Re: [go-nuts] Re: is there a way to mirror a standard package while adding some functions to it?

[Marwan abdel moneim]

yes, you are right, if i am going to drop http.JSON and http.Response
i am trying to do that, i think it is better to make it small like you have 
said

thanks

On Saturday, January 28, 2017 at 5:50:08 AM UTC+2, Matt Silverlock wrote:
>
> This definitely doesn't require you to modify net/http directly. 
>
> Just create a library with custom handler types that satisfy the 
> http.Handler interface. Many existing Go routing libraries & frameworks 
> will get you 90% of the way there.
>
>
> On Fri, Jan 27, 2017 at 7:42 PM Marwan abdel moneim  > wrote:
>
>> i want to do something like this
>>
>> http.Handler{
>>   Action:   "Create new user",
>>   Method: "POST",
>>   URI:   "/users",
>>   Auth:  false,
>>   Params: []string{"name:max=100"},
>>   Do: func(r *http.Request) http.Response{
>> ..
>> return http.JSON(&user)
>>   }}
>>
>> and do the common tasks like validation and authentication on a top layer
>> and could also generate a nice looking html file for the API 
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/g9NYQNaBBMA/unsubscribe.
>> To unsubscribe from this group and all its topics, 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: is there a way to mirror a standard package while adding some functions to it?

[Matt S]

This definitely doesn't require you to modify net/http directly.

Just create a library with custom handler types that satisfy the
http.Handler interface. Many existing Go routing libraries & frameworks
will get you 90% of the way there.


On Fri, Jan 27, 2017 at 7:42 PM Marwan abdel moneim 
wrote:

> i want to do something like this
>
> http.Handler{
>   Action:   "Create new user",
>   Method: "POST",
>   URI:   "/users",
>   Auth:  false,
>   Params: []string{"name:max=100"},
>   Do: func(r *http.Request) http.Response{
> ..
> return http.JSON(&user)
>   }}
>
> and do the common tasks like validation and authentication on a top layer
> and could also generate a nice looking html file for the API
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/g9NYQNaBBMA/unsubscribe.
> To unsubscribe from this group and all its topics, 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: is there a way to mirror a standard package while adding some functions to it?

[Matt S]

This definitely doesn't require you to modify net/http directly.

Just create a library with custom handler types that satisfy the
http.Handler interface. Many existing Go routing libraries & frameworks
will get you 90% of the way there.
On Fri, Jan 27, 2017 at 7:42 PM Marwan abdel moneim 
wrote:

> i want to do something like this
>
> http.Handler{
>   Action:   "Create new user",
>   Method: "POST",
>   URI:   "/users",
>   Auth:  false,
>   Params: []string{"name:max=100"},
>   Do: func(r *http.Request) http.Response{
> ..
> return http.JSON(&user)
>   }}
>
> and do the common tasks like validation and authentication on a top layer
> and could also generate a nice looking html file for the API
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/g9NYQNaBBMA/unsubscribe.
> To unsubscribe from this group and all its topics, 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: is there a way to mirror a standard package while adding some functions to it?

[Marwan abdel moneim]

i want to do something like this

http.Handler{
  Action:   "Create new user",
  Method: "POST",
  URI:   "/users",
  Auth:  false,
  Params: []string{"name:max=100"},
  Do: func(r *http.Request) http.Response{
..
return http.JSON(&user)
  }}

and do the common tasks like validation and authentication on a top layer
and could also generate a nice looking html file for the API 

-- 
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: is there a way to mirror a standard package while adding some functions to it?

[Matt S]

Which functions? What are you actually changing?

A wrapper library doesn't have to wrap all the functions: just wrap the
ones you need to and make it a small, composable library.



On Fri, Jan 27, 2017 at 7:12 PM Marwan abdel moneim 
wrote:

> do your changes require you to modify the package?
>
> yes, i want to add some functions, but still provide all the package to
> the user
>
> Why not use wrap it?
>
> i would have to wrap all the functions, very tedious
>
> On Saturday, January 28, 2017 at 5:06:31 AM UTC+2, Matt Silverlock wrote:
>
> No, but without more context, do your changes require you to modify the
> package? Why not use wrap it?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/g9NYQNaBBMA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: is there a way to mirror a standard package while adding some functions to it?

[Marwan abdel moneim]

>
> do your changes require you to modify the package?
>
yes, i want to add some functions, but still provide all the package to the 
user 

Why not use wrap it?
>
i would have to wrap all the functions, very tedious 

On Saturday, January 28, 2017 at 5:06:31 AM UTC+2, Matt Silverlock wrote:
>
> No, but without more context, do your changes require you to modify the 
> package? Why not use wrap it?

-- 
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] is there a way to mirror a standard package while adding some functions to it?

[Matt Silverlock]

No, but without more context, do your changes require you to modify the 
package? Why not use wrap it?

-- 
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] Call for Feedback: Scoping gorilla/sessions v2

[Matt Silverlock]

gorilla/sessions has been around for a while, and with request.Context() back 
in Go 1.7, there's an unavoidable need to make breaking changes to the library. 
While we're at it, breaking a bunch more (and simplifying others!) in the 
process makes a whole lot of sense. We've also been ultra-careful about any 
breaking changes because sessions existed well before many of the vendoring 
tools did.  

I've pulled together a list of ideas, but wanted to gather feedback from as 
many (current & future) users as possible. GitHub Issue here:
 http:///github.com/gorilla/sessions/issues/105

-- 
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] Short vs. long variable declarations

[Will Faught]

Variable shadowing is rarely, if ever, a problem for me too; but what about
for newcomers?

I think my copy/paste point stands, though; everyone has those problems, at
least occasionally.

On Fri, Jan 27, 2017 at 3:00 PM Tyler Compton  wrote:

> While theoretically, I agree with your argument against using the short
> variable declaration pattern, I've personally found that in practice it
> isn't an issue. I think that if this is something you run into often, it
> might suggest that you're letting too many variables into your scope,
> whether that means having too many generically named global variables or
> being inside too large a function.
>
> On Fri, Jan 27, 2017, 11:57 AM Shawn Milochik 
> wrote:
>
> Here's a good discussion about it:
>
> https://groups.google.com/d/msg/golang-nuts/J9QeizedpuI/ECifbR0YGcsJ
>
> TL;DR: scope
>
> --
>
> 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 a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/222uOfTmd0U/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Short vs. long variable declarations

[Will Faught]

This seems to be a discussion about short variable names. What's the
connection?

On Fri, Jan 27, 2017 at 10:58 AM Shawn Milochik 
wrote:

> Here's a good discussion about it:
>
> https://groups.google.com/d/msg/golang-nuts/J9QeizedpuI/ECifbR0YGcsJ
>
> TL;DR: scope
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/222uOfTmd0U/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Short vs. long variable declarations

[Shawn Milochik]

On Fri, Jan 27, 2017 at 6:00 PM, Tyler Compton  wrote:

> While theoretically, I agree with your argument against using the short
> variable declaration pattern, I've personally found that in practice it
> isn't an issue. I think that if this is something you run into often, it
> might suggest that you're letting too many variables into your scope,
> whether that means having too many generically named global variables or
> being inside too large a function.
>
> On Fri, Jan 27, 2017, 11:57 AM Shawn Milochik 
> wrote:
>
>> Here's a good discussion about it:
>>
>> https://groups.google.com/d/msg/golang-nuts/J9QeizedpuI/ECifbR0YGcsJ
>>
>> TL;DR: scope
>>
>>

I'm not making an argument against them, and use them all the time. The
original post in that thread was from years ago, when I was new to Go and
steeped in the ways of Python. :o)

-- 
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] Short vs. long variable declarations

[Tyler Compton]

While theoretically, I agree with your argument against using the short
variable declaration pattern, I've personally found that in practice it
isn't an issue. I think that if this is something you run into often, it
might suggest that you're letting too many variables into your scope,
whether that means having too many generically named global variables or
being inside too large a function.

On Fri, Jan 27, 2017, 11:57 AM Shawn Milochik  wrote:

> Here's a good discussion about it:
>
> https://groups.google.com/d/msg/golang-nuts/J9QeizedpuI/ECifbR0YGcsJ
>
> TL;DR: scope
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 1.8rc3 - surprise

[joetsai via golang-nuts]

When I was deploying Go1.8 in my company, I found url.Parse to also caused 
many problems. However, every time I looked closely at the failure, I was 
convinced that it was because of a mis-use of the url package, rather than 
Go1.8's fault. If anything, I think the documentation for the url package 
could definitely use some work.

I filed https://github.com/golang/go/issues/18824 for this.

On Friday, January 27, 2017 at 1:39:01 PM UTC-8, Matt Aimonetti wrote:
>
> Just a quick heads up since we noticed an issue testing 1.8rc3 against our 
> code. The issue is quite subtle and was hidden inside a dependency package 
> of ours: https://github.com/pubnub/go/tree/master/messaging
>
> After updating our containers to 1.8 we started noticing that pubnub was 
> rejecting the JSON messages generated by its own package. We wrongly 
> assumed it was a problem with JSON marshaling but the problem was a bit 
> deeper.
> The root cause was that the `url.URL` `String()` method was changed to 
> match the RFC 3986 https://beta.golang.org/doc/go1.8#net_url 
>
> > To force interpretation as a relative path, such URLs should be prefixed 
> with “./”. The URL.String method now inserts this prefix as needed.
>
> Because of this change, the PubNub library was now starting creating 
> unexpected urls with `./` in the path which was causing a bunch of issues.
> To make things worth, the change in JSON marshaling of floating points 
> make a lot of (poorly written) tests fail and ends up hiding the root 
> cause: https://beta.golang.org/doc/go1.8#encoding_json
>
> The fix is quite straightforward but I am afraid this change to url.URL 
> might make the transition to 1.8 much painful/unexpected than usual.
>
> - Matt
>

-- 
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] is there a way to mirror a standard package while adding some functions to it?

[Marwan abdel moneim]

i want to add few changes for the net/http package, while keeping the rest 
of the package as it is, but without copying the package source and put it 
in another one, i want my package to mirror whatever the package version 
installed

-- 
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] Go 1.8rc3 - surprise

[Matt Aimonetti]

Just a quick heads up since we noticed an issue testing 1.8rc3 against our 
code. The issue is quite subtle and was hidden inside a dependency package 
of ours: https://github.com/pubnub/go/tree/master/messaging

After updating our containers to 1.8 we started noticing that pubnub was 
rejecting the JSON messages generated by its own package. We wrongly 
assumed it was a problem with JSON marshaling but the problem was a bit 
deeper.
The root cause was that the `url.URL` `String()` method was changed to 
match the RFC 3986 https://beta.golang.org/doc/go1.8#net_url 

> To force interpretation as a relative path, such URLs should be prefixed 
with “./”. The URL.String method now inserts this prefix as needed.

Because of this change, the PubNub library was now starting creating 
unexpected urls with `./` in the path which was causing a bunch of issues.
To make things worth, the change in JSON marshaling of floating points make 
a lot of (poorly written) tests fail and ends up hiding the root cause: 
https://beta.golang.org/doc/go1.8#encoding_json

The fix is quite straightforward but I am afraid this change to url.URL 
might make the transition to 1.8 much painful/unexpected than usual.

- Matt

-- 
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.5 and Go 1.8rc3 are released

[Steven Hartland]

Nice thanks for sharing that :)

On 27/01/2017 16:42, alb.donize...@gmail.com wrote:

A better link is this one, IMHO:

github.com/golang/go/compare/go1.7.4...go1.7.5

the gerrit one shows uninteresting CLs too, like:

[release-branch.go1.7] cmd/godoc: add perf subrepo

while the github one doesn't

Il giorno venerdì 27 gennaio 2017 15:58:20 UTC+1, Steven Hartland ha 
scritto:


Hi guys first off thanks for 1.7.5!

Having reviewed the changes for the 1.7.5 milestone
, which
is the link provided for more info from the release notes, I feel
that the its not as easy to follow as they have been for other
milestones, which means that users may not realise the impact as
well as they should.

 The data is there but you really have do dig in to see it, I'm
referring specifically to the "backport" changes:

  * time, cmd/compile: backport fixes to 1.7.5
  * runtime: backport CL 34835
  * runtime: backport CLs 9 and 35353
  * runtime: backport CL 31138

In the past each fix has been in the original format which would
have resulted in something like:

  * time: TestLoadFixed failure
  * cmd/compile: passing method on value receiver causes memory
corruption
  * runtime: fatal error: bad g->status in ready
  * runtime: fatal error: scan missed a g
  * runtime: fatal error: unexpected signal during runtime execution
  * runtime: getArgInfo nil dereference

Its important to know that these are issues that "were actually
raised" and are fixed by changes in the release, it is NOT the
list of fixes which users are likely expecting.

Its good to know the "issues" which have been closed by the
release, but its more useful to know all the "changes" in the release.

This is something that jenkins can do:

https://go-review.googlesource.com/#/q/status:merged+branch:release-branch.go1.7++after:2016-12-02+before:2017-01-27



Is this something we can include for releases moving forward?


On 26/01/2017 21:19, Chris Broadfoot wrote:

Hello gophers,

We have just released go1.7.5, which includes fixes to the compiler,
runtime, and the crypto/x509 and time packages.
https://golang.org/doc/devel/release.html#go1.7.minor

You can download binary and source distributions from the Go web
site:
https://golang.org/dl/

We also released go1.8rc3, a release candidate of Go 1.8.
It is cut from release-branch.go1.8 at the revision tagged go1.8rc3.

Thank you to everyone who has helped to test Go 1.8 so far.
Your help is invaluable.

Report any problems using the issue tracker:
https://golang.org/issue/new

If you have Go installed already, the easiest way to try go1.8rc3
is by using this tool:
https://godoc.org/golang.org/x/build/version/go1.8rc3


You can download binary and source distributions from the usual
place:
https://golang.org/dl/#go1.8rc3 

To find out what has changed in Go 1.8, read the draft release notes:
https://beta.golang.org/doc/go1.8 

Documentation for Go 1.8 is available at:
https://beta.golang.org/

Our goal is to release the final version of Go 1.8 on February 1st.

Cheers,
Chris
-- 
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] Short vs. long variable declarations

[Shawn Milochik]

Here's a good discussion about it:

https://groups.google.com/d/msg/golang-nuts/J9QeizedpuI/ECifbR0YGcsJ

TL;DR: scope

-- 
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] Short vs. long variable declarations

[Will Faught]

 

Which do you default to? I see a lot of code using short decls in most 
cases, and only using long decls with no initialization where the zero 
value is needed. It seems to me that long decls should be the default 
declaration used because short decls are context-sensitive. That is, you 
have no idea what this is doing:


x, y := z()


It might be declaring x and y, or just x, or just y. This can lead to 
copy/paste and variable shadowing errors. Long declarations don't have 
those problems. As a bonus, the long declaration syntax matches those for 
consts and types:


const c = ... 

type t ... 

var x = ...


So I use long declarations unless I need to declare a new variable in 
combination with assigning to an existing variable, like reusing an err 
variable:


var w, err = x()

y, err := z()


The short declaration draws attention to the fact that something clever is 
going on.


What do you think? I'm looking for pragmatic reasons for or against.

-- 
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] testing.Benchmark Unanswered StackOverflow question. Looks like a bug.

[Ilya Kostarev]

On 01/27/2017 05:20 PM, Ian Lance Taylor wrote:
Please file an issue at https://golang.org/issue/new. Thanks. Ian 

Ian,
done, issued.

--
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.5 and Go 1.8rc3 are released

[alb . donizetti]

A better link is this one, IMHO:

github.com/golang/go/compare/go1.7.4...go1.7.5

the gerrit one shows uninteresting CLs too, like:

[release-branch.go1.7] cmd/godoc: add perf subrepo 

while the github one doesn't

Il giorno venerdì 27 gennaio 2017 15:58:20 UTC+1, Steven Hartland ha 
scritto:
>
> Hi guys first off thanks for 1.7.5!
>
> Having reviewed the changes for the 1.7.5 milestone 
> , which is the 
> link provided for more info from the release notes, I feel that the its not 
> as easy to follow as they have been for other milestones, which means that 
> users may not realise the impact as well as they should.
>
>  The data is there but you really have do dig in to see it, I'm referring 
> specifically to the "backport" changes:
>
>- time, cmd/compile: backport fixes to 1.7.5 
>- runtime: backport CL 34835 
>- runtime: backport CLs 9 and 35353 
>- runtime: backport CL 31138 
>
> In the past each fix has been in the original format which would have 
> resulted in something like:
>
>- time: TestLoadFixed failure 
>- cmd/compile: passing method on value receiver causes memory 
>corruption 
>- runtime: fatal error: bad g->status in ready 
>- runtime: fatal error: scan missed a g 
>- runtime: fatal error: unexpected signal during runtime execution 
>- runtime: getArgInfo nil dereference
>
> Its important to know that these are issues that "were actually raised" 
> and are fixed by changes in the release, it is NOT the list of fixes which 
> users are likely expecting.
>
> Its good to know the "issues" which have been closed by the release, but 
> its more useful to know all the "changes" in the release.
>
> This is something that jenkins can do:
>
> https://go-review.googlesource.com/#/q/status:merged+branch:release-branch.go1.7++after:2016-12-02+before:2017-01-27
>
> Is this something we can include for releases moving forward?
>
> On 26/01/2017 21:19, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We have just released go1.7.5, which includes fixes to the compiler,
> runtime, and the crypto/x509 and time packages.
> https://golang.org/doc/devel/release.html#go1.7.minor
> You can download binary and source distributions from the Go web site:
> https://golang.org/dl/ 
>
> We also released go1.8rc3, a release candidate of Go 1.8.
> It is cut from release-branch.go1.8 at the revision tagged go1.8rc3.
>
> Thank you to everyone who has helped to test Go 1.8 so far.
> Your help is invaluable.
>
> Report any problems using the issue tracker:
> https://golang.org/issue/new
>
> If you have Go installed already, the easiest way to try go1.8rc3
> is by using this tool:
> https://godoc.org/golang.org/x/build/version/go1.8rc3
>
> You can download binary and source distributions from the usual place:
> https://golang.org/dl/#go1.8rc3
>
> To find out what has changed in Go 1.8, read the draft release notes:
> https://beta.golang.org/doc/go1.8
>
> Documentation for Go 1.8 is available at:
> https://beta.golang.org/
>
> Our goal is to release the final version of Go 1.8 on February 1st.
>
> Cheers,
> Chris
> -- 
> 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] GOMAXPROCS survey

[Sameer Ajmani]

Inside Google. we automatically update GOMAXPROCS when the job management
system indicates that the container resources have changed.  This usually
happens when with either the user or automatic systems update the container
resources based on observed use.  I would expect other job management
systems provide similar auto-scaling facilities.

On Thu, Jan 26, 2017 at 11:40 PM Sokolov Yura 
wrote:

> How often your application changes GOMAXPROCS at runtime?
> What is the reason of this change?
> What patterns of this change exist (ie is it bounded, is it frequent, etc)?
>
> --
> 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.5 and Go 1.8rc3 are released

[Steven Hartland]

Hi guys first off thanks for 1.7.5!

Having reviewed the changes for the 1.7.5 milestone 
, which is 
the link provided for more info from the release notes, I feel that the 
its not as easy to follow as they have been for other milestones, which 
means that users may not realise the impact as well as they should.


 The data is there but you really have do dig in to see it, I'm 
referring specifically to the "backport" changes:


 * time, cmd/compile: backport fixes to 1.7.5
 * runtime: backport CL 34835
 * runtime: backport CLs 9 and 35353
 * runtime: backport CL 31138

In the past each fix has been in the original format which would have 
resulted in something like:


 * time: TestLoadFixed failure
 * cmd/compile: passing method on value receiver causes memory corruption
 * runtime: fatal error: bad g->status in ready
 * runtime: fatal error: scan missed a g
 * runtime: fatal error: unexpected signal during runtime execution
 * runtime: getArgInfo nil dereference

Its important to know that these are issues that "were actually raised" 
and are fixed by changes in the release, it is NOT the list of fixes 
which users are likely expecting.


Its good to know the "issues" which have been closed by the release, but 
its more useful to know all the "changes" in the release.


This is something that jenkins can do:
https://go-review.googlesource.com/#/q/status:merged+branch:release-branch.go1.7++after:2016-12-02+before:2017-01-27

Is this something we can include for releases moving forward?


On 26/01/2017 21:19, Chris Broadfoot wrote:

Hello gophers,

We have just released go1.7.5, which includes fixes to the compiler,
runtime, and the crypto/x509 and time packages.
https://golang.org/doc/devel/release.html#go1.7.minor
You can download binary and source distributions from the Go web site:
https://golang.org/dl/

We also released go1.8rc3, a release candidate of Go 1.8.
It is cut from release-branch.go1.8 at the revision tagged go1.8rc3.

Thank you to everyone who has helped to test Go 1.8 so far.
Your help is invaluable.

Report any problems using the issue tracker:
https://golang.org/issue/new

If you have Go installed already, the easiest way to try go1.8rc3
is by using this tool:
https://godoc.org/golang.org/x/build/version/go1.8rc3

You can download binary and source distributions from the usual place:
https://golang.org/dl/#go1.8rc3

To find out what has changed in Go 1.8, read the draft release notes:
https://beta.golang.org/doc/go1.8

Documentation for Go 1.8 is available at:
https://beta.golang.org/

Our goal is to release the final version of Go 1.8 on February 1st.

Cheers,
Chris
--
You received this message because you are subscribed to the Google 
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to golang-nuts+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: http: Empty pattern

[paraiso . marc]

> What did I miss?

nothing, there is plenty of routers that will do what you want :

https://github.com/avelino/awesome-go#web-frameworks

or just write a switch statement in your handler.

the behavior of the default muxer is hardly going to change anyway, it 
would obviously be a breaking change. That's the drawback of "facades".

Le vendredi 27 janvier 2017 14:54:07 UTC+1, Florian Uekermann a écrit :
>
> I tried googling this, but couldn't find anything.
>
> A common issue when using the http package and registering handles is the 
> need to register a handler for "domain.com" that does not catch "
> domain.com/otherStuff". Since any pattern ending in a "/" matches paths
> prefixed with the pattern, providing "/" as a pattern matches both "
> domain.com" as well as "domain.com/asdf".
>
> With longer patterns the corresponding issue is easily dealt with by 
> omitting the trailing "/" in the pattern.
> I was wondering if it makes sense to change the http package a bit and use 
> the empty pattern "" to match only "domain.com", but not longer paths.
>
> This change would be fairly consistent with how specific matches work in 
> other cases (remove trailing "/") and should not change the behavior of 
> existing code, since providing "" as a pattern results in a panic at the 
> moment.
>
> What did I miss?
>
> Best regards,
> Florian
>

-- 
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] AST to parse contents of Structs

[Jeffrey Smith]

I'm trying to use the ast and parse packages to find the fields in two 
separate structs one that will be called Inputs and the other Outputs. 
these can change but as an example i'm trying to parse these

package main

import (
   "fmt"
)

type Inputs struct {
   Name string `json:"name"`
   Age  int`json:"age"`
}

type Outputs struct {
   Number float `json:"number"`
}

func main() {

fmt.Println("Hello World!")
}



I have the following which can pick out the two structs but i'm now lost on 
how to loop through the fields to get name, type and commenty bit 
`json:"name"` at the end. 

package main

import (
"fmt"
"go/ast"
"go/parser"
"go/token"
"log"
)

func main() {

fset := token.NewFileSet()
file, err := parser.ParseFile(fset, "sample/main.go", nil, 0)
if err != nil {
log.Fatal(err)
}
ast.Walk(VisitorFunc(FindTypes), file)

}

type VisitorFunc func(n ast.Node) ast.Visitor

func (f VisitorFunc) Visit(n ast.Node) ast.Visitor {
return f(n)
}

func FindTypes(n ast.Node) ast.Visitor {
switch n := n.(type) {
case *ast.Package:
return VisitorFunc(FindTypes)
case *ast.File:
return VisitorFunc(FindTypes)
case *ast.GenDecl:
if n.Tok == token.TYPE {
return VisitorFunc(FindTypes)
}
case *ast.TypeSpec:
if n.Name.Name == "Inputs" {
//We have hit the inputs struct
fmt.Println(n.Name.Name)
}
if n.Name.Name == "Outputs" {
//We have hit the outputs struct
fmt.Println(n.Name.Name)
}
}
return nil
}

Any suggestions as to how to do it?

-- 
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] testing.Benchmark Unanswered StackOverflow question. Looks like a bug.

[Ian Lance Taylor]

On Fri, Jan 27, 2017 at 1:15 AM, Ilya Kostarev  wrote:
> Just this
> http://stackoverflow.com/questions/41861918/using-testing-benchmark-does-not-produce-any-output
> Citation
>
> package main
>
> import "testing"
>
> func main() {
>
> result := testing.Benchmark(func(parentB *testing.B) {
> parentB.Run("example", func(b *testing.B) {
> for n := 0; n < b.N; n++ {
> println("ok")
> }
> })
> })
>
> println(result.String())
>
> }
>
> This will print ok a couple times and then 0 0 ns/op but the benchmark
> clearly did run something.
>
> Same on my machine. It really looks like a bug, or documentation
> incorrectness/incompleteness.

I think it's a bug in how the Benchmark function handles
sub-benchmarks.  Please file an issue at https://golang.org/issue/new.
Thanks.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: x/mobile/gl: blocking vs non-blocking calls

[Roberto Zanotto]

I misunderstood the purpose of the mechanism used for the gl calls.
It is not to save cgo calls (in fact, it doesn't), it is to handle the fact 
that OpenGL wants to be called form a locked thread, as exemplified in:
https://godoc.org/golang.org/x/mobile/gl#Worker

On Thursday, January 26, 2017 at 7:04:36 PM UTC+1, Roberto Zanotto wrote:
>
> Hi.
>
> I'm looking at the source of mobile/gl.
> If I understand correctly, it has a mechanism to reduce the number of cgo 
> calls: the gl calls are accumulated, until a "blocking" call is reached; 
> when that happens, all the calls with associated arguments are passed at 
> once to a C function, which executes them all.
>
> I would like to implement a similar technique for some OpenGL non-ES 
> bindings.
> The question is: how is this "blocking" property defined? How do I decide 
> which function should be flagged as blocking and which one shouldn't?
>

-- 
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] http: Empty pattern

['Florian Uekermann' via golang-nuts]

I tried googling this, but couldn't find anything.

A common issue when using the http package and registering handles is the 
need to register a handler for "domain.com" that does not catch 
"domain.com/otherStuff". Since any pattern ending in a "/" matches paths
prefixed with the pattern, providing "/" as a pattern matches both 
"domain.com" as well as "domain.com/asdf".

With longer patterns the corresponding issue is easily dealt with by 
omitting the trailing "/" in the pattern.
I was wondering if it makes sense to change the http package a bit and use 
the empty pattern "" to match only "domain.com", but not longer paths.

This change would be fairly consistent with how specific matches work in 
other cases (remove trailing "/") and should not change the behavior of 
existing code, since providing "" as a pattern results in a panic at the 
moment.

What did I miss?

Best regards,
Florian

-- 
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] [ANN] raylib-go: Go bindings for raylib, a simple and easy-to-use library to learn videogames programming

[gen2brain]

Golang bindings for http://www.raylib.com/ , a library to learn videogames 
programming.

Raylib is highly inspired by BGI lib and XNA framework. It is written in 
plain C and by default compiles to single static library.
Depends on GLFW3 (for desktop only) and OpenAL, both libs can also be 
easily compiled statically.

All raylib examples (60+) are ported to Go and there are a few more, for 
raygui (immediate mode GUI API) and for easings. Physics engine is on TODO 
list.

Android support is implemented with native_app_glue and NativeActivity, 
without any Java code. Go bindinds also support RPi, but I tried only with 
cross compile, not on a real device.

https://github.com/gen2brain/raylib-go

-- 
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] testing.Benchmark Unanswered StackOverflow question. Looks like a bug.

[Ilya Kostarev]

Just this 
http://stackoverflow.com/questions/41861918/using-testing-benchmark-does-not-produce-any-output

Citation

|package  main

import  "testing"

func main()  {

result:=  testing.Benchmark(func(parentB*testing.B)  {
parentB.Run("example",  func(b*testing.B)  {
for  n:=  0;  n<  b.N;  n++  {
println("ok")
}
})
})

println(result.String())

}|

This will print |ok| a couple times and then |0 0 ns/op| but the 
benchmark clearly did run something.


Same on my machine. It really looks like a bug, or documentation 
incorrectness/incompleteness.

__
Ilya Kostarev

--
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] GolangRT Docs?

[Konstantin Khomoutov]

On Thu, 26 Jan 2017 19:57:22 -0800 (PST)
T L  wrote:

> > It depends. A call to new can (and will, often) give you a pointer
> > to a stack allocated object. If you pass that pointer to something
> > like fmt.Println() you'll see the object escape to the heap, get
> > flagged by -m, and presumably forbidden by -+. 
> >
> 
> so
> 
> new(T)
> 
> is just a sugar of the following one?
> 
> var t T; &t

Sort of yes, but the allocated (pointed at) value will be anonymous
(not contained in any variable).

IIUC, Go compiler makes no distinction between "stack" and "heap"
allocation: you are free to return pointer to a variable which -- in
C -- would be stack-allocated, and the Go compiler will notice the
value of that variable "escapes" its scope and will make sure it will
be heap-allocated (or otherwise preserved).

Allocating a value with new(T) has the similar property: contrary to the
(not overloaded) operator new from C++, calling new() does not mean you
will get a heap-allocated value: if it can be proven to not escape, it
may well be allocated on the stack.

As you can see for yourself, [1] does not in any way mention how
exactly a value is allocated -- just that a pointer to its memory is
returned.

1. https://golang.org/ref/spec#Allocation

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