[go-nuts] Force pointer at compile time to interface{} parameter

[hay]

Hi,

I've the following example code of correct version. 

func SomeFunction(itemPtr interface{}) {


//itemPtr must be pointer to struct and not struct.


}


func SomeFunctionCaller() {


u := UserRecord{}


SomeFunction(&u)


}


Above is the correct version, but some coders pass struct instead of 
pointer which causes run-time errors.

Bad version:

func SomeFunctionCaller() {


u := UserRecord{}


SomeFunction(u)


}


Is there a way to force "SomeFunction" to take pointers only at compile 
time?

Thanks and best regards,

-- 
You received this message because you are subscribed to the Google 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: Force pointer at compile time to interface{} parameter

[Volker Dobler]

> Is there a way to force "SomeFunction" to take pointers only at compile 
time?

No, sorry.

V.

-- 
You received this message because you are subscribed to the Google 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: Force pointer at compile time to interface{} parameter

[Robert Engels]

Aren’t all interface references passed as a pointer? It is a var that contains 
a pointer to the struct and a concrete type of the struct?

> On Nov 19, 2018, at 8:45 AM, Volker Dobler  wrote:
> 
> > Is there a way to force "SomeFunction" to take pointers only at compile 
> > time?
> 
> No, sorry.
> 
> V.
> 
> -- 
> You received this message because you are subscribed to the Google 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] Force pointer at compile time to interface{} parameter

[Chris Burkert]

Hello Hay,
with interface{} you explicitly allow everything. Instead you may consider
to restrict the accepted input in the first place - e.g. with a non-empty
interface.
Chris

hay  schrieb am Mo. 19. Nov. 2018 um 15:37:

> Hi,
>
> I've the following example code of correct version.
>
> func SomeFunction(itemPtr interface{}) {
>
>
> //itemPtr must be pointer to struct and not struct.
>
>
> }
>
>
> func SomeFunctionCaller() {
>
>
> u := UserRecord{}
>
>
> SomeFunction(&u)
>
>
> }
>
>
> Above is the correct version, but some coders pass struct instead of
> pointer which causes run-time errors.
>
> Bad version:
>
> func SomeFunctionCaller() {
>
>
> u := UserRecord{}
>
>
> SomeFunction(u)
>
>
> }
>
>
> Is there a way to force "SomeFunction" to take pointers only at compile
> time?
>
> Thanks and best regards,
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Re: [RFC] Dynamically instrumentation Go binaries

[Julio Guerra]

On Fri, Nov 16, 2018 at 12:06 AM Damian Gryski  wrote:

> One approach would be to augment the compiler to instrument the binary
> with the techniques outlined in:
>
> XRay: A Function Call Tracing System
> https://ai.google/research/pubs/pub45287
>
>
Yes, this is very likely the best option for performance and to avoid code
relocation at run time... Unfortunately, the go toolchain currently doesn't
have any "plugin" interface to add extra compilation stages.

-- 
Julio Guerra

-- 
You received this message because you are subscribed to the Google 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] [RFC] Dynamically instrumentation Go binaries

[Julio Guerra]

On Thu, Nov 15, 2018 at 7:55 PM Michael Jones 
wrote:

> You could study Rob Pike’s coverage/profiling tool to see how he adds and
> exploits basic block counting.  Good work as always.
>

Good idea, thanks. I had a look at the implementation of it, and at the way
it is integrated into the go toolchain. Unfortunately, it doesn't seem
possible to include extra compilation stages in the toolchain. I was hoping
for a way to insert an extra step to be able to modify the AST to insert
tracepoints.

So, for example, coverage is built inside `go test` by directly calling `go
cover`, and it doesn't use any plugin interface :(

-- 
Julio Guerra

-- 
You received this message because you are subscribed to the Google 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] [RFC] Dynamically instrumentation Go binaries

[Julio Guerra]

On Thu, Nov 15, 2018 at 9:57 PM Tristan Colgate  wrote:

> Maybe you mean something like support for linux uprobes?
> There is some discussion here:
> https://github.com/golang/go/issues/22008
> Google for "golang uprobes" picks up a couple of other links:
>
> http://www.brendangregg.com/blog/2017-01-31/golang-bcc-bpf-function-tracing.html
>
> https://kinvolk.io/blog/2017/09/an-update-on-gobpf---elf-loading-uprobes-more-program-types/
>

Ran a small benchmark using uprobes and there's no overhead for an io-bound
function, for a cpu-bound function, it is twice slower. So it may be a very
good solution for a first linux-only version, as I don't need return probes
(uretprobes seem to be a problem with Go's dynamic stack management).

-- 
Julio Guerra

-- 
You received this message because you are subscribed to the Google 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] I cannot access global var from package. Any idea?

[Juan Mamani]

Thanks for comments.

Good idea is to implement "package qualifier".  I will try it.
(Conclusion:  Go's rule doesn't apply for subdirectories.  If I'm wrong let
me know=)

Thanks again!

El vie., 16 de nov. de 2018 a la(s) 10:53, Jan Mercl (0xj...@gmail.com)
escribió:

>
> On Fri, Nov 16, 2018 at 2:40 PM Juan Mamani 
> wrote:
>
> > Why can not access global var MyGlobalVar? Any idea?
>
> Go has no global scope. It has universe scope, but you cannot define
> anything there. `MyGlobalVar` has package scope. To access an exported
> identifier imported from pacakge foo, you must use the package qualifier,
> like in `foo.MyGlobalVar` - in the first approximation. For other options
> lookup "dot imports" but that's seldom a good choice.
>
>
> > According Golang docs should be possible.
>
> No.
>
> > It works when both files are in the same directory.
>
> Yes, package scope contains all TLD declarations in a package. visible
> everywhere in the package.
>
> > But when db.go is in another doesn't work.
>
> WAI
>
> --
>
> -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.

[go-nuts] Determining latest released Go version

[Janne Snabb]

Dear Gophers,

How to determine the latest released Go version programmatically?

I am working on a system which needs to use the latest published Go 
version (whatever it is at the time it is run). I would rather not 
update it manually every time a new version comes out as this is error 
prone and slow. Also scraping and parsing golang.org web site contents 
seems silly.


I would like an URL which returns the latest released version number as 
text or as a redirect to the latest tarball or something similar.


Does such thing exist? Any other ideas?

--
Janne Snabb
sn...@epipe.com

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

Re: [go-nuts] Re: Force pointer at compile time to interface{} parameter

[Ian Denhardt]

>From an implementation standpoint they are passed by reference (The
representation is actually a pair (pointer to vtable, pointer to
object), but from a semantic standpoint the difference still matters,
because e.g. if the original value was a struct, it still can't be
mutated. There are use cases for what Volker is asking about in the
standard library, even:

package json // import "encoding/json"

func Unmarshal(data []byte, v interface{}) error
Unmarshal parses the JSON-encoded data and stores the result in the value
pointed to by v. If v is nil or not a pointer, Unmarshal returns an
InvalidUnmarshalError.

...

Quoting Robert Engels (2018-11-19 09:57:12)
>Aren't all interface references passed as a pointer? It is a var that
>contains a pointer to the struct and a concrete type of the struct?
>
>On Nov 19, 2018, at 8:45 AM, Volker Dobler
><[1]dr.volker.dob...@gmail.com> wrote:
>
>> Is there a way to force "SomeFunction" to take pointers only at
>compile time?
>No, sorry.
>V.
>
>--
>You received this message because you are subscribed to the Google
>Groups "golang-nuts" group.
>To unsubscribe from this group and stop receiving emails from it, send
>an email to [2]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [3]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 [4]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [5]https://groups.google.com/d/optout.
>
> Verweise
>
>1. mailto:dr.volker.dob...@gmail.com
>2. mailto:golang-nuts+unsubscr...@googlegroups.com
>3. https://groups.google.com/d/optout
>4. mailto:golang-nuts+unsubscr...@googlegroups.com
>5. 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: Force pointer at compile time to interface{} parameter

[Robert Engels]

But isn’t that just for safety. Meaning the unmarshall could use it as a 
pointer via reflection and mutate it (but that is probably not what the caller 
expects in Go) ?

> On Nov 19, 2018, at 2:04 PM, Ian Denhardt  wrote:
> 
> From an implementation standpoint they are passed by reference (The
> representation is actually a pair (pointer to vtable, pointer to
> object), but from a semantic standpoint the difference still matters,
> because e.g. if the original value was a struct, it still can't be
> mutated. There are use cases for what Volker is asking about in the
> standard library, even:
> 
> package json // import "encoding/json"
> 
> func Unmarshal(data []byte, v interface{}) error
>Unmarshal parses the JSON-encoded data and stores the result in the value
>pointed to by v. If v is nil or not a pointer, Unmarshal returns an
>InvalidUnmarshalError.
> 
>...
> 
> Quoting Robert Engels (2018-11-19 09:57:12)
>>   Aren't all interface references passed as a pointer? It is a var that
>>   contains a pointer to the struct and a concrete type of the struct?
>> 
>>   On Nov 19, 2018, at 8:45 AM, Volker Dobler
>>   <[1]dr.volker.dob...@gmail.com> wrote:
>> 
>>> Is there a way to force "SomeFunction" to take pointers only at
>>   compile time?
>>   No, sorry.
>>   V.
>> 
>>   --
>>   You received this message because you are subscribed to the Google
>>   Groups "golang-nuts" group.
>>   To unsubscribe from this group and stop receiving emails from it, send
>>   an email to [2]golang-nuts+unsubscr...@googlegroups.com.
>>   For more options, visit [3]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 [4]golang-nuts+unsubscr...@googlegroups.com.
>>   For more options, visit [5]https://groups.google.com/d/optout.
>> 
>> Verweise
>> 
>>   1. mailto:dr.volker.dob...@gmail.com
>>   2. mailto:golang-nuts+unsubscr...@googlegroups.com
>>   3. https://groups.google.com/d/optout
>>   4. mailto:golang-nuts+unsubscr...@googlegroups.com
>>   5. https://groups.google.com/d/optout
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] improve the reflection of golang

[iamybj via golang-nuts]

I am dong a simple sql library, but i need access some unexpected members 
in the std lib.
I find this project https://github.com/alangpierce/go-forceexport
but it is out of date.\

The authors of golang are some old programmer, but programming language 
processing for several ten years.
golang must borrow new features from c# and java.

reflection should be completely support package, it is not enough  now.

And also, in java and c#, user defined types are the same as runtime types 
for example these 2 languages can use for..each for user defined types.
but in go, for...range can only be applied in system types.

A lot of thing should be done, go process too slow...

-- 
You received this message because you are subscribed to the Google 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] net/http/httputil.ReverseProxy Expect: 100-continue broken?

[gregoryh]

Hi folks!

Hoping somebody can help me figure out what I'm doing wrong (or what Go's 
doing wrong in the small chance it's that).

It _seems_ Go's reverse proxy doesn't support 100 Continue when the backend 
is HTTP/2 (but I'm guessing).

I put up the sample at https://github.com/gholt/proxrepro -- just `go run 
main.go` and then look at the `trace` file that's output.

You can see where curl sends its request headers with the Expect: 
100-continue but the first thing it gets back is 200 OK and then 
"weirdness" ensues.

-- Greg Holt

-- 
You received this message because you are subscribed to the Google 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: Force pointer at compile time to interface{} parameter

[Ian Denhardt]

Quoting Robert Engels (2018-11-19 15:13:53)
> But isn’t that just for safety. Meaning the unmarshall could use it as a 
> pointer via reflection and mutate it (but that is probably not what the 
> caller expects in Go) ?

No, see:

https://play.golang.org/p/MyF0Dx87-1j

If you pass in &foo instead and insert the appropriate call to
value.Elem(), it works.

-- 
You received this message because you are subscribed to the Google 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] improve the reflection of golang

[Ian Lance Taylor]

On Mon, Nov 19, 2018 at 2:11 AM, iamybj via golang-nuts
 wrote:
>
> I am dong a simple sql library, but i need access some unexpected members in
> the std lib.
> I find this project https://github.com/alangpierce/go-forceexport
> but it is out of date.\
>
> The authors of golang are some old programmer, but programming language
> processing for several ten years.
> golang must borrow new features from c# and java.
>
> reflection should be completely support package, it is not enough  now.
>
> And also, in java and c#, user defined types are the same as runtime types
> for example these 2 languages can use for..each for user defined types.
> but in go, for...range can only be applied in system types.
>
> A lot of thing should be done, go process too slow...

Thanks for the note, but you didn't show us any code.  What do you
actually want?

To the best of my knowledge the reflect package lets you do anything
that you can do in the language itself, except for some very special
cases like creating a new interface type.

Ian

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

Re: [go-nuts] Re: Force pointer at compile time to interface{} parameter

[Robert Engels]

Interesting. I guess that makes sense. But you would think that if using a 
reflection call should force the compiler to heap allocate , then no reason for 
the restriction. 

> On Nov 19, 2018, at 2:33 PM, Ian Denhardt  wrote:
> 
> Quoting Robert Engels (2018-11-19 15:13:53)
>> But isn’t that just for safety. Meaning the unmarshall could use it as a 
>> pointer via reflection and mutate it (but that is probably not what the 
>> caller expects in Go) ?
> 
> No, see:
> 
>https://play.golang.org/p/MyF0Dx87-1j
> 
> If you pass in &foo instead and insert the appropriate call to
> value.Elem(), it works.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Re: Force pointer at compile time to interface{} parameter

['Axel Wagner' via golang-nuts]

The restriction has nothing to do with heaps (in fact, the Go language
(i.e. the spec) doesn't even have a concept of a "heap"). It's a
type-safety requirement. If you pass in a value, it can't be mutated,
full-stop. Reflect shouldn't allow you to bypass type-safety - only
"unsafe" can do that, hence the name.
On Mon, Nov 19, 2018 at 9:51 PM Robert Engels  wrote:
>
> Interesting. I guess that makes sense. But you would think that if using a 
> reflection call should force the compiler to heap allocate , then no reason 
> for the restriction.
>
> > On Nov 19, 2018, at 2:33 PM, Ian Denhardt  wrote:
> >
> > Quoting Robert Engels (2018-11-19 15:13:53)
> >> But isn’t that just for safety. Meaning the unmarshall could use it as a 
> >> pointer via reflection and mutate it (but that is probably not what the 
> >> caller expects in Go) ?
> >
> > No, see:
> >
> >https://play.golang.org/p/MyF0Dx87-1j
> >
> > If you pass in &foo instead and insert the appropriate call to
> > value.Elem(), it works.
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to golang-nuts+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Re: Force pointer at compile time to interface{} parameter

[Robert Engels]

That is not really true though, as I can declare a method that take a pointer 
receiver and mutate through it, but the caller can pass a struct which it 
thinks can not be mutated.

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

Go isn’t type safe by stating that methods cannot mutate structs. Any reader of 
the above code would think that couldn’t work, unless they inspected the source 
to find a pointer receiver. 

> On Nov 19, 2018, at 3:28 PM, Axel Wagner  
> wrote:
> 
> The restriction has nothing to do with heaps (in fact, the Go language
> (i.e. the spec) doesn't even have a concept of a "heap"). It's a
> type-safety requirement. If you pass in a value, it can't be mutated,
> full-stop. Reflect shouldn't allow you to bypass type-safety - only
> "unsafe" can do that, hence the name.
>> On Mon, Nov 19, 2018 at 9:51 PM Robert Engels  wrote:
>> 
>> Interesting. I guess that makes sense. But you would think that if using a 
>> reflection call should force the compiler to heap allocate , then no reason 
>> for the restriction.
>> 
>>> On Nov 19, 2018, at 2:33 PM, Ian Denhardt  wrote:
>>> 
>>> Quoting Robert Engels (2018-11-19 15:13:53)
 But isn’t that just for safety. Meaning the unmarshall could use it as a 
 pointer via reflection and mutate it (but that is probably not what the 
 caller expects in Go) ?
>>> 
>>> No, see:
>>> 
>>>   https://play.golang.org/p/MyF0Dx87-1j
>>> 
>>> If you pass in &foo instead and insert the appropriate call to
>>> value.Elem(), it works.
>>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Re: Force pointer at compile time to interface{} parameter

['Axel Wagner' via golang-nuts]

On Mon, Nov 19, 2018 at 10:37 PM Robert Engels  wrote:
> That is not really true though, as I can declare a method that take a pointer 
> receiver and mutate through it, but the caller can pass a struct which it 
> thinks can not be mutated.
>
> https://play.golang.org/p/Abf4VX9kUTR

This is syntactic sugar for (&a).Change() - the method is still called
on a pointer, even if it's not obvious from the code. It's one of the
many ways in which `a.F()` differs from `A.F(a)`. I agree that it
makes the mutability less obvious (there's a tradeoff between
verbosity and convenience and Go deviates here), but it doesn't change
what I said - if you pass a value to a function or method, it can't be
mutated.

>
> Go isn’t type safe by stating that methods cannot mutate structs. Any reader 
> of the above code would think that couldn’t work, unless they inspected the 
> source to find a pointer receiver.
>
> On Nov 19, 2018, at 3:28 PM, Axel Wagner  
> wrote:
>
> The restriction has nothing to do with heaps (in fact, the Go language
> (i.e. the spec) doesn't even have a concept of a "heap"). It's a
> type-safety requirement. If you pass in a value, it can't be mutated,
> full-stop. Reflect shouldn't allow you to bypass type-safety - only
> "unsafe" can do that, hence the name.
> On Mon, Nov 19, 2018 at 9:51 PM Robert Engels  wrote:
>
>
> Interesting. I guess that makes sense. But you would think that if using a 
> reflection call should force the compiler to heap allocate , then no reason 
> for the restriction.
>
>
> On Nov 19, 2018, at 2:33 PM, Ian Denhardt  wrote:
>
>
> Quoting Robert Engels (2018-11-19 15:13:53)
>
> But isn’t that just for safety. Meaning the unmarshall could use it as a 
> pointer via reflection and mutate it (but that is probably not what the 
> caller expects in Go) ?
>
>
> No, see:
>
>
>   https://play.golang.org/p/MyF0Dx87-1j
>
>
> If you pass in &foo instead and insert the appropriate call to
>
> value.Elem(), it works.
>
>
> --
>
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
>
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Re: Force pointer at compile time to interface{} parameter

[Dan Kortschak]

As Axel points out this is not the case. This can be demonstrated by
trying to assign the struct to an interface that has the method you are
wanting to call. The following would compile under the rules you're
suggesting. It doesn't.

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


On Mon, 2018-11-19 at 15:37 -0600, Robert Engels wrote:
> That is not really true though, as I can declare a method that take a
> pointer receiver and mutate through it, but the caller can pass a
> struct which it thinks can not be mutated.
>
> https://play.golang.org/p/Abf4VX9kUTR
>
> Go isn’t type safe by stating that methods cannot mutate structs. Any
> reader of the above code would think that couldn’t work, unless they
> inspected the source to find a pointer receiver.
>
> >
> > On Nov 19, 2018, at 3:28 PM, Axel Wagner  > .com> wrote:
> >
> > The restriction has nothing to do with heaps (in fact, the Go
> > language
> > (i.e. the spec) doesn't even have a concept of a "heap"). It's a
> > type-safety requirement. If you pass in a value, it can't be
> > mutated,
> > full-stop. Reflect shouldn't allow you to bypass type-safety - only
> > "unsafe" can do that, hence the name.
> > >
> > > On Mon, Nov 19, 2018 at 9:51 PM Robert Engels  > > com> wrote:
> > >
> > > Interesting. I guess that makes sense. But you would think that
> > > if using a reflection call should force the compiler to heap
> > > allocate , then no reason for the restriction.
> > >
> > > >
> > > > On Nov 19, 2018, at 2:33 PM, Ian Denhardt 
> > > > wrote:
> > > >
> > > > Quoting Robert Engels (2018-11-19 15:13:53)
> > > > >
> > > > > But isn’t that just for safety. Meaning the unmarshall could
> > > > > use it as a pointer via reflection and mutate it (but that is
> > > > > probably not what the caller expects in Go) ?
> > > > No, see:
> > > >
> > > >   https://play.golang.org/p/MyF0Dx87-1j
> > > >
> > > > If you pass in &foo instead and insert the appropriate call to
> > > > value.Elem(), it works.
> > > >
> > > > --
> > > > You received this message because you are subscribed to the
> > > > Google Groups "golang-nuts" group.
> > > > To unsubscribe from this group and stop receiving emails from
> > > > it, send an email to golang-nuts+unsubscr...@googlegroups.com.
> > > > For more options, visit https://groups.google.com/d/optout.
> > > --
> > > You received this message because you are subscribed to the
> > > Google Groups "golang-nuts" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> > > send an email to golang-nuts+unsubscr...@googlegroups.com.
> > > For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Re: Force pointer at compile time to interface{} parameter

[Robert Engels]

I understand that. I was stating that the syntactic sugar of automatic pointer 
creation to call a method should be removed. Having an A become a *A in one 
instance but not in others just causes confusion, let alone makes things not 
obviously mutable, mutable, causing a developer to determine that the method 
actually have a pointer receiver. I know it won’t because of backwards 
compatibility, but it was a very bad choice IMO. 

> On Nov 19, 2018, at 5:41 PM, Dan Kortschak  
> wrote:
> 
> As Axel points out this is not the case. This can be demonstrated by
> trying to assign the struct to an interface that has the method you are
> wanting to call. The following would compile under the rules you're
> suggesting. It doesn't.
> 
> https://play.golang.org/p/qRYPaDOPYsl
> 
> 
>> On Mon, 2018-11-19 at 15:37 -0600, Robert Engels wrote:
>> That is not really true though, as I can declare a method that take a
>> pointer receiver and mutate through it, but the caller can pass a
>> struct which it thinks can not be mutated.
>> 
>> https://play.golang.org/p/Abf4VX9kUTR
>> 
>> Go isn’t type safe by stating that methods cannot mutate structs. Any
>> reader of the above code would think that couldn’t work, unless they
>> inspected the source to find a pointer receiver.
>> 
>>> 
>>> On Nov 19, 2018, at 3:28 PM, Axel Wagner >> .com> wrote:
>>> 
>>> The restriction has nothing to do with heaps (in fact, the Go
>>> language
>>> (i.e. the spec) doesn't even have a concept of a "heap"). It's a
>>> type-safety requirement. If you pass in a value, it can't be
>>> mutated,
>>> full-stop. Reflect shouldn't allow you to bypass type-safety - only
>>> "unsafe" can do that, hence the name.
 
 On Mon, Nov 19, 2018 at 9:51 PM Robert Engels >>> com> wrote:
 
 Interesting. I guess that makes sense. But you would think that
 if using a reflection call should force the compiler to heap
 allocate , then no reason for the restriction.
 
> 
> On Nov 19, 2018, at 2:33 PM, Ian Denhardt 
> wrote:
> 
> Quoting Robert Engels (2018-11-19 15:13:53)
>> 
>> But isn’t that just for safety. Meaning the unmarshall could
>> use it as a pointer via reflection and mutate it (but that is
>> probably not what the caller expects in Go) ?
> No, see:
> 
>  https://play.golang.org/p/MyF0Dx87-1j
> 
> If you pass in &foo instead and insert the appropriate call to
> value.Elem(), it works.
> 
> --
> You received this message because you are subscribed to the
> Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
 --
 You received this message because you are subscribed to the
 Google Groups "golang-nuts" group.
 To unsubscribe from this group and stop receiving emails from it,
 send an email to golang-nuts+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Re: Force pointer at compile time to interface{} parameter

[Dan Kortschak]

I don't agree that it was a bad idea. It eases reading and writing in
many cases. The mutability of a value is based on the method signature,
which is readily available through the godoc.

On Mon, 2018-11-19 at 17:57 -0600, Robert Engels wrote:
> I understand that. I was stating that the syntactic sugar of
> automatic pointer creation to call a method should be removed. Having
> an A become a *A in one instance but not in others just causes
> confusion, let alone makes things not obviously mutable, mutable,
> causing a developer to determine that the method actually have a
> pointer receiver. I know it won’t because of backwards compatibility,
> but it was a very bad choice IMO.

-- 
You received this message because you are subscribed to the Google 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: Force pointer at compile time to interface{} parameter

[Robert Engels]

Sorry, I only brought it up because it seemed related to me, and the original 
question was answered as No...

> On Nov 19, 2018, at 6:06 PM, Dan Kortschak  
> wrote:
> 
> I don't agree that it was a bad idea. It eases reading and writing in
> many cases. The mutability of a value is based on the method signature,
> which is readily available through the godoc.
> 
>> On Mon, 2018-11-19 at 17:57 -0600, Robert Engels wrote:
>> I understand that. I was stating that the syntactic sugar of
>> automatic pointer creation to call a method should be removed. Having
>> an A become a *A in one instance but not in others just causes
>> confusion, let alone makes things not obviously mutable, mutable,
>> causing a developer to determine that the method actually have a
>> pointer receiver. I know it won’t because of backwards compatibility,
>> but it was a very bad choice IMO.

-- 
You received this message because you are subscribed to the Google 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 modules and vendor: redundant features?

[andrewchamberss]

I recall reading from Russ Cox that vendoring will be removed in the future 
and be replaced by explicit caching with modules.

-- 
You received this message because you are subscribed to the Google 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: compiling from within vim not working

[Robert Solomon]

I'm running gvim when I try this.  I was able to symlink as an earlier poster 
instructed.  
Now I'm having a different problem.   I'm getting the error that no go files 
are found.  My code is in ~/go/src, so each file is dir/code file.go.  gvim 
make is confused by that 

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

[go-nuts] Determining latest released Go version

[Tamás Gulácsi]

See what github.com/niemeyer/godeb does.

-- 
You received this message because you are subscribed to the Google 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] [ANN] Elastic APM Go Agent

[Andrew Wilkins]

Hi folks,

The Elastic APM Go agent has just released v1.0.0, and is now "generally 
available."
Elastic APM is an open source Application Performance Monitoring solution 
built on top of the Elastic Stack.

The Go agent now supports the OpenTracing API. All of our agents are 
implementing the draft W3C Trace-Context standard* for distributed tracing.

You can read more in the announcement blog post: 
https://www.elastic.co/blog/elastic-apm-go-agent-1-0-0-released.

Cheers,
Andrew

* We implement the same logic as in the W3C trace-Context standard, however 
we have temporarily renamed the Traceparent header to avoid compatibility 
issues during the draft process; we will use the standard header names when 
they're out of draft, to ensure compatibility with other implementations. 
That's the pointer, after all :)

On Wednesday, 21 March 2018 13:41:40 UTC+8, Andrew Wilkins wrote:
>
> On Wed, 21 Mar 2018 at 13:34 Henrik Johansson  
> wrote:
>
>> Out of curiosity is it Open Tracing compatible?
>>
>
> Not at the moment, but we are looking at both OpenTracing and OpenCensus. 
> Which common/standard APIs we implement will depend on customer demand or 
> community contributions. I expect at least one of those will be supported 
> in the future.
>
> Cheers,
> Andrew
>  
>
>> On Wed, Mar 21, 2018, 02:55 Andrew Wilkins  wrote:
>>
>>> Hi folks,
>>>
>>> Elastic APM [0] is an open source APM solution being developed by 
>>> Elastic. The Elastic APM server [1] is written in Go. We've recently 
>>> started working on a package for tracing/monitoring Go applications: 
>>> https://github.com/elastic/apm-agent-go.
>>>
>>> Although the Go support is fully functional, it's still very early in 
>>> development -- we're calling it "pre-alpha" to make it clear that the API 
>>> is still very likely to change. Currently there's support for tracing (but 
>>> not *distributed* tracing -- we're working on that), and we've started 
>>> looking at adding support for application metrics.
>>>
>>> We'd be happy to hear your feedback on the Go agent, and what things 
>>> you'd like to monitor in your Go applications. If you're interested and 
>>> have 5-10 minutes, please fill it out: 
>>> https://goo.gl/forms/6CMMsqd6TVAYEEg42.
>>>
>>> Finally, if you want to follow along, I encourage you to either 
>>> star/watch the repositories, and/or sign up to 
>>> https://discuss.elastic.co/c/apm. I won't be posting this sort of thing 
>>> regularly to golang-nuts, as I'm sure it's not of general interest.
>>>
>>> Cheers,
>>> Andrew
>>>
>>> P.S. It's called an "agent" for consistency, but really it's just a 
>>> package you import into your application. That could change.
>>>
>>> [0] https://www.elastic.co/solutions/apm
>>> [1] https://github.com/elastic/apm-server
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google 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] Types are contract -, v2

[Burak Serdar]

Hi,

A while ago I sent an email to this list proposing an alternative way
to specify contracts using existing types, with a "like" keyword to
represent contracts on primitives. The idea stirred up some
discussion, I got some useful feedback, and eventually, it died down.
The idea stuck with me though, because it wasn't complete when I
proposed it, it had inconsistencies and unresolved problems. It turned
into this puzzle that I kept working on on the side, I started writing
a contracts/generics simulator, which I never finished, but it allowed
me to figure out a way to solve the problems the original idea had. So
the latest version of that proposal is now here:

https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3

-- 
You received this message because you are subscribed to the Google 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] improve the reflection of golang

['yinbingjun' via golang-nuts]

in database/sql rows.Scan(…) can only copy values to seperate variables, the 
style is not comfortable ,I want use a struct as database row.

I want to use unexported database/sql.convertAssign,

type Test struct {
Name  string
Age   int
Email string
}

var tests []Test
var count int

b := NewSqlBuilder()
b.Sql(`select * from test where name = ?;
 select count(*) from test;`, "ybj")
fmt.Println(b.String())
fmt.Println(b.Params())

QueryObjects(db, b.String(), b.Params(), []func(r *Record){

func(r *Record) {
var t Test = Test{}
r.ConvertAssign(0, &t.Name)
r.ConvertAssignByName("age", &t.Age)
r.ConvertAssignByName("Email", &t.Email)

tests = append(tests, t)
},
func(r *Record) {
r.ConvertAssign(0, &count)
},
})

fmt.Println(tests)
fmt.Println(count)

The methods r.ConvertAssign and r.ConvertAssignByName should work keep the same 
with database.sql.ConvertAssign





> On Nov 20, 2018, at 04:41, Ian Lance Taylor  wrote:
> 
> On Mon, Nov 19, 2018 at 2:11 AM, iamybj via golang-nuts
>  wrote:
>> 
>> I am dong a simple sql library, but i need access some unexpected members in
>> the std lib.
>> I find this project https://github.com/alangpierce/go-forceexport
>> but it is out of date.\
>> 
>> The authors of golang are some old programmer, but programming language
>> processing for several ten years.
>> golang must borrow new features from c# and java.
>> 
>> reflection should be completely support package, it is not enough  now.
>> 
>> And also, in java and c#, user defined types are the same as runtime types
>> for example these 2 languages can use for..each for user defined types.
>> but in go, for...range can only be applied in system types.
>> 
>> A lot of thing should be done, go process too slow...
> 
> Thanks for the note, but you didn't show us any code.  What do you
> actually want?
> 
> To the best of my knowledge the reflect package lets you do anything
> that you can do in the language itself, except for some very special
> cases like creating a new interface type.
> 
> 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.

-- 
You received this message because you are subscribed to the Google 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] 3 important things that go should do first

['yinbingjun' via golang-nuts]

Recently I want to build a personal website using go, and I found it is very 
difficult.

First go should support generic types. 
Generic types is  very useful in ORM projects. 
If this make complex, go can borrow idea from java: only support generic types 
in language grammar and compiling time, not in runtime.  
I think this will make go support type conversion like []interface to 
[]interface{}


Second go should improve reflection.
Go should can reflect all members in go, like package.

Third go should treat user defined types as the same as system types.
For example, for…range can only be applied to system types, if you write a 
List/Queue type, sorry ,for…range cannot use them.

And I recommend go support python’s decorator. It is very useful in programming.

-- 
You received this message because you are subscribed to the Google 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] 3 important things that go should do first

[Ian Denhardt]

Quoting 'yinbingjun' via golang-nuts (2018-11-19 22:23:35)
> First go should support generic types.

There's ongoing discussion of this in the context of Go 2; see:

https://blog.golang.org/go2draft

Which also links to the full draft designs, as well as feedback pages
(with *lots* of feedback).

> And I recommend go support python’s decorator. It is very useful in
> programming.

I've found Go's anonymous functions cover basically everything you'd
actually want decorators for; This makes sense because python's
decorator syntax is just syntactic sugar, i.e.

@mydecorator
def myfun():
...

Is the same as:

def myfun():
...
myfun = mydecorator(myfun)

This is somewhat useful since Python's lambda is limited to a single
expression, but Go does not have this restriction, so you'd probably
just do:

myfun := mydecorator(func() {
...
})

-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] gob limitation or bug?

[Hoping White]

package main

import (
   "bytes"
   "encoding/gob"
   "fmt"
)

var data = bytes.NewBuffer(nil)
var buff = bytes.NewBuffer(nil)
var encoder = gob.NewEncoder(data)
var decoder = gob.NewDecoder(buff)

func main() {
   encode()
   decode()
   decode()
}

func encode() {
   n := [][]int32{[]int32{1}, []int32{2, 3}, []int32{4, 5, 6}}
   encoder.Encode(&n)
   fmt.Printf("encode bytes:%v len:%d\n", data.Bytes(), data.Len())
}

func decode() {
   buff.Write(data.Bytes())
   println("data size", buff.Len(), data.Len())
   var n [][]int32
   err := decoder.Decode(&n)
   if err != nil {
  println("decode err:", err.Error())
   }
   println("data left:", buff.Len())
   fmt.Printf("%v\n", n)
}

Run output:

encode bytes:[13 255 131 2 1 2 255 132 0 1 255 130 0 0 12 255 129 2 1
2 255 130 0 1 4 0 0 13 255 132 0 3 1 2 2 4 6 3 8 10 12] len:41data
size 41 41
data left: 0[[1] [2 3] [4 5 6]]data size 41 41
decode err: extra data in buffer
data left: 27[]


I found that, encode a slice would failed, but a struct ok. Is this a bug
or limitation of gob?

-- 
You received this message because you are subscribed to the Google 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] improve the reflection of golang

[Reto Brunner]

If you want to do that, there's already a package for it: 
https://github.com/jmoiron/sqlx

```
people := []Person{}
db.Select(&people, "SELECT * FROM person ORDER BY first_name ASC")
```

-- 
You received this message because you are subscribed to the Google 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] Where is the very first g/m/p?

[Fei Ding]

Hi

I am trying to figure out the process of creation of the very first 
g(goroutine), together with the very fist m, and p. It seems that the 
deepest code I can find is at proc.go 
, and 
the getg() function is my dead end, which has no implementation written by 
golang. So, here is my q:

1. I guess before the user main() function be executed, a lot of work has 
already been finished, including creating the very first g/m/p, where the 
code is? It seems to be asm code? I do have some problem reading/digging 
asm code.

2. Could any one explain the whole process of creating the very first g/m/p?

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.