Re: [go-nuts] What is called reference values in Golang?

[T L]

On Friday, October 21, 2016 at 1:11:32 AM UTC+8, Ian Lance Taylor wrote:
>
> On Thu, Oct 20, 2016 at 6:47 AM, T L  
> wrote: 
> > 
> > On Thursday, October 20, 2016 at 4:46:52 PM UTC+8, Dave Cheney wrote: 
> >> 
> >> What is a pointer wrapper value? 
> > 
> > 
> > struct { 
> >p *T 
> > } 
> > 
> >> 
> >> 
> >> in all seriousness, if you review the git history of the Go spec you'll 
> >> find the word "reference" was purged about two years ago, in effect, to 
> try 
> >> to stem these discussions. 
> > 
> > 
> > Yes, I found many old docs and old web pages are still using the word 
> > "reference value". 
> > I think it is an unnecessary word. The concepts of values and pointer 
> values 
> > are sufficient to understand Golang values well. 
>
> I have a minor objection.  I don't know what a "reference value" is. 
> Alan spoke about "reference types", and sometimes, in the past, before 
> we realized that it was confusing, the Go docs also talked about 
> "reference types." 
>
> I don't think we ever talked about "reference values."  Perhaps a 
> "reference value" is a value whose type is a "reference type." 
> However, people (not Go people, computer programming people in 
> general) also talk about "passing by reference" as opposed to "passing 
> by value", so combining the two opposing terms "reference" and "value" 
> into a single phrase is confusing. 
>
> Ian 
>

This faq, "Why are maps, slices, and channels references while arrays are 
values?", https://golang.org/doc/faq#references.
thinks maps, slices, and channels are references. I think the "references" 
here means "reference values".


 

-- 
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] undefined: C in C.PCAP_NETMASK_UNKNOWN

[Mehrdad . Arshad . Rad]

Hi,

Today I noticed the travis-ci fails once it tries to build myLG 
 w/ latest Go version:devel +7ea5829 
and shows below errors.

The command "eval go get -t -v ./..." failed. 

github.com/google/gopacket/pcap../../google/gopacket/pcap/pcap.go:594: 
undefined: C in C.PCAP_NETMASK_UNKNOWN 


any idea?


Thanks,

Mehrdad

-- 
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: Like "inquirer" cli...

[derrick . cohodas]

I'm looking for the same thing!

On Thursday, October 20, 2016 at 8:48:57 AM UTC-7, luism...@gmail.com wrote:
>
>
> Hi, from Spain.
> Does anyone know of a cli like inquirer for golang?
>
> https://github.com/sboudrias/Inquirer.js
>
> Thanks a lot.
>

-- 
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 build my own godoc

[Pietro Gagliardi]

You can cd into ~/golang.org/x/tools/godoc and do go build to build a godoc in 
that directory.

go install golang.org/x/tools/godoc will also use your local modification of 
godoc, but I don't know where it installs to anymore.

> On Oct 20, 2016, at 10:08 PM, FancyGo  wrote:
> 
> Download from github go-tool. Modified 
> ~/gopkg/src/golang.org/x/tools/godoc/static/static.go. GOPATH is ~/gopkg
> 
> 在 2016年10月21日星期五 UTC+8上午12:50:49，Pietro Gagliardi (andlabs)写道：
> Where did you download it to, what file (absolute filename) did you modify, 
> and what is your $GOPATH?
>> On Oct 20, 2016, at 3:05 AM, FancyGo  wrote:
>> 
>> Hi all, I have download source code of godoc. But I have no idea how to 
>> build it. Because I have modified the source code, so I don't want use the 
>> bin godoc.
>> 
>> -- 
>> 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] How to build my own godoc

[FancyGo]

Download from github go-tool. Modified 
~/gopkg/src/golang.org/x/tools/godoc/static/static.go. GOPATH is ~/gopkg

在 2016年10月21日星期五 UTC+8上午12:50:49，Pietro Gagliardi (andlabs)写道：
>
> Where did you download it to, what file (absolute filename) did you 
> modify, and what is your $GOPATH?
>
> On Oct 20, 2016, at 3:05 AM, FancyGo  
> wrote:
>
> Hi all, I have download source code of godoc. But I have no idea how to 
> build it. Because I have modified the source code, so I don't want use the 
> bin godoc.
>
> -- 
> 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: Tooling experience feedback

[roger peppe]

That's a marvellous hack Aram!
It would still be nicer if there was an easier way though.

On 20 Oct 2016 20:09, "Aram Hăvărneanu"  wrote:

On Wed, Oct 19, 2016 at 7:27 PM, Nate Finch  wrote:
> Please give us an easy way to ensure all tests in a list of packages
compile

Do something like this:

go test -toolexec wrapper -exec success pkgs...

Where wrapper is a binary that dispatches to the compiler, but a nop
when called with the linker, and success is a binary that just exits
successfully.

--
Aram Hăvărneanu

--
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] the defer list

[andrew . smith]

Yeah, thanks for that Konstantin. I have done something fairly similar, 
although all my objects support a Destroyable interface with one method 
Destroy(). However, I think your idea to closely mimic the defer list and 
simply push functions is much cleaner. The basic concept seems to work 
quite well so far and makes the wrapped functions pretty tidy at the 
expense of some efficiency I imagine. Ive also added a finalizer to the 
Stack so that in the (hopefully rare) case where the defer might be 
accidentally omitted, there is potentially a second chance to clean up.

On Thursday, October 20, 2016 at 3:46:00 PM UTC+1, Konstantin Khomoutov 
wrote:
>
> On Wed, 19 Oct 2016 15:35:40 -0700 (PDT) 
> andrew...@miracl.com  wrote: 
>
> [...] 
> > Im considering a scheme where I push every CString onto an 
> > implementation of a stack, and then call defer once. Im sure some 
> > people might think it overkill... Kinda like this : 
> > 
> > func Outer(arg1 string, arg2 string, arg3 string, arg4 string) Return 
> > { stack := NewStack() 
> > defer stack.Destroy() 
> > return wrapReturn( 
> > C.inner( 
> > NewStackCString(arg1, stack).p, 
> > NewStackCString(arg2, stack).p, 
> > NewStackCString(arg3, stack).p, 
> > NewStackCString(arg4, stack).p)) 
> > } 
> [...] 
>
> I think something like this should work in Go almost unmodified -- 
> just you won't have a system-provided "defer list", will have a single 
> deferred execution of stack.Destroy() and have your own implementation 
> of that stack type. 
>
> Something like this: 
>
> 8< 
> package main 
> 
> import "fmt" 
> 
> type dtor func() 
> 
> type cleanup struct { 
> dts []dtor 
> } 
> 
> func (c *cleanup) Add(d dtor) { 
> c.dts = append(c.dts, d) 
> } 
> 
> func (c *cleanup) Cleanup() { 
> for _, f := range c.dts { 
> f() 
> } 
> } 
> 
> type Foo struct{} 
> 
> func (f Foo) Close() { 
> fmt.Println("Foo.Close()") 
> } 
> 
> type Bar struct{} 
> 
> func (b Bar) CFree() { 
> fmt.Println("Bar.CFree()") 
> } 
> 
> func foo() { 
> var dts cleanup 
> defer dts.Cleanup() 
> 
> foo := Foo{} 
> dts.Add(foo.Close) 
> 
> bar := Bar{} 
> dts.Add(bar.CFree) 
> } 
> 
> func main() { 
> foo() 
> } 
> 8< 
>
> (Playground link: https://play.golang.org/p/TqCfBfZb_X). 
>
>
> BTW I found myself doing something much like this in some of my C# 
> projects to avoid nesting hell of 
>
>   using (...acquire resource...) { 
> using (...acquire resource...) { 
>   ...etc ad nauseum 
>   } 
>
> whereas you have a stack-like data type which implements IDisposable, 
> and you just have a single using() { ... } block for it inside which 
> you add particular resources to be destroyed to that instance, and at 
> the end of the block it's told to destroy itself and then it destroys 
> whatever resources have been added to 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] Are short variable declarations necessary?

[Robert Griesemer]

To answer the subject line question: No, short variable declarations are
not technically necessary. We could have chosen not to have them. But there
are good reasons for them. It was a deliberate design decision.

Let me throw in a bit of historical perspective:

Rob's invention of ":=" in one of his prior languages, and later, our
shared experience with ":=" in Sawzall (
https://en.wikipedia.org/wiki/Sawzall_(programming_language)) led to the
desire of wanting ":=" in Go. Variable declaration and initialization is
among the most common statements written in an imperative programming
language (next to simple assignment), and ":=" worked beautifully and
succinctly for this purpose in the past, and it fit well into the overall
design of Go.

The key here is that providing an initialization expression is mandatory
with ":=" (in contrast to "just" a variable declaration), and because it's
mandatory, we can omit the type of the variable (assuming we're ok with the
type of the initialization expression).

At the same time we wouldn't simple give up ordinary variable declarations,
using the "var" keyword. For one, at the package level, a free-standing
(i.e., w/o introductory keyword) "v := x" would cause parsing difficulties
and be somewhat irregular compared to all other declarations.

Thus, originally, "x := y" was simply very convenient syntactic sugar for
"var x = y" and both could be used interchangeably, in most places. Go has
little syntactic sugar, and where it has, it's because there's a lot of
"bang for the buck" - and that's certainly the case for ":=".

The fact that "var x = y" is not permitted as a "for" loop initialization
statement was simply a design decision. Ian Taylor suggested that it's
"ugly". Aesthetics plaid a role here; and different people find different
things attractive. There's no hard technical reason why it couldn't be
permitted, it just isn't.

Finally, the special rule permitting "redeclarations" with ":=" only came
in later. It gave short variable declarations different powers over regular
keyword-based variable declarations. While it was considered a very useful
new rule, it definitively distracted from the simple syntactic sugar
regularity.

It is no secret that many people (including us) think that there may be too
many different yet similar ways of declaring and initializing variables in
Go; and it would be nice if a future Go could streamline and simplify this.
But we should also keep in mind that variable declaration and
initialization, next to simple assignment, are the most common statements
in program (it's one of the few things hardware can actually do directly,
which is moving data from a to b), so it does not seem unreasonable to have
various ways to express that, fine-tuned for each (relatively common) use
case.

- gri



On Thu, Oct 20, 2016 at 12:19 AM, T L  wrote:

>
>
> On Thursday, October 20, 2016 at 3:25:18 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Wed, Oct 19, 2016 at 11:38 AM, Michael Jones 
>> wrote:
>> > As in a number of previous questions, this one was asked poorly and the
>> answers dance all around the intention. I had decided never to enter the
>> fray of these oddly-put assertion/half questions, but since this is
>> lingering, may I suggest that this is his real question:
>> >
>> > “can we have var-style declarations in the places where the shorthand
>> syntax is allowed?”
>> >
>> > elaborating…
>> >
>> > for i := 0; i < 10; i++ {…}
>> >
>> > might also allow
>> >
>> > for var i int; i < 10; i++ {…}
>> >
>> > and likewise in other short-variable-permitting contexts.
>> >
>> > Personally, it seems that the simplest argument in favor would be
>> orthogonality and the best argument in favor would be the natural creation
>> of multiple scope local variables. This “best” is not very strong, though,
>> since it is unclear to me how you could introduce variables of multiple
>> types.
>> >
>> > Not taking sides here…just feeling that the core issue was not
>> addressed. Nor was the much better question that was not asked, “why was
>> the decision made in Go not to allow non-short variable declarations in
>> these contexts?”
>>
>> Thanks for trying to clarify.
>>
>> I'm not sure I buy the orthogonality argument here.  I mean, why not
>> permit any statement in the first clause of a for statement?  Why
>> restrict it to just variable declarations?  But if we accept that it
>> is restricted, I think it seems reasonable to restrict only to short
>> variable declarations, since `for var i int` seems to me to be ugly.
>>
>> You can create multiple local variables in the for scope by writing, for
>> example
>> for a, b := 0, 10; a < b; a++ {
>> (That would work with var, too).
>>
>> Ian
>>
>
> I think the short form should be used as a supplement for the normal var
> form,
> Specifically, short form should be used in the situation new variable
> identifiers and old variable identifiers are hybrid,
> or the situation 

Re: [go-nuts] Should go vet catch people attempting to identify errors by inspecting err.Error()?

['Joe Tsai' via golang-nuts]

Hi Pietro,

I don't think this is a vet issue since doing that pattern is not a matter
of correctness, but more about style.

This lint issue (https://github.com/golang/lint/issues/232) is tracking
things we may want to add to golint to alert on these types of abuse.

JT

On Thu, Oct 20, 2016 at 11:16 AM, Chris Manghane  wrote:

> +joetsai, who has been thinking about this a lot recently
>
> On Thu, Oct 20, 2016 at 11:10 AM, Pietro Gagliardi 
> wrote:
>
>> It seems that something about the way the error interface is designed is
>> not intuitive enough for some, because a number of people on the IRC
>> channel keep coming up asking what the best way to check for a specific
>> error is — and their first instinct is to scan the contents of the string
>> returned by the Error() method, which is wrong.
>>
>> I'm not sure how to solve this problem once and for all, but we could
>> probably bandage it by having vet report such misuse. A basic
>> implementation would be something like
>>
>> if err.Error() == "file not found" {
>> // vet should say that is not how to identify an error
>> // slightly smarter: suggest to use os.IsNotExist(err)
>> }
>>
>> How feasible is this? Is catching all possible variations of this mistake
>> too difficult of a problem to solve? Is there a better way?
>>
>> --
>> 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] Should go vet catch people attempting to identify errors by inspecting err.Error()?

['Chris Manghane' via golang-nuts]

+joetsai, who has been thinking about this a lot recently

On Thu, Oct 20, 2016 at 11:10 AM, Pietro Gagliardi 
wrote:

> It seems that something about the way the error interface is designed is
> not intuitive enough for some, because a number of people on the IRC
> channel keep coming up asking what the best way to check for a specific
> error is — and their first instinct is to scan the contents of the string
> returned by the Error() method, which is wrong.
>
> I'm not sure how to solve this problem once and for all, but we could
> probably bandage it by having vet report such misuse. A basic
> implementation would be something like
>
> if err.Error() == "file not found" {
> // vet should say that is not how to identify an error
> // slightly smarter: suggest to use os.IsNotExist(err)
> }
>
> How feasible is this? Is catching all possible variations of this mistake
> too difficult of a problem to solve? Is there a better way?
>
> --
> 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] Should go vet catch people attempting to identify errors by inspecting err.Error()?

[Pietro Gagliardi]

It seems that something about the way the error interface is designed is not 
intuitive enough for some, because a number of people on the IRC channel keep 
coming up asking what the best way to check for a specific error is — and their 
first instinct is to scan the contents of the string returned by the Error() 
method, which is wrong.

I'm not sure how to solve this problem once and for all, but we could probably 
bandage it by having vet report such misuse. A basic implementation would be 
something like

if err.Error() == "file not found" {
// vet should say that is not how to identify an error
// slightly smarter: suggest to use os.IsNotExist(err)
}

How feasible is this? Is catching all possible variations of this mistake too 
difficult of a problem to solve? Is there a better way?

-- 
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: Tooling experience feedback

[Aram Hăvărneanu]

On Wed, Oct 19, 2016 at 7:27 PM, Nate Finch  wrote:
> Please give us an easy way to ensure all tests in a list of packages compile

Do something like this:

go test -toolexec wrapper -exec success pkgs...

Where wrapper is a binary that dispatches to the compiler, but a nop
when called with the linker, and success is a binary that just exits
successfully.

-- 
Aram Hăvărneanu

-- 
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] Interface Pitfalls and Harnessing io.Reader

[Joshua Rubin]

I just put together some thoughts to try to help newcomers to Go start to 
grasp interfaces. It walks through some steps that I've seen people coming 
from languages like Perl go through. I'd really appreciate any any vetting, 
comments or critiques you could offer.

https://jrub.in/golang-interface-pitfalls-and-io-reader-a57e2d8842a2

Much thanks!

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

Re: [go-nuts] Hosting godoc internally for private git server

[Pietro Gagliardi]

You can go get golang.org/x/tools/cmd/godoc and run the godoc tool itself, 
which will imitate golang.org. This is different from godoc.org; that is harder 
to host locally.

> On Oct 20, 2016, at 1:13 PM, Kareem Gan  wrote:
> 
> Hello.
> 
> Is it possible to host godoc internally because we have our own git server 
> and would like to host godoc internally so we can build documentation for our 
> golang repositories.
> -- 
> Best,
> 
> Kareem Gan
> 01010011 01000101
> 
> -- 
> 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] Hosting godoc internally for private git server

[Kareem Gan]

Hello.

Is it possible to host godoc internally because we have our own git server
and would like to host godoc internally so we can build documentation for
our golang repositories.
-- 
Best,

Kareem Gan
01010011 01000101

-- 
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: How to setup go-swagger for an existing project to generate API docs

[Nathan Kerr]

I just tried this out and discovered that an operationId is required for 
swagger:route:

// swagger:route GET /profile getProfile


tags go between the path and the operationId:

// swagger:route GET /profile tag1 tag2 getProfile


Hope this helps.

On Monday, October 17, 2016 at 7:01:52 AM UTC+2, SakShak wrote:
>
> I have an existing project that needs a UI for the API. I want to use go 
> swagger but I am completely confused
> https://github.com/go-swagger/go-swagger/tree/master/examples/todo-list
>
> I want to set it up so I add annotations in the code and then run the 
> command swagger generate spec and it would generate the spec
>
> However whenever I run it, it prints 
> {"swagger":"2.0","paths":{},"definitions":{}}
>
> My project structure is as follows
>
> project/ 
>   main.go
>   api/
> router.go
>
> In main.go I have this annotation
>
> //go:generate swagger generate spec
> package main
>
> In router above one of my handlers I have this annotation
>
> // swagger:route GET /profile
> //
> // Gets profile of user
> //
> // Produces:
> // - application/json
> // - application/x-protobuf
> //
> // Schemes: http, https, ws, wss
> //
> // Security:
> //   api_key:
> //   oauth: read, write
> //
> // Responses:
> //   default: genericError
> //   200: someResponse
> //   422: validationError
> r.GET("/profile", profileHandler
>
> I've been stuck trying to set up an api generator for a while. Any help is 
> much appreciated. If you have experience setting it up, please let me know 
> how you did 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] What is called reference values in Golang?

[Ian Lance Taylor]

On Thu, Oct 20, 2016 at 6:47 AM, T L  wrote:
>
> On Thursday, October 20, 2016 at 4:46:52 PM UTC+8, Dave Cheney wrote:
>>
>> What is a pointer wrapper value?
>
>
> struct {
>p *T
> }
>
>>
>>
>> in all seriousness, if you review the git history of the Go spec you'll
>> find the word "reference" was purged about two years ago, in effect, to try
>> to stem these discussions.
>
>
> Yes, I found many old docs and old web pages are still using the word
> "reference value".
> I think it is an unnecessary word. The concepts of values and pointer values
> are sufficient to understand Golang values well.

I have a minor objection.  I don't know what a "reference value" is.
Alan spoke about "reference types", and sometimes, in the past, before
we realized that it was confusing, the Go docs also talked about
"reference types."

I don't think we ever talked about "reference values."  Perhaps a
"reference value" is a value whose type is a "reference type."
However, people (not Go people, computer programming people in
general) also talk about "passing by reference" as opposed to "passing
by value", so combining the two opposing terms "reference" and "value"
into a single phrase is confusing.

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] How to build my own godoc

[FancyGo]

Hi all, I have download source code of godoc. But I have no idea how to 
build it. Because I have modified the source code, so I don't want use the 
bin godoc.

-- 
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] Like "inquirer" cli...

[luismanolo]

Hi, from Spain.
Does anyone know of a cli like inquirer for golang?

https://github.com/sboudrias/Inquirer.js

Thanks a lot.

-- 
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: Golang and WebAssembly

[Arif Hussain]

I loved the idea of Go to Js transpiler. The only problem I had with 
Gopherjs was that it was creating huge output files, so I don't think it 
will be great for production right now.

On Wednesday, July 8, 2015 at 8:51:29 AM UTC+5, andrewc...@gmail.com wrote:
>
> Fyi, Go already works in the front end with 
> https://github.com/gopherjs/gopherjs. As to whether there will ever be an 
> official Webassembly target for Go, I will leave it for someone else to say.
>
> On Wednesday, July 8, 2015 at 1:08:22 PM UTC+12, Ilya Kowalewski wrote:
>>
>> Salute nuts,
>>
>> I read about WebAssembly (WA) recently and this topic haven't left my 
>> head ever since. Am I right that if we had a Go-to-WA translator when 
>> actually becomes standard, we'd been able to run Go applications on the 
>> front-end? That makes hell lot of sense to me. We could kill JavaScript, 
>> once and for all. Among all the modern languages, Go seems to be a pretty 
>> great candidate for such a JS-killer.
>>
>> Go team, are you generally going to look into this topic in the near 
>> future? IIRC, Google loved Go, e.g. for networking stuff, who knows, maybe 
>> you guys would love it for front-end?
>>
>> Best regards,
>> Ilya Kowalewski
>>
>

-- 
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] What is called reference values in Golang?

[T L]

On Thursday, October 20, 2016 at 10:34:41 PM UTC+8, T L wrote:
>
>
>
> On Thursday, October 20, 2016 at 9:58:46 PM UTC+8, T L wrote:
>>
>>
>>
>> On Thursday, October 20, 2016 at 7:31:25 PM UTC+8, Val wrote:
>>>
>>> I like Alan's "useful definition" of a semantically reference type, 
>>> which involves shared mutable state.
>>>
>>> About the string type, I also like the implementation detail that
>>>   
>>> var string t = s
>>>
>>> is O(1) in memory and running time, i.e. it happens internally to "copy 
>>> the reference, not the bytes" :  see 
>>> https://play.golang.org/p/p-PD_yOnw6
>>> It usually doesn't make much of a difference because most strings are 
>>> short, and also they are not the best data structure to manipulate data 
>>> (unlike []byte). But I take this implementation detail into account when I 
>>> want to optimize code, especially to reduce the need for memory allocation.
>>>
>>
>> So, comparing two long same stings at the first time may spend much time?
>>
>
> It looks golang 1.7.1 doesn't release one copy of underlying data after 
> comparings:
>
> https://play.golang.org/p/Lu9FZ9iqn6
> https://play.golang.org/p/-wE2oUGce1
>

filed an issue: 
https://github.com/golang/go/issues/17526#issuecomment-255142005
and closed by the lighting issue closer. :)
 

>
>  
>
>>
>> It looks strings are much like interfaces here: 
>> https://play.golang.org/p/fEzxkzLfS2
>>  
>>
>>>
>>> On Wednesday, October 19, 2016 at 6:44:26 PM UTC+2, adon...@google.com 
>>> wrote:


 Jan is write that the term does not appear in the spec, but I think 
 it's possible to come up with a useful definition of a reference type that 
 applies to all ALGOL-like languages: a reference type is one whose values 
 indirectly refer to mutable state.  So, pointers are obviously references, 
 as are slices, maps, and channels.  But a string is not a reference 
 because, although internally it contains a pointer, you cannot mutate the 
 array of bytes to which it refers.  Functions may be references, because a 
 closure may refer to lexically enclosing variables.  Structs and arrays 
 are 
 references if their elements contain references.  An interface value is a 
 reference if its payload contains a references.

 The essence of a reference is that copying one creates a new alias for 
 its underlying state, and changes made via one alias are visible to all 
 others.  This definition is not absolute: a pointer to an immutable data 
 structure, for example, can be considered to have "value" (non-reference) 
 semantics since although it points to a variable, that variable can never 
 be changed.




-- 
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] the defer list

[Konstantin Khomoutov]

On Wed, 19 Oct 2016 15:35:40 -0700 (PDT)
andrew.sm...@miracl.com wrote:

[...]
> Im considering a scheme where I push every CString onto an
> implementation of a stack, and then call defer once. Im sure some
> people might think it overkill... Kinda like this :
> 
> func Outer(arg1 string, arg2 string, arg3 string, arg4 string) Return
> { stack := NewStack()
> defer stack.Destroy()
> return wrapReturn(
> C.inner(
> NewStackCString(arg1, stack).p,
> NewStackCString(arg2, stack).p,
> NewStackCString(arg3, stack).p,
> NewStackCString(arg4, stack).p))
> }
[...]

I think something like this should work in Go almost unmodified --
just you won't have a system-provided "defer list", will have a single
deferred execution of stack.Destroy() and have your own implementation
of that stack type.

Something like this:

8<
package main

import "fmt"

type dtor func()

type cleanup struct {
dts []dtor
}

func (c *cleanup) Add(d dtor) {
c.dts = append(c.dts, d)
}

func (c *cleanup) Cleanup() {
for _, f := range c.dts {
f()
}
}

type Foo struct{}

func (f Foo) Close() {
fmt.Println("Foo.Close()")
}

type Bar struct{}

func (b Bar) CFree() {
fmt.Println("Bar.CFree()")
}

func foo() {
var dts cleanup
defer dts.Cleanup()

foo := Foo{}
dts.Add(foo.Close)

bar := Bar{}
dts.Add(bar.CFree)
}

func main() {
foo()
}
8<

(Playground link: https://play.golang.org/p/TqCfBfZb_X).


BTW I found myself doing something much like this in some of my C#
projects to avoid nesting hell of

  using (...acquire resource...) {
using (...acquire resource...) {
  ...etc ad nauseum
  }

whereas you have a stack-like data type which implements IDisposable,
and you just have a single using() { ... } block for it inside which
you add particular resources to be destroyed to that instance, and at
the end of the block it's told to destroy itself and then it destroys
whatever resources have been added to 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] What is called reference values in Golang?

[T L]

On Thursday, October 20, 2016 at 9:58:46 PM UTC+8, T L wrote:
>
>
>
> On Thursday, October 20, 2016 at 7:31:25 PM UTC+8, Val wrote:
>>
>> I like Alan's "useful definition" of a semantically reference type, which 
>> involves shared mutable state.
>>
>> About the string type, I also like the implementation detail that
>>   
>> var string t = s
>>
>> is O(1) in memory and running time, i.e. it happens internally to "copy 
>> the reference, not the bytes" :  see https://play.golang.org/p/p-PD_yOnw6
>> It usually doesn't make much of a difference because most strings are 
>> short, and also they are not the best data structure to manipulate data 
>> (unlike []byte). But I take this implementation detail into account when I 
>> want to optimize code, especially to reduce the need for memory allocation.
>>
>
> So, comparing two long same stings at the first time may spend much time?
>

It looks golang 1.7.1 doesn't release one copy of underlying data after 
comparings:

https://play.golang.org/p/Lu9FZ9iqn6
https://play.golang.org/p/-wE2oUGce1
 

>
> It looks strings are much like interfaces here: 
> https://play.golang.org/p/fEzxkzLfS2
>  
>
>>
>> On Wednesday, October 19, 2016 at 6:44:26 PM UTC+2, adon...@google.com 
>> wrote:
>>>
>>>
>>> Jan is write that the term does not appear in the spec, but I think it's 
>>> possible to come up with a useful definition of a reference type that 
>>> applies to all ALGOL-like languages: a reference type is one whose values 
>>> indirectly refer to mutable state.  So, pointers are obviously references, 
>>> as are slices, maps, and channels.  But a string is not a reference 
>>> because, although internally it contains a pointer, you cannot mutate the 
>>> array of bytes to which it refers.  Functions may be references, because a 
>>> closure may refer to lexically enclosing variables.  Structs and arrays are 
>>> references if their elements contain references.  An interface value is a 
>>> reference if its payload contains a references.
>>>
>>> The essence of a reference is that copying one creates a new alias for 
>>> its underlying state, and changes made via one alias are visible to all 
>>> others.  This definition is not absolute: a pointer to an immutable data 
>>> structure, for example, can be considered to have "value" (non-reference) 
>>> semantics since although it points to a variable, that variable can never 
>>> be changed.
>>>
>>>
>>>

-- 
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] The [low:high] expression for creating slices

[Konstantin Khomoutov]

On Thu, 20 Oct 2016 09:45:07 +0100
Nyah Check  wrote:

> My understanding of the [low:high] expression is Go is creating
> slices when you're copying data from an already existing slice. Is it
> possible to use the expression when you're creating a slice without
> copying data from another slice? If yes, I'll appreciate some use
> cases.

Please read [1] and [2].

1. https://blog.golang.org/go-slices-usage-and-internals
2. https://blog.golang.org/slices

-- 
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: Append consecutive slices, same underlying array

[T L]

yes, you are right. You can file an issue at 
https://github.com/golang/go/issues

On Thursday, October 20, 2016 at 9:11:14 PM UTC+8, Nick Patavalis wrote:
>
> Hi,
>
> It seems that the built-in append does not check for a situation like
> the following, and needlessly copies data, when it could avoid it.
>
>   func appendBytes(a, b []byte) []byte {
>   if len(b) == 0 {
>   return a
>   }
> // Shouldn't append() check for something like this?
>   if cap(a) >= len(a)+len(b) && [:len(a)+1][len(a)] == [0] {
>   return a[:len(a)+len(b)]
>   }
>   return append(a, b...)
>   }
>
> If I'm following the breadcrumbs correctly, they lead to the fact that
> runtime-memmove() does *not* short-circuit when source and destination
> addresses are the same (I may be wrong, though).
>
> Running the benchmark at:
>
>   https://gist.github.com/npat-efault/f055654633f43d0ef771d38657fd499e
>
> for any value of N, demonstrates this.
>
> Rather marginal (and possibly very contrived) case, but I though I'd
> point it out...
>
> /npat
>
>

-- 
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] Reusable regex in Golang for rule system.

['Paul Borman' via golang-nuts]

Check out time.Parse :

t := time.Parse("2006-01-02", inputString)
year := t.Year()
month := t.Month()
day := t.Day()

On Thu, Oct 20, 2016 at 5:06 AM, David Sofo  wrote:

>
> Hi,
> I ma new to Go Regex.
>
> I want to have a set of reusable rules of regex in golang easy to edit or
> update. For example a regex for date can be splitted in day, month and year
> :
>
> year=d{4}
> month=d{2}
> day=d{2}
>
> and for date we can have as following: date=year-month-day
>
>
> Is it possible in golang? Can we add human readable comment to regex?
>
> Any suggestion is welcome.
>
> Thank you
> David
>
>
>
>
> --
> 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] What is called reference values in Golang?

[T L]

On Thursday, October 20, 2016 at 7:31:25 PM UTC+8, Val wrote:
>
> I like Alan's "useful definition" of a semantically reference type, which 
> involves shared mutable state.
>
> About the string type, I also like the implementation detail that
>   
> var string t = s
>
> is O(1) in memory and running time, i.e. it happens internally to "copy 
> the reference, not the bytes" :  see https://play.golang.org/p/p-PD_yOnw6
> It usually doesn't make much of a difference because most strings are 
> short, and also they are not the best data structure to manipulate data 
> (unlike []byte). But I take this implementation detail into account when I 
> want to optimize code, especially to reduce the need for memory allocation.
>

So, comparing two long same stings at the first time may spend much time?

It looks strings are much like interfaces here: 
https://play.golang.org/p/fEzxkzLfS2
 

>
> On Wednesday, October 19, 2016 at 6:44:26 PM UTC+2, adon...@google.com 
> wrote:
>>
>>
>> Jan is write that the term does not appear in the spec, but I think it's 
>> possible to come up with a useful definition of a reference type that 
>> applies to all ALGOL-like languages: a reference type is one whose values 
>> indirectly refer to mutable state.  So, pointers are obviously references, 
>> as are slices, maps, and channels.  But a string is not a reference 
>> because, although internally it contains a pointer, you cannot mutate the 
>> array of bytes to which it refers.  Functions may be references, because a 
>> closure may refer to lexically enclosing variables.  Structs and arrays are 
>> references if their elements contain references.  An interface value is a 
>> reference if its payload contains a references.
>>
>> The essence of a reference is that copying one creates a new alias for 
>> its underlying state, and changes made via one alias are visible to all 
>> others.  This definition is not absolute: a pointer to an immutable data 
>> structure, for example, can be considered to have "value" (non-reference) 
>> semantics since although it points to a variable, that variable can never 
>> be changed.
>>
>>
>>

-- 
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] What is called reference values in Golang?

[T L]

On Thursday, October 20, 2016 at 4:46:52 PM UTC+8, Dave Cheney wrote:
>
> What is a pointer wrapper value?
>

struct {
   p *T
}
 

>
> in all seriousness, if you review the git history of the Go spec you'll 
> find the word "reference" was purged about two years ago, in effect, to try 
> to stem these discussions.
>

Yes, I found many old docs and old web pages are still using the word 
"reference value".
I think it is an unnecessary word. The concepts of values and pointer 
values are sufficient to understand Golang values well.
 

>
> On Thursday, 20 October 2016 16:07:07 UTC+9, T L wrote:
>>
>>
>>
>> On Thursday, October 20, 2016 at 12:44:26 AM UTC+8, adon...@google.com 
>> wrote:
>>>
>>> On Wednesday, 19 October 2016 06:33:09 UTC-4, Jan Mercl wrote:

 On Wed, Oct 19, 2016 at 12:27 PM T L  wrote:

 Nothing. The language specification does not mention it.

 People use that term based on definitions specified for other 
 programming languages, but those are not always equal to each other.

>>>
>>> Jan is write that the term does not appear in the spec, but I think it's 
>>> possible to come up with a useful definition of a reference type that 
>>> applies to all ALGOL-like languages: a reference type is one whose values 
>>> indirectly refer to mutable state.  So, pointers are obviously references, 
>>> as are slices, maps, and channels.  But a string is not a reference 
>>> because, although internally it contains a pointer, you cannot mutate the 
>>> array of bytes to which it refers.  Functions may be references, because a 
>>> closure may refer to lexically enclosing variables.  Structs and arrays are 
>>> references if their elements contain references.  An interface value is a 
>>> reference if its payload contains a references.
>>>
>>> The essence of a reference is that copying one creates a new alias for 
>>> its underlying state, and changes made via one alias are visible to all 
>>> others.  This definition is not absolute: a pointer to an immutable data 
>>> structure, for example, can be considered to have "value" (non-reference) 
>>> semantics since although it points to a variable, that variable can never 
>>> be changed.
>>>
>>>
>> So reference values must be pointer related? Reference values can be 
>> direct pointer values or pointer wrapper values, people can modify the 
>> values pointed by the pointers directly or indirectly (through the methods 
>> or other mechanisms exposed on the reference value identifier)? 
>>
>

-- 
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: Golang should have a center packages index hosting like npm, rust crates

[T L]

On Thursday, October 20, 2016 at 4:43:08 PM UTC+8, Dave Cheney wrote:
>
> T L, I often hear this comment when a central repo for Go is 
> proposed/suggested/requested. Are you able to give details of the things 
> you do not like about Maven/npm/rubygems central repos. The most specific 
> the better please.
>
>
central repos are your fingerprint collectors. This is why I also don't use 
rss readers. 
When you update your dependencies or your feeds, you are identified without 
logging in.

Another reason is central repos weaken, if not break, the connections 
between the dependency projects and you.
 

> On Thursday, 20 October 2016 16:23:09 UTC+9, T L wrote:
>>
>>
>>
>> On Thursday, October 20, 2016 at 12:05:03 PM UTC+8, zixu mo wrote:
>>>
>>> Golang should have a center packages index hosting like npm, rust crates.
>>>
>>>
>>>
>>> For Rust : 
>>> https://crates.io/
>>>
>>> For JS:
>>> https://www.npmjs.com/ 
>>>
>>
>>>
>>> For PHP
>>> https://packagist.org/
>>>
>>> For Ruby
>>> https://rubygems.org/
>>>
>>>
>>
>> one reason I like Golang is there is no npm, maven etc for Golang.
>> :)
>>
>

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

[go-nuts] Re: Why does a "concurrent" Go GC phase appear to be stop-the-world?

[Will Sewell]

Interesting, that does sound like it could be the cause.

I just tried running the same benchmark on master 
(692df217ca21b6df8e4dc65538fcc90733e8900e), and I get the following results:

gc 1 @0.004s 3%: 0.009+0.41+0.049 ms clock, 0.036+0.11/0.36/0.12+0.19 ms 
cpu, 4->4->3 MB, 5 MB goal, 4 P
gc 2 @0.008s 4%: 0.008+0.80+0.035 ms clock, 0.034+0.097/0.67/0.16+0.14 ms 
cpu, 7->7->7 MB, 8 MB goal, 4 P
gc 3 @0.016s 3%: 0.010+0.91+0.044 ms clock, 0.041+0/0.31/0.79+0.17 ms cpu, 
13->15->14 MB, 15 MB goal, 4 P
gc 4 @0.032s 3%: 0.009+2.3+0.10 ms clock, 0.037+0.60/2.0/0.12+0.40 ms cpu, 
27->28->27 MB, 29 MB goal, 4 P
gc 5 @0.070s 3%: 0.010+7.6+0.068 ms clock, 0.043+0.79/5.4/8.5+0.27 ms cpu, 
51->53->51 MB, 54 MB goal, 4 P
gc 6 @0.149s 3%: 0.020+8.2+0.12 ms clock, 0.081+0.56/7.2/9.7+0.48 ms cpu, 
98->102->99 MB, 103 MB goal, 4 P
gc 7 @0.282s 4%: 0.028+21+0.082 ms clock, 0.11+10/20/1.9+0.32 ms cpu, 
190->195->190 MB, 198 MB goal, 4 P
gc 8 @0.568s 3%: 0.024+24+0.080 ms clock, 0.098+0/23/41+0.32 ms cpu, 
364->376->214 MB, 381 MB goal, 4 P
gc 9 @0.816s 3%: 0.008+27+0.072 ms clock, 0.035+0/25/34+0.29 ms cpu, 
412->420->213 MB, 428 MB goal, 4 P
gc 10 @1.064s 3%: 0.009+31+0.10 ms clock, 0.039+6.1/26/33+0.41 ms cpu, 
415->427->216 MB, 427 MB goal, 4 P

My manually calculated worst time for a call to mkMessage is 7.73812ms, 
which is much better than before. It's significantly faster than the worst 
wall clock time for the concurrent mark/scan phase, but it's also much 
slower than the worst STW phase. Do you know why this might be?

Best,
Will

On Wednesday, 19 October 2016 17:29:23 UTC+1, rhys.h...@gmail.com wrote:
>
> Yes, this sounds a lot like https://golang.org/issue/16293, where 
> goroutines that allocate memory while the garbage collector is running can 
> end up stalled for nearly the entire GC cycle, in programs where a large 
> amount of the memory is in a single allocation. For the program you've 
> shared, that would be the "channel" map. The bug is present in Go 1.5–1.7, 
> and is fixed in tip (via CL 23540).
>
> Do you still see the problem if you run the program with the current 
> development version of Go?
>
> On Wednesday, October 19, 2016 at 6:10:23 AM UTC-7, r...@golang.org wrote:
>>
>> This is likely 23540 .  
>>
>>
>> On Wednesday, October 19, 2016 at 8:32:18 AM UTC-4, Will Sewell wrote:
>>>
>>> Hey, I previously posted this on StackOverflow, but I was told this 
>>> mailing list would be a better forum for discussion.
>>>
>>> I am attempting to benchmark the maximum STW GC pause time for different 
>>> numbers of heap objects. To do this I have written a simple benchmark that 
>>> pushes and pops messages from a map:
>>>
>>> package main
>>>
>>> type message []byte
>>>
>>> type channel map[int]message
>>>
>>> const (
>>> windowSize = 20
>>> msgCount = 100
>>> )
>>>
>>> func mkMessage(n int) message {
>>> m := make(message, 1024)
>>> for i := range m {
>>> m[i] = byte(n)
>>> }
>>> return m
>>> }
>>>
>>>
>>> func pushMsg(c *channel, highID int) {
>>> lowID := highID - windowSize
>>> m := mkMessage(highID)
>>> (*c)[highID] = m
>>> if lowID >= 0 {
>>> delete(*c, lowID)
>>> }
>>> }
>>>
>>>
>>> func main() {
>>> c := make(channel)
>>> for i := 0; i < msgCount; i++ {
>>> pushMsg(, i)
>>> }
>>> }
>>>
>>> I ran this with GODEBUG=gctrace=1 , 
>>> and on my machine the output is:
>>>
>>> gc 1 @0.004s 2%: 0.007+0.44+0.032 ms clock, 0.029+0.22/0.20/0.28+0.12 
>>> ms cpu, 4->4->3 MB, 5 MB goal, 4 P
>>> gc 2 @0.009s 3%: 0.007+0.64+0.042 ms clock, 0.030+0/0.53/0.18+0.17 ms 
>>> cpu, 7->7->7 MB, 8 MB goal, 4 P
>>> gc 3 @0.019s 1%: 0.007+0.99+0.037 ms clock, 0.031+0/0.13/1.0+0.14 ms cpu
>>> , 13->13->13 MB, 14 MB goal, 4 P
>>> gc 4 @0.044s 2%: 0.009+2.3+0.032 ms clock, 0.039+0/2.3/0.30+0.13 ms cpu, 
>>> 25->25->25 MB, 26 MB goal, 4 P
>>> gc 5 @0.081s 1%: 0.009+9.2+0.082 ms clock, 0.039+0/0.32/9.7+0.32 ms cpu, 
>>> 49->49->48 MB, 50 MB goal, 4 P
>>> gc 6 @0.162s 0%: 0.020+10+0.078 ms clock, 0.082+0/0.28/11+0.31 ms cpu, 
>>> 93->93->91 MB, 96 MB goal, 4 P
>>> gc 7 @0.289s 0%: 0.020+27+0.092 ms clock, 0.080+0/0.95/28+0.37 ms cpu, 
>>> 178->178->173 MB, 182 MB goal, 4 P
>>> gc 8 @0.557s 1%: 0.023+38+0.086 ms clock, 0.092+0/38/10+0.34 ms cpu, 337
>>> ->339->209 MB, 346 MB goal, 4 P
>>> gc 9 @0.844s 1%: 0.008+40+0.077 ms clock, 0.032+0/5.6/46+0.30 ms cpu, 
>>> 407->409->211 MB, 418 MB goal, 4 P
>>> gc 10 @1.100s 1%: 0.009+43+0.047 ms clock, 0.036+0/6.6/50+0.19 ms cpu, 
>>> 411->414->212 MB, 422 MB goal, 4 P
>>> gc 11 @1.378s 1%: 0.008+45+0.093 ms clock, 0.033+0/6.5/52+0.37 ms cpu, 
>>> 414->417->213 MB, 425 MB goal, 4 P
>>>
>>> My version of Go is:
>>>
>>> $ go version
>>> go version go1.7.1 darwin/amd64
>>>
>>> From the above results, the longest wall clock STW pause time is 
>>> 0.093ms. Great!
>>>
>>> However as a sanity check I also manually timed how long 

[go-nuts] Append consecutive slices, same underlying array

[Nick Patavalis]

Hi,

It seems that the built-in append does not check for a situation like
the following, and needlessly copies data, when it could avoid it.

  func appendBytes(a, b []byte) []byte {
  if len(b) == 0 {
  return a
  }
  // Shouldn't append() check for something like this?
  if cap(a) >= len(a)+len(b) && [:len(a)+1][len(a)] == [0] {
  return a[:len(a)+len(b)]
  }
  return append(a, b...)
  }

If I'm following the breadcrumbs correctly, they lead to the fact that
runtime-memmove() does *not* short-circuit when source and destination
addresses are the same (I may be wrong, though).

Running the benchmark at:

  https://gist.github.com/npat-efault/f055654633f43d0ef771d38657fd499e

for any value of N, demonstrates this.

Rather marginal (and possibly very contrived) case, but I though I'd
point it out...

/npat

-- 
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] Reusable regex in Golang for rule system.

[David Sofo]

Hi,
I ma new to Go Regex.

I want to have a set of reusable rules of regex in golang easy to edit or 
update. For example a regex for date can be splitted in day, month and year 
:

year=d{4}
month=d{2}
day=d{2}

and for date we can have as following: date=year-month-day


Is it possible in golang? Can we add human readable comment to regex? 

Any suggestion is welcome.

Thank you
David




-- 
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] What is called reference values in Golang?

[Val]

I like Alan's "useful definition" of a semantically reference type, which 
involves shared mutable state.

About the string type, I also like the implementation detail that
  
var string t = s

is O(1) in memory and running time, i.e. it happens internally to "copy the 
reference, not the bytes" :  see https://play.golang.org/p/p-PD_yOnw6
It usually doesn't make much of a difference because most strings are 
short, and also they are not the best data structure to manipulate data 
(unlike []byte). But I take this implementation detail into account when I 
want to optimize code, especially to reduce the need for memory allocation.

On Wednesday, October 19, 2016 at 6:44:26 PM UTC+2, adon...@google.com 
wrote:
>
>
> Jan is write that the term does not appear in the spec, but I think it's 
> possible to come up with a useful definition of a reference type that 
> applies to all ALGOL-like languages: a reference type is one whose values 
> indirectly refer to mutable state.  So, pointers are obviously references, 
> as are slices, maps, and channels.  But a string is not a reference 
> because, although internally it contains a pointer, you cannot mutate the 
> array of bytes to which it refers.  Functions may be references, because a 
> closure may refer to lexically enclosing variables.  Structs and arrays are 
> references if their elements contain references.  An interface value is a 
> reference if its payload contains a references.
>
> The essence of a reference is that copying one creates a new alias for its 
> underlying state, and changes made via one alias are visible to all others. 
>  This definition is not absolute: a pointer to an immutable data structure, 
> for example, can be considered to have "value" (non-reference) semantics 
> since although it points to a variable, that variable can never be changed.
>
>
>

-- 
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: Proposal: add "future" internal type (similar to channel)

[Jesper Louis Andersen]

On Mon, Oct 17, 2016 at 5:08 PM adonovan via golang-nuts <
golang-nuts@googlegroups.com> wrote:

>
> Go does not take a strong Erlang-like stance against concurrency with
> shared variables, so mutexes really are critical to Go's concurrency.
>
>
>
Even Erlang took a more loose stance towards concurrency with shared
variables. You have ETS tables, which acts as tables of M-Vars (in the
setting of how such vars work in Id or Haskell). In turn, they act as a way
to share data between processes without resorting to message passing.

The primary reason is efficiency. An ETS table has sub-microsecond lookup
time (because you still need at least two locks in the runtime to grab a
value, and then you have to copy it into your own memory space). But it
avoids a context switch when you look up. They are used as an in-memory
backing store for the mnesia database, among other things, but finds broad
use in most Erlang applications.

As for the concept of future, I feel it is a crutch. If you have channels,
mailboxes or some other concurrency pattern, I've often preferred tailoring
a solution to the problem space, rather than trying to get things to work
with futures. I'm also skeptic towards its need to be efficient. A
long-running computation in the background is often measured in
milli-seconds and a channel operates under the 1ms barrier in practice. I'd
much rather see some uses of a future primitive where it is applicable and
not solvable with a bit of simple channel code, while also being necessary
for efficiency reasons.

Also note that most broadcast-like patterns are more efficient if the
subscribers pull their data. See, for instance, the Disruptor pattern in
Java, which would be a nice construction to implement rather than
implementing something such as futures (which I feel is a special case of a
one-slotted disruptor).

-- 
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] The [low:high] expression for creating slices

[Nyah Check]

>
> ng to that region in memory at run time? Or does it just reference only
> that part of the existing slice. Like it's done with pointers?
>
> "If the sliced operand of a valid slice expression is a nil slice, the
> result is a nil slice. Otherwise, the result shares its underlying array
> with the operand."[0]
>
>   [0]: https://golang.org/ref/spec#Slice_expressions
>
>
Thanks

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

Re: [go-nuts] The [low:high] expression for creating slices

[Jan Mercl]

On Thu, Oct 20, 2016 at 11:33 AM Nyah Check  wrote:

> I thought that expression allocates memory corresponding to that region
in memory at run time? Or does it just reference only that part of the
existing slice. Like it's done with pointers?

"If the sliced operand of a valid slice expression is a nil slice, the
result is a nil slice. Otherwise, the result shares its underlying array
with the operand."[0]

  [0]: https://golang.org/ref/spec#Slice_expressions

-- 

-j

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

Re: [go-nuts] The [low:high] expression for creating slices

[Nyah Check]

Hi Jan,


>
> Slicing does not copy any of the backing array items.
>
>
> I thought that expression allocates memory corresponding to that region in
memory at run time? Or does it just reference only that part of the
existing slice. Like it's done with pointers?

Cheers!

-- 
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] The [low:high] expression for creating slices

[Jan Mercl]

On Thu, Oct 20, 2016 at 10:45 AM Nyah Check  wrote:

> My understanding of the [low:high] expression is Go is creating slices
when you're copying data from an already existing slice. Is it possible to
use the expression when you're creating a slice without copying data from
another slice? If yes, I'll appreciate some use cases.

Slicing does not copy any of the backing array items.

-- 

-j

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

Re: [go-nuts] What is called reference values in Golang?

[Dave Cheney]

What is a pointer wrapper value?

in all seriousness, if you review the git history of the Go spec you'll 
find the word "reference" was purged about two years ago, in effect, to try 
to stem these discussions.

On Thursday, 20 October 2016 16:07:07 UTC+9, T L wrote:
>
>
>
> On Thursday, October 20, 2016 at 12:44:26 AM UTC+8, adon...@google.com 
> wrote:
>>
>> On Wednesday, 19 October 2016 06:33:09 UTC-4, Jan Mercl wrote:
>>>
>>> On Wed, Oct 19, 2016 at 12:27 PM T L  wrote:
>>>
>>> Nothing. The language specification does not mention it.
>>>
>>> People use that term based on definitions specified for other 
>>> programming languages, but those are not always equal to each other.
>>>
>>
>> Jan is write that the term does not appear in the spec, but I think it's 
>> possible to come up with a useful definition of a reference type that 
>> applies to all ALGOL-like languages: a reference type is one whose values 
>> indirectly refer to mutable state.  So, pointers are obviously references, 
>> as are slices, maps, and channels.  But a string is not a reference 
>> because, although internally it contains a pointer, you cannot mutate the 
>> array of bytes to which it refers.  Functions may be references, because a 
>> closure may refer to lexically enclosing variables.  Structs and arrays are 
>> references if their elements contain references.  An interface value is a 
>> reference if its payload contains a references.
>>
>> The essence of a reference is that copying one creates a new alias for 
>> its underlying state, and changes made via one alias are visible to all 
>> others.  This definition is not absolute: a pointer to an immutable data 
>> structure, for example, can be considered to have "value" (non-reference) 
>> semantics since although it points to a variable, that variable can never 
>> be changed.
>>
>>
> So reference values must be pointer related? Reference values can be 
> direct pointer values or pointer wrapper values, people can modify the 
> values pointed by the pointers directly or indirectly (through the methods 
> or other mechanisms exposed on the reference value identifier)? 
>

-- 
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] The [low:high] expression for creating slices

[Nyah Check]

Hi Devs,

My understanding of the [low:high] expression is Go is creating slices when
you're copying data from an already existing slice. Is it possible to use
the expression when you're creating a slice without copying data from
another slice? If yes, I'll appreciate some use cases.

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

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

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

[Dave Cheney]

For some background, I'm trying to flesh out the concerns of the various 
personas who would interact with a central repository.

https://docs.google.com/document/d/10jbJLkmQgpi1CxHKuO75Av1tKYgtOBSjzX5Z9hnG0vI/edit?usp=sharing

On Thursday, 20 October 2016 17:43:08 UTC+9, Dave Cheney wrote:
>
> T L, I often hear this comment when a central repo for Go is 
> proposed/suggested/requested. Are you able to give details of the things 
> you do not like about Maven/npm/rubygems central repos. The most specific 
> the better please.
>
> On Thursday, 20 October 2016 16:23:09 UTC+9, T L wrote:
>>
>>
>>
>> On Thursday, October 20, 2016 at 12:05:03 PM UTC+8, zixu mo wrote:
>>>
>>> Golang should have a center packages index hosting like npm, rust crates.
>>>
>>>
>>>
>>> For Rust : 
>>> https://crates.io/
>>>
>>> For JS:
>>> https://www.npmjs.com/ 
>>>
>>
>>>
>>> For PHP
>>> https://packagist.org/
>>>
>>> For Ruby
>>> https://rubygems.org/
>>>
>>>
>>
>> one reason I like Golang is there is no npm, maven etc for Golang.
>> :)
>>
>

-- 
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: Golang should have a center packages index hosting like npm, rust crates

[Dave Cheney]

T L, I often hear this comment when a central repo for Go is 
proposed/suggested/requested. Are you able to give details of the things 
you do not like about Maven/npm/rubygems central repos. The most specific 
the better please.

On Thursday, 20 October 2016 16:23:09 UTC+9, T L wrote:
>
>
>
> On Thursday, October 20, 2016 at 12:05:03 PM UTC+8, zixu mo wrote:
>>
>> Golang should have a center packages index hosting like npm, rust crates.
>>
>>
>>
>> For Rust : 
>> https://crates.io/
>>
>> For JS:
>> https://www.npmjs.com/ 
>>
>
>>
>> For PHP
>> https://packagist.org/
>>
>> For Ruby
>> https://rubygems.org/
>>
>>
>
> one reason I like Golang is there is no npm, maven etc for Golang.
> :)
>

-- 
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] gocql db creation at Application

[laxman . vallandas]

Hi All,

Triggering creation/alteration of db schema from two applications at same 
point of time is causing below error:
java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
org.apache.cassandra.exceptions.ConfigurationException: Column family ID 
mismatch (found cba88010-9695-11e6-ba16-3d2bc4159375; expected 
cba0b7e0-9695-11e6-ba16-3d2bc4159375.

Another way of doing this is to keep the db creation as an independent 
module.

Why is the first one failing. Does it have any issues creating schema via 
application. 

Thanks in advance.

---
LV

-- 
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: Golang should have a center packages index hosting like npm, rust crates

[T L]

On Thursday, October 20, 2016 at 12:05:03 PM UTC+8, zixu mo wrote:
>
> Golang should have a center packages index hosting like npm, rust crates.
>
>
>
> For Rust : 
> https://crates.io/
>
> For JS:
> https://www.npmjs.com/ 
>

>
> For PHP
> https://packagist.org/
>
> For Ruby
> https://rubygems.org/
>
>

one reason I like Golang is there is no npm, maven etc for Golang.
:)

-- 
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] Are short variable declarations necessary?

[T L]

On Thursday, October 20, 2016 at 3:25:18 AM UTC+8, Ian Lance Taylor wrote:
>
> On Wed, Oct 19, 2016 at 11:38 AM, Michael Jones  > wrote: 
> > As in a number of previous questions, this one was asked poorly and the 
> answers dance all around the intention. I had decided never to enter the 
> fray of these oddly-put assertion/half questions, but since this is 
> lingering, may I suggest that this is his real question: 
> > 
> > “can we have var-style declarations in the places where the shorthand 
> syntax is allowed?” 
> > 
> > elaborating… 
> > 
> > for i := 0; i < 10; i++ {…} 
> > 
> > might also allow 
> > 
> > for var i int; i < 10; i++ {…} 
> > 
> > and likewise in other short-variable-permitting contexts. 
> > 
> > Personally, it seems that the simplest argument in favor would be 
> orthogonality and the best argument in favor would be the natural creation 
> of multiple scope local variables. This “best” is not very strong, though, 
> since it is unclear to me how you could introduce variables of multiple 
> types. 
> > 
> > Not taking sides here…just feeling that the core issue was not 
> addressed. Nor was the much better question that was not asked, “why was 
> the decision made in Go not to allow non-short variable declarations in 
> these contexts?” 
>
> Thanks for trying to clarify. 
>
> I'm not sure I buy the orthogonality argument here.  I mean, why not 
> permit any statement in the first clause of a for statement?  Why 
> restrict it to just variable declarations?  But if we accept that it 
> is restricted, I think it seems reasonable to restrict only to short 
> variable declarations, since `for var i int` seems to me to be ugly. 
>
> You can create multiple local variables in the for scope by writing, for 
> example 
> for a, b := 0, 10; a < b; a++ { 
> (That would work with var, too). 
>
> Ian 
>

I think the short form should be used as a supplement for the normal var 
form, 
Specifically, short form should be used in the situation new variable 
identifiers and old variable identifiers are hybrid, 
or the situation only new variable identifiers exist.

But now, the short form in an inner block will shadow variables in outer 
block.
If we really want to shadow variables in outer block, then we can just use 
the normal var form.
Now the design makes the short form compete with the normal var form.

 

-- 
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] What is called reference values in Golang?

[T L]

On Thursday, October 20, 2016 at 12:44:26 AM UTC+8, adon...@google.com 
wrote:
>
> On Wednesday, 19 October 2016 06:33:09 UTC-4, Jan Mercl wrote:
>>
>> On Wed, Oct 19, 2016 at 12:27 PM T L  wrote:
>>
>> Nothing. The language specification does not mention it.
>>
>> People use that term based on definitions specified for other programming 
>> languages, but those are not always equal to each other.
>>
>
> Jan is write that the term does not appear in the spec, but I think it's 
> possible to come up with a useful definition of a reference type that 
> applies to all ALGOL-like languages: a reference type is one whose values 
> indirectly refer to mutable state.  So, pointers are obviously references, 
> as are slices, maps, and channels.  But a string is not a reference 
> because, although internally it contains a pointer, you cannot mutate the 
> array of bytes to which it refers.  Functions may be references, because a 
> closure may refer to lexically enclosing variables.  Structs and arrays are 
> references if their elements contain references.  An interface value is a 
> reference if its payload contains a references.
>
> The essence of a reference is that copying one creates a new alias for its 
> underlying state, and changes made via one alias are visible to all others. 
>  This definition is not absolute: a pointer to an immutable data structure, 
> for example, can be considered to have "value" (non-reference) semantics 
> since although it points to a variable, that variable can never be changed.
>
>
So reference values must be pointer related? Reference values can be direct 
pointer values or pointer wrapper values, people can modify the values 
pointed by the pointers directly or indirectly (through the methods or 
other mechanisms exposed on the reference value identifier)? 

-- 
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] What is called reference values in Golang?

[T L]

On Thursday, October 20, 2016 at 12:44:26 AM UTC+8, adon...@google.com 
wrote:
>
> On Wednesday, 19 October 2016 06:33:09 UTC-4, Jan Mercl wrote:
>>
>> On Wed, Oct 19, 2016 at 12:27 PM T L  wrote:
>>
>> Nothing. The language specification does not mention it.
>>
>> People use that term based on definitions specified for other programming 
>> languages, but those are not always equal to each other.
>>
>
> Jan is write that the term does not appear in the spec, but I think it's 
> possible to come up with a useful definition of a reference type that 
> applies to all ALGOL-like languages: a reference type is one whose values 
> indirectly refer to mutable state.  So, pointers are obviously references, 
> as are slices, maps, and channels.  But a string is not a reference 
> because, although internally it contains a pointer, you cannot mutate the 
> array of bytes to which it refers.  Functions may be references, because a 
> closure may refer to lexically enclosing variables.  Structs and arrays are 
> references if their elements contain references.  An interface value is a 
> reference if its payload contains a references.
>
> The essence of a reference is that copying one creates a new alias for its 
> underlying state, and changes made via one alias are visible to all others. 
>  This definition is not absolute: a pointer to an immutable data structure, 
> for example, can be considered to have "value" (non-reference) semantics 
> since although it points to a variable, that variable can never be changed.
>

So reference values must be pointer related? Reference values can be direct 
pointer values of pointer wrapper values, people can modify the values 
pointed by the pointers directly or indirectly (through the methods or 
other mechanisms exposed on the reference value identifier)?


 

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