[go-nuts] Re: adding context.Context to new code

[mhhcbon]

I want something similar too.

Automatic and smart insertion of context args in a chain of calls.

Methods signature updates are easy, but how to appropriately insert context 
check in the ast  ?
I m not sure yet.

>The difficulty here seems to differentiate intra package calls from calls 
to standard/3rd party libraries which shouldn't be having new param.

That does not sound too difficult, from the pkg identifier, lookup for the 
import path, for every import path, exists in GOROOT ?

Please put updates here anything you want to share.

At that moment i m using this package to help me with ast, 
https://github.com/mh-cbon/astutil

might be a start even though it needs refactoring.

On Monday, May 8, 2017 at 1:03:52 AM UTC+2, meir fischer wrote:
>
> I'm adding tracing to an existing code base with many packages and it 
> seems the best way to have context's passed around is to just have every 
> method take a context.Context. 
>
> Is there any tooling for converting a code base/package to have:
> (a) context.Context as the first parameter in each function - ctx 
> context.Context
> (b) for any function that has changed, have its callers (within that 
> package) pass ctx as the first arg
>
> The difficulty here seems to differentiate intra package calls from calls 
> to standard/3rd party libraries which shouldn't be having new param.
>

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

Re: [go-nuts] why received can be defined with/without pointer?

[mhhcbon]

thanks, 

> The definition of the 
method always makes it clear whether you are passing a value of the 
type or a pointer to the type.  People defining methods on large types 
should know which one want to use.

in short and put straightly,
1- i think its not appropriate to let us 
define pointer/non pointer attribute 
of a type over multiple points in the code.
In my experience of a beginner, its a pain that teaches you to always use 
pointer by default.
2- The current way to define a type as value/pointer does indeed serves its 
job, but absolutely nothing more,
that is where i feel there are certain lacks. 

As you say the keyword is superfluous, but not practical imho,
in any cases can it be made helpful to help us prevent error or undesired 
side effects ?
Can the compiler helped not to copy a pointer when it is inappropriate.


> That would lose a clearly useful feature from the language.  In 
particular, if you only permit pointer receivers or value receivers, 
which one do you permit?  See also 
https://golang.org/doc/faq#methods_on_values_or_pointers . 

I have read both your thoughts and the doc, i have not found a 
"useful feature". I respectfully did not.
(hope the ability of value/pointer is not the feature you talk about 
because i don t intend to remove it, and its barely just a feature i think, 
its critical)

imho, we should not defines the way the type is stored in memory
at its declaration, unless it produces useful barriers to mistakes.

So i think there should be only no-star on receiver.
And that to the question "where to store that instances" (use pointer or 
value?) the answer should be provider only
at the instanciation time. (see below i have a tech question about it btw, 
please)

The only feature it disables i can think about is the feature which helps 
to tell
if your receiver is nil/or not.
I question this feature and wonder if it was a worthy trade against other 
possibilities,
if one wants to imagine them, obviously.


Side Q,

Given this program, with an hypothetical Value type with a method Hello 
without side effects.

func main(){
x(T{})
}

func x(T Value){
(&T).Hello() // How is this happening ? 
// Does it escape the variable ahead of time so x become x(T *Value) ? 
// Or does it take the address of T wherever it is in memory to manipulate 
it ?
// or maybe it does a copy of T to new *T, do the work, copies, then frees 
it ?
}

thanks again for your time.


On Monday, May 8, 2017 at 8:39:48 PM UTC+2, Ian Lance Taylor wrote:
>
> On Sun, May 7, 2017 at 3:37 AM,  > wrote: 
> > yes, sorry you scratched your head 
> > 
> > https://play.golang.org/p/Gg6Euyvsw6 
> > 
> > this example shows that it is possible to do all the things. 
> > hth. 
> > 
> > I m curious to know more about other questions. 
> > Maybe they are not good idea, or not technically achievable. 
> > Just curious. 
>
>
> > if a new keyword appear to ensure a type is 
> > consumed by value, that might be helpful to provide 
> > a function to make sure that type won t exceed the stack size 
> > and escape to the heap. 
> > that keyword would help api designer to avoid consumption problems. 
> > nop ? 
>
> To me that seems like a very abstract concern.  The definition of the 
> method always makes it clear whether you are passing a value of the 
> type or a pointer to the type.  People defining methods on large types 
> should know which one want to use.  There is no need for an additional 
> keyword; the method definition is clear in any case. 
>
>
> > If a new keyword would appear to ensure a type is initialized by 
> reference, 
> > might help to detect value copy and warn/error when that case is met. 
> > That would helped consumers to avoid problems. 
> > nop ? 
>
> Where would such a keyword be used?  The definition of the type makes 
> clear whether it has values or pointers. 
>
>
> > If the receiver type was not able to be star/nostar, 
> > that d probably help to get ride of confusion, 
> > nop ? 
>
> That would lose a clearly useful feature from the language.  In 
> particular, if you only permit pointer receivers or value receivers, 
> which one do you permit?  See also 
> https://golang.org/doc/faq#methods_on_values_or_pointers . 
>
> Ian 
>

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

[go-nuts] Re: Go 1.8.1 is released

[nixusr]

Great!!!

On Friday, April 7, 2017 at 3:16:40 PM UTC-3, Nathan Kerr wrote:
>
> Thanks for all the hard work!
>
> I have updated my go release timeline 
>  visualization.
>

-- 
You received this message because you are subscribed to the Google 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: [ANN] listser/mutexer/channeler: generators.

[mhhcbon]

Hi,

i want to share some more with you as i feel like it looks good to whoever 
interested into speeding up his programming experience with go ;)

Until now i presented works that took a type T and produce a derived type 
T2 of it.
Easy stuff, not so useful unless you only want to do rpc stuffs.
But still cool as this pattern helps to implement implement of 
proxy-like/facade type that are interesting.

Today i want to share a new feature i added, contextual parameters.

The methods parameters are not only meaningful by their type definition, 
but also by their names.

So it become possible to write this kind of thing and got them to work 
seamlessly,

func (t *Controller) UpdateByID(urlID int, reqBody *Tomate) *Tomate {


Simply put, 
UpdateByID look for an ID value in the URL (might be route params, query 
values),
takes the req body and somehow decodes it to an *Tomate instance.

That s it, you combine that +jsoner +httper and 
you got hundreds of lines of generated for you, 
ready to consume.
boom, lets get a beer.

That works with cookies/session/post/req/url/get because the type is 
consumed by http domain related generators (aka the context).

Also some methods parameters signature are recognized to work in the 
context of an http thing,
so you can write

func (t *Controller) TestVars1(w http.ResponseWriter, r *http.Request) {



And it just works too. the generators at each step understand them and 
behave appropriately.


But its not all, what i described is pretty interesting to maintain code 
easily,
but there s no way to declare additional information such route pattern or 
else,

So i added annotations support.


Thus i can write,

// GetByID ... 
// @route /{id} 
// @methods GET 
func (t *Controller) GetByID(urlID int) *Tomate

And get a program generated that handles all those intents for me in a 
coherent manner :D

Gonna have a beer now.


Have fun!



On Saturday, April 29, 2017 at 5:06:27 PM UTC+2, mhh...@gmail.com wrote:
>
> Hi,
>
> several generators i made to avoid some duplication.
>
> https://github.com/mh-cbon/lister
>
> Package lister is a generator to generate typed slice.
>
>
> https://github.com/mh-cbon/channeler
>
> Package channeler is a cli generator to generate channeled version of a 
> type.
>
> https://github.com/mh-cbon/mutexer
>
> Package mutexer is a cli generator to generate mutexed version of a type.
>
>
> so basically, using below code you got hundreds of line generated for you,
>
>
> in that example to make a mutexed []Tomate.
>
>
> But as it s not too stupid, or tries too, it will be able to handle 
>
> pointer and basic types
>
> mutexed []*Tomate
>
> mutexed []string
>
> ect
>
>
> It should also be able to lookup for a constructor of the src type 
> (Tomate),
>
> and reproduce it into the dest type implementation.
>
>
> There is both mutexer / channeler because both cases applies for reasons.
>
>
> The lister is a convenient way to create typed slice.
>
>
> package demo
>
> // Tomate is about red vegetables to make famous italian food.
> type Tomate struct {
> Name string
> }
>
> // GetID return the ID of the Tomate.
> func (t Tomate) GetID() string {
> return t.Name
> }
>
> //go:generate lister vegetables_gen.go Tomate:Tomates
> //go:generate mutexer vegetuxed_gen.go Tomates:Tomatex
>
> hth
>
>

-- 
You received this message because you are subscribed to the Google 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: use of builtin print for debug

[mhhcbon]

ast transformation seems a good candidate for your problem.

Should not be very difficult.

start with 
https://godoc.org/golang.org/x/tools/go/loader

Learn ast struct with 
https://golang.org/pkg/go/ast/#Print
might be helpful 
https://gist.github.com/mh-cbon/3ed5d9c39e9635cfed0f89698133

Also i think go has already several patchers that you might get inspiration 
from,
not sure where they are located. Sorry : x

On Tuesday, May 9, 2017 at 2:01:19 AM UTC+2, Tong Sun wrote:
>
> I know using of builtin print is not encouraged, but it's convenient, and 
> I've sprinted it all over my code. 
>
> Now debugging is over, I need to disable all the builtin prints. Is there 
> any easy way to toggle the printing on and off, so that I can enable 
> debugging any time in the future? I've tried many ways, but seems 
> commenting them off is the only way I can find. 
>
> Please help. 
>

-- 
You received this message because you are subscribed to the Google 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: suggest: improve go gen intergration for non core code ?

[mhhcbon]

Maybe that could be a simple go sub command: 

go gun [...packages]

gen+run=>gun 

Sure i could do on my end, it won t be adopted so ... useless.

On Friday, May 5, 2017 at 3:15:25 PM UTC+2, mhh...@gmail.com wrote:
>
> Hi,
>
> just a suggestion to improve go gen adoption rate, maybe.
>
> go generate is not included in the go build pipeline,
> for good reasons, especially for the core code.
>
> It s a two step command,
> 1- go gen
> 2- go build
>
> Although, since vendoring is implemented,
> I think it would be good to re think its usage,
> depending if you are building core code Vs random package.
>
> When you write a random package (no better name sorry),
> if `go gen` was included into the `go run` command,
> i believe that d help to improve its adoption rate.
>
> In that case that would only apply to the package files,
> excluding core code, vendored code,
> and those generated files must be committed to the vcs.
>
> Doing so, when pkg A depends on B,
> and that B uses go gen, the files would already be present, 
> thus no need to gen then B.
>
> Only pkg A might need 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] Re: suggest: improve go gen intergration for non core code ?

[Ian Davis]

On Tue, 9 May 2017, at 12:12 PM, mhhc...@gmail.com wrote:
> Maybe that could be a simple go sub command: 
> 
> go gun [...packages]
> 
> gen+run=>gun 
> 
> Sure i could do on my end, it won t be adopted so ... useless.

Usually go generate is intended to be run once and the results committed
to the repository. It's not expected that end users of the code re-run
it regularly.
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: use of builtin print for debug

[Marvin Renich]

* mhhc...@gmail.com  [170509 07:10]:
> Also i think go has already several patchers that you might get
> inspiration from, not sure where they are located. Sorry : x

Try man gofmt and look at -r.

...Marvin

-- 
You received this message because you are subscribed to the Google 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: suggest: improve go gen intergration for non core code ?

[mhhcbon]

thanks for feedback,

i put that in regards to my understanding of go generate,
re run it anytime its needed, anytime you changed your code,

please see
https://groups.google.com/forum/#!topic/golang-nuts/8L_bjxB-_T0

that concretely demonstrates why i don t go with the "usual thinking".

On Tuesday, May 9, 2017 at 1:29:54 PM UTC+2, Ian Davis wrote:
>
>
> On Tue, 9 May 2017, at 12:12 PM, mhh...@gmail.com  wrote:
>
> Maybe that could be a simple go sub command: 
>
> go gun [...packages]
>
> gen+run=>gun 
>
> Sure i could do on my end, it won t be adopted so ... useless.
>
>
> Usually go generate is intended to be run once and the results committed 
> to the repository. It's not expected that end users of the code re-run it 
> regularly.
>
> 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: use of builtin print for debug

[mhhcbon]

: ( thanks

$ man gofmt
Aucune entrée de manuel pour gofmt
/no such entry/




*$ gofmt -husage: gofmt [flags] [path ...]  -r stringrewrite rule 
(e.g., 'a[b:len(a)] -> a[b:]')*

https://golang.org/cmd/gofmt/#hdr-Examples


How to take advantage of it ?
He needs to add new func, probably.
And maybe to rename expr.Call.Name.


On Tuesday, May 9, 2017 at 1:34:26 PM UTC+2, Marvin Renich wrote:
>
> * mhh...@gmail.com  > [170509 
> 07:10]: 
> > Also i think go has already several patchers that you might get 
> > inspiration from, not sure where they are located. Sorry : x 
>
> Try man gofmt and look at -r. 
>
> ...Marvin 
>
>

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

Re: [go-nuts] why received can be defined with/without pointer?

[Volker Dobler]

On Tuesday, 9 May 2017 12:30:38 UTC+2, mhh...@gmail.com wrote:
>
> in short and put straightly,
> 1- i think its not appropriate to let us 
> define pointer/non pointer attribute 
> of a type over multiple points in the code.
> In my experience of a beginner, its a pain that teaches you to always use 
> pointer by default.
>

Please keep in mind that while "friendly to newcomers/beginner"
_is_  important it cannot be the main (or even only) goal of a language
targeting productivity.
 

> 2- The current way to define a type as value/pointer does indeed serves 
> its job, but absolutely nothing more,
> that is where i feel there are certain lacks. 
>

What more than "serve[...] its job" would you expect from a
language construct. Go offers two types of methods, those
defined on value types and those defined on pointer types.
Both are useful, both server their job. What's wrong here?
 

> I have read both your thoughts and the doc, i have not found a 
> "useful feature". I respectfully did not.
> (hope the ability of value/pointer is not the feature you talk about 
> because i don t intend to remove it, and its barely just a feature i think, 
> its critical)
>

It is useful to have methods on values and it is useful to have
methods on pointers. Both are useful: Pointer methods make
mutation possible and value methods provide a notion of 
const-ness which is useful too and value methods can be invoked
on non-addressable values which is useful too.
This type of usefulness might not be obvious on first encounter
with these two types of methods.

imho, we should not defines the way the type is stored in memory
> at its declaration, unless it produces useful barriers to mistakes.
>

I'm not sure I understand: Something like
type S struct { a int64; b[3]complex128 }
actually defines storage layout and I think that the ability to control
is this in Go is a good (and useful thing).

So i think there should be only no-star on receiver.
>
 
A "non-star" receiver would be a method on a value
(non-pointer, non-interface) type.
This would basically disallow methods to mutate the receiver
state as only a copy of the receiver would be mutated.
Are you proposing that methods on values should not
operate on a copy of the value? This would be possible but
it would be an exception to the normal rules how values
are copied during function invocation. Would such an exception
really make the language easier to understand? And if yes:
We would lose the notion of const-ness and method
invocation on non-addressable values would be limited.

 

> And that to the question "where to store that instances" (use pointer or 
> value?) the answer should be provider only
> at the instanciation time. (see below i have a tech question about it btw, 
> please)
>
> The only feature it disables i can think about is the feature which helps 
> to tell
> if your receiver is nil/or not.
> I question this feature and wonder if it was a worthy trade against other 
> possibilities,
> if one wants to imagine them, obviously.
>
>
> Side Q,
>
> Given this program, with an hypothetical Value type with a method Hello 
> without side effects.
>
> func main(){
> x(T{})
> }
>
> func x(T Value){
> (&T).Hello() // How is this happening ? 
> // Does it escape the variable ahead of time so x become x(T *Value) ? 
> // Or does it take the address of T wherever it is in memory to manipulate 
> it ?
> // or maybe it does a copy of T to new *T, do the work, copies, then frees 
> it ?
> }
>

I have to admit I'm confused and probably do not understand your
question so forgive me if I'm unable to explain it in detail.

In func x(T Value) {...} the T is a copy of the zero Value{} (typo here in
your code?) passed from main.
T is addressable and &T is it's address. If T has a method
Hello than *T has also a method Hello. So (&T).Hello() invokes
Hello on the copy of the zero value created in main.

So it would be the second option: "[...] does it take the address
of T wherever it is in memory to manipulate it ?"

There is not much magic here. Copying happens during invocation of
function x, not during the method call Hello(). Freeing the memory
used by T happens during GC: Once x is done T is unreachable and
will be collected.

You can read the code and spell out what will happen:

func x(T Value)
Read it like: function x takes a copy of a Value and names this copy T

(&T).Hello()
Read it like: Take the address of T and invoke the Hello method from
type *Value. This is the Hello method from type Value as *Value's
method set contains all methods from Value.

I hope this helps a bit.

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] why received can be defined with/without pointer?

[Jan Mercl]

On Tue, May 9, 2017 at 2:22 PM Volker Dobler 
wrote:

> Go offers two types of methods, those
> defined on value types and those defined on pointer types.

To avoid possible confusion: It's not possible to attach methods to a
pointer type. The receiver has form T or *T, but T cannot be a pointer type.

-- 

-j

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

Re: [go-nuts] Re: use of builtin print for debug

[Marvin Renich]

[I set an explicit Reply-To header because I do not want duplicate
emails.  Please do not CC me; I read this list.]

* mhhc...@gmail.com  [170509 07:40]:
> : ( thanks
> 
> $ man gofmt
> Aucune entrée de manuel pour gofmt
> /no such entry/

One of many advantages of the Debian distribution is that policy
mandates that any command which the end user is expected to use must
have a man page.  Many thanks go to the Debian maintainers of the Go
packages for their hard work, including, but not limited to, converting
Go package documentation into proper man pages.  This is not busy work;
rather it is very, very helpful!

> *$ gofmt -husage: gofmt [flags] [path ...]  -r stringrewrite rule 
> (e.g., 'a[b:len(a)] -> a[b:]')*
> 
> https://golang.org/cmd/gofmt/#hdr-Examples

Indeed, this is the right place to find the official Go documentation
for this tool.

> How to take advantage of it ?
> He needs to add new func, probably.
> And maybe to rename expr.Call.Name.

If I were trying to extricate myself from the OP's position, my first
attempt would be

  gofmt -r 'print -> debug.Print'

and then add a debug package where I could make that function empty if I
wanted.  If you want to get fancy, use build tags so that

  go build -tags debug

will build with debugging turned on, but without the tag, the debug
functions are empty.

...Marvin

-- 
You received this message because you are subscribed to the Google 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: Creating shared-libraries which override existing system functions?

[tonywalker . uk]

Looks like the first link didn't work. Should link to here 

.

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

Re: [go-nuts] why received can be defined with/without pointer?

[mhhcbon]

On Tuesday, May 9, 2017 at 2:21:52 PM UTC+2, Volker Dobler wrote:
>
> On Tuesday, 9 May 2017 12:30:38 UTC+2, mhh...@gmail.com wrote:
>>
>> in short and put straightly,
>> 1- i think its not appropriate to let us 
>> define pointer/non pointer attribute 
>> of a type over multiple points in the code.
>> In my experience of a beginner, its a pain that teaches you to always use 
>> pointer by default.
>>
>
> Please keep in mind that while "friendly to newcomers/beginner"
> _is_  important it cannot be the main (or even only) goal of a language
> targeting productivity.
>

I don t intend to, did i, i have not noticed, i want not.
I intent to think about it from my pov.
The how a solution might embrace all those cases expresses,
is subject to debate, if any there should be indeed.
 

>  
>
>> 2- The current way to define a type as value/pointer does indeed serves 
>> its job, but absolutely nothing more,
>> that is where i feel there are certain lacks. 
>>
>
> What more than "serve[...] its job" would you expect from a
> language construct. Go offers two types of methods, those
> defined on value types and those defined on pointer types.
> Both are useful, both server their job. What's wrong here?
>  
>

Help me to not copy a pointer value when its inappropriate.
If there s a purpose at defining star/nostar on a type,
but not mix them either,
help me to make that happen with ease, rather than pain.
 
That is, i agree there s point in defining star/nostar like property on a 
type,
(note i don t speak of receiver at purpose), see below.


I have read both your thoughts and the doc, i have not found a 
>> "useful feature". I respectfully did not.
>> (hope the ability of value/pointer is not the feature you talk about 
>> because i don t intend to remove it, and its barely just a feature i think, 
>> its critical)
>>
>
> It is useful to have methods on values and it is useful to have
> methods on pointers. Both are useful: Pointer methods make
> mutation possible and value methods provide a notion of 
> const-ness which is useful too and value methods can be invoked
> on non-addressable values which is useful too.
> This type of usefulness might not be obvious on first encounter
> with these two types of methods.
>

yes. The consumer can decide how to consume the value,
according if its provided/defined type is star/nostar.

//defined
var x &T{} // put on heap
var x T // put on stack

// provided
//func (r Value) n(x T) {(&x).Hello()} // x passed from stack (there might 
be some magic here, not the point, i think)
//func (r Value) n(x *T) {(*x).Hello()} // always get x from heap
//func (r Value) n(x InterfaceDef){x.Hello()} // x is pointer to value that 
matches intf.

Why does it matter that the declarer knows about this in its receiver ? 
I can t find much examples about that, besides testing if the receiver is 
nil.

That the declarer defines a type to be handled by copy 
needs proper out values,
not only nostar def on the receiver,
does it ?



>  
>
imho, we should not defines the way the type is stored in memory
>> at its declaration, unless it produces useful barriers to mistakes.
>>
>
> I'm not sure I understand: Something like
> type S struct { a int64; b[3]complex128 }
> actually defines storage layout and I think that the ability to control
> is this in Go is a good (and useful thing).
>
>
yes, i m really focused about the receiver.

by incidence i come to think about the struct, indeed somehow,

type S ref { a int64; b[3]complex128 } // prevent copy of S
type S value { a int64; b[3]complex128 } // prevent referencing to S
type S struct { a int64; b[3]complex128 } // does not matter

What can i do with `func (x *T)...` i can not do with `func (x T)`,
except checking for T==nil ?


So i think there should be only no-star on receiver.
>>
>  
> A "non-star" receiver would be a method on a value
> (non-pointer, non-interface) type.
> This would basically disallow methods to mutate the receiver
> state as only a copy of the receiver would be mutated.
> Are you proposing that methods on values should not
> operate on a copy of the value? 
>

The consumer can tell about it.

If he receives a value `func (x T)` he can say `x.Hello()` or `(&x).Hello()`
If he receives a pointer `func (x *T)` he can say `x.Hello()` or 
`(*x).Hello()` 

if he defines `var x T` and do  `(&x).Hello()` is weird.
if he defines `var x *T` and do  `(*x).Hello()` is weird.

 This would be possible but

> it would be an exception to the normal rules how values
> are copied during function invocation. 
>

Possibly yes.
 

> Would such an exception
> really make the language easier to understand? 
>

digging.
 

> And if yes:
> We would lose the notion of const-ness and method
> invocation on non-addressable values would be limited.
>
> I think we misunderstood and hope that helps you to find out about it.
or else, hope i can understand your misunderstanding of my questions.
 

>  
>
>> And that to the question "where to sto

Re: [go-nuts] Re: use of builtin print for debug

[mhhcbon]

On Tuesday, May 9, 2017 at 2:46:03 PM UTC+2, Marvin Renich wrote:
>
> [I set an explicit Reply-To header because I do not want duplicate 
> emails.  Please do not CC me; I read this list.] 
>

sure.
 

>
> * mhh...@gmail.com  > [170509 
> 07:40]: 
> > : ( thanks 
> > 
> > $ man gofmt 
> > Aucune entrée de manuel pour gofmt 
> > /no such entry/ 
>
> One of many advantages of the Debian distribution is that policy 
> mandates that any command which the end user is expected to use must 
> have a man page.  Many thanks go to the Debian maintainers of the Go 
> packages for their hard work, including, but not limited to, converting 
> Go package documentation into proper man pages.  This is not busy work; 
> rather it is very, very helpful! 
>

yeah that sounds awesome, why its not standardized?
 

>
> > *$ gofmt -husage: gofmt [flags] [path ...]  -r stringrewrite 
> rule 
> > (e.g., 'a[b:len(a)] -> a[b:]')* 
> > 
> > https://golang.org/cmd/gofmt/#hdr-Examples 
>
> Indeed, this is the right place to find the official Go documentation 
> for this tool. 
>

yes indeed, i m more interested to compare it with your man pages,
they looks awesome.
 

>
> > How to take advantage of it ? 
> > He needs to add new func, probably. 
> > And maybe to rename expr.Call.Name. 
>
> If I were trying to extricate myself from the OP's position, my first 
> attempt would be 
>
>   gofmt -r 'print -> debug.Print' 
>

For completeness,

gofmt -r 'print -> debug.Print' ...file.go
 
otherwise it stucks on stdin.


> and then add a debug package where I could make that function empty if I 
> wanted.  


Maybe he could declare the package in its gopath then run goimports ?
I mean that command that adds imports automagically.
 

> If you want to get fancy, use build tags so that 
>
>   go build -tags debug 
>
> will build with debugging turned on, but without the tag, the debug 
> functions are empty. 
>

mhh, not convinced :)
 

>
> ...Marvin 
>
>

-- 
You received this message because you are subscribed to the Google 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: adding context.Context to new code

[Sameer Ajmani]

The eg tool can execute simple refactoring steps, but automating context
plumbing through a chain of calls is an open problem. Alan Donovan put some
thought into this a few years ago, and I've done a limited form of this
using awk ;-)

On Tue, May 9, 2017 at 6:10 AM  wrote:

> I want something similar too.
>
> Automatic and smart insertion of context args in a chain of calls.
>
> Methods signature updates are easy, but how to appropriately insert
> context check in the ast  ?
> I m not sure yet.
>
>
> >The difficulty here seems to differentiate intra package calls from calls
> to standard/3rd party libraries which shouldn't be having new param.
>
> That does not sound too difficult, from the pkg identifier, lookup for the
> import path, for every import path, exists in GOROOT ?
>
> Please put updates here anything you want to share.
>
> At that moment i m using this package to help me with ast,
> https://github.com/mh-cbon/astutil
>
> might be a start even though it needs refactoring.
>
>
> On Monday, May 8, 2017 at 1:03:52 AM UTC+2, meir fischer wrote:
>>
>> I'm adding tracing to an existing code base with many packages and it
>> seems the best way to have context's passed around is to just have every
>> method take a context.Context.
>>
>> Is there any tooling for converting a code base/package to have:
>> (a) context.Context as the first parameter in each function - ctx
>> context.Context
>> (b) for any function that has changed, have its callers (within that
>> package) pass ctx as the first arg
>>
>> The difficulty here seems to differentiate intra package calls from calls
>> to standard/3rd party libraries which shouldn't be having new param.
>>
> --
> You received this message because you are subscribed to the Google 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] TAR max file name woes

[blakrow]

I am attempting to TAR a directory with relatively long file names (over 
100 chars long) and all I get is garbage. Is there any way to TAR a 
directory with file paths longer than 100 chars?

-- 
You received this message because you are subscribed to the Google 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: adding context.Context to new code

[mhhcbon]

> I've done a limited form of this using awk ;-)

if you have a minute,

can you tell more about what limited you 
in your attempts and which trade made you stop (guessing), 
if any ?

Do you still think it be awesome ? 
Or have you made your mind to an opposite position ? 
if so, For which reasons?

My tool is very poor, consider it as on going, a place for inspiration to 
get started from absolutely no idea to lets get a dirty prototype.
not sure yet how long is going to be the road, still digging :)

On Tuesday, May 9, 2017 at 4:25:46 PM UTC+2, Sameer Ajmani wrote:
>
> The eg tool can execute simple refactoring steps, but automating context 
> plumbing through a chain of calls is an open problem. Alan Donovan put some 
> thought into this a few years ago, and I've done a limited form of this 
> using awk ;-)
>
> On Tue, May 9, 2017 at 6:10 AM > wrote:
>
>> I want something similar too.
>>
>> Automatic and smart insertion of context args in a chain of calls.
>>
>> Methods signature updates are easy, but how to appropriately insert 
>> context check in the ast  ?
>> I m not sure yet.
>>
>>
>> >The difficulty here seems to differentiate intra package calls from 
>> calls to standard/3rd party libraries which shouldn't be having new param.
>>
>> That does not sound too difficult, from the pkg identifier, lookup for 
>> the import path, for every import path, exists in GOROOT ?
>>
>> Please put updates here anything you want to share.
>>
>> At that moment i m using this package to help me with ast, 
>> https://github.com/mh-cbon/astutil
>>
>> might be a start even though it needs refactoring.
>>
>>
>> On Monday, May 8, 2017 at 1:03:52 AM UTC+2, meir fischer wrote:
>>>
>>> I'm adding tracing to an existing code base with many packages and it 
>>> seems the best way to have context's passed around is to just have every 
>>> method take a context.Context. 
>>>
>>> Is there any tooling for converting a code base/package to have:
>>> (a) context.Context as the first parameter in each function - ctx 
>>> context.Context
>>> (b) for any function that has changed, have its callers (within that 
>>> package) pass ctx as the first arg
>>>
>>> The difficulty here seems to differentiate intra package calls from 
>>> calls to standard/3rd party libraries which shouldn't be having new param.
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

[go-nuts] Re: TAR max file name woes

[Jim Robinson]

It looks to me as though the Writer specifically only handles the posix 
standard tar, which does indeed limit you to 100 characters.  It appears as 
though they've implemented support for reading the GNU format, which I 
think does not place limits on the name length. 
 See https://github.com/golang/go/issues/12594 for some discussion about 
the assumptions being made by the current package.

On Tuesday, May 9, 2017 at 7:42:52 AM UTC-7, Terence wrote:
>
> I am attempting to TAR a directory with relatively long file names (over 
> 100 chars long) and all I get is garbage. Is there any way to TAR a 
> directory with file paths longer than 100 chars?
>

-- 
You received this message because you are subscribed to the Google 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: Do I need to unset variables in a for loop?

[Pierre Durand]

>
> I "believe" in PHP a for loop keeps the variable in memory until the end 
> of the script and if you want to remove the variable from memory you need 
> to unset the variable to help conserve memory. 


https://en.wikipedia.org/wiki/Cargo_cult

Le mardi 9 mai 2017 00:29:14 UTC+2, var...@gmail.com a écrit :
>
> I have heard that golang has excellent memory management / garbage 
> collection. If I am preforming millions of calculations in a for loop do I 
> need to unset a variable before the end of the for loop to help with memory 
> or does golang do that for me? I "believe" in PHP a for loop keeps the 
> variable in memory until the end of the script and if you want to remove 
> the variable from memory you need to unset the variable to help conserve 
> memory. 
>

-- 
You received this message because you are subscribed to the Google 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: Do I need to unset variables in a for loop?

[Ian Davis]

On Tue, 9 May 2017, at 04:31 PM, Pierre Durand wrote:
>> I "believe" in PHP a for loop keeps the variable in memory until the
>> end of the script and if you want to remove the variable from memory
>> you need to unset the variable to help conserve memory.> 
> https://en.wikipedia.org/wiki/Cargo_cult

I don't believe this is helpful to the questioner who was simply
explaining their understanding.
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: Do I need to unset variables in a for loop?

[Jesper Louis Andersen]

>
>
> I don't believe this is helpful to the questioner who was simply
> explaining their understanding.
>
>
A reference to cargo cults is useful insofar one should study why something
happens rather than copying a hearsay. On the other hand, it doesn't give
you much tooling: you can't solve the problem just by knowing you might
have run into the cargo cult trap---which we all do from time to time.

The problem really has to do with how different programming languages
handle variable scopes and how their implementations implement those
scoping rules. Ian already answered the gist: Go handles the liveness of
the variables well and you don't need to hint it, usually.

As for PHP, the story is likely more complex and also relates to the PHP
system you are using, what mode you are running PHP in, what configuration
you chose and so on. It is one of those languages I've selectively avoided
when I could[0], so I'm afraid I can't be of much help in explaining its
inner workings.

[0] This list also includes C++, Java, C#, and Javascript. YMMV :)

-- 
You received this message because you are subscribed to the Google 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: Do I need to unset variables in a for loop?

[Ian Davis]

On Tue, 9 May 2017, at 05:07 PM, Jesper Louis Andersen wrote:
>> 
>> I don't believe this is helpful to the questioner who was simply
>> explaining their understanding.>> 
> 
> A reference to cargo cults is useful insofar one should study why
> something happens rather than copying a hearsay. On the other hand, it
> doesn't give you much tooling: you can't solve the problem just by
> knowing you might have run into the cargo cult trap---which we all do
> from time to time.
Quite. But simply posting a link to wikipedia's page on Cargo Cult is
not helpful to newcomers from other languages and is belittling. The
OP's message was asking about Go. Their belief in some possible PHP
behaviour is irrelevant to the answer about Go's behaviour so no-one
needs to imply they are blindly copying patterns - after all they are
asking a question to find out more.
Let's take the time to be extra welcoming to newcomers.

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] encoding/asn1: Accept the non-PrintableString character underscore

[Ivan Borshukov]

Hi Gohpers,

I need to deal with certificates which contain '_'. Unfortunately, the '_' 
is not treated like a printable string character from Go.
I read through the discussions in [1], [2], but unfortunately none of them 
proposes a work around.

Can you suggest a solution other than forking the x509 and asn1 packages or 
building with custom standard library.

The exact piece of functionality i need is x509.ParseCertificate, which 
internally relies on asn1.Marshal.


Thanks in advance!
Regards,
Ivan

[1] https://github.com/golang/go/issues/14017
[2] https://groups.google.com/forum/#!msg/golang-nuts/_5LLpAZpwck/AiClr5ZvCwAJ

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

Re: [go-nuts] why received can be defined with/without pointer?

[Volker Dobler]

I must admit you lost me.

Thus just some minor notes:

On Tuesday, 9 May 2017 16:05:16 UTC+2, mhh...@gmail.com wrote:
>
>
> Help me to not copy a pointer value when its inappropriate.
>

Copying a pointer value is one of the most trivial and fast operations
imaginable.
Maybe you are using the term "pointer value" in some non-standard way here?
 

> If there s a purpose at defining star/nostar on a type,
> but not mix them either,
> help me to make that happen with ease, rather than pain.
>  
> That is, i agree there s point in defining star/nostar like property on a 
> type,
> (note i don t speak of receiver at purpose), see below.
>

Maybe this is part of the confusion. The current language (as opposed
to some other hypothetical language, probably better discussed on
some other mailing list) has no star or nostar properties on types.
Some types carry methods. Some don't. Some types are intimately
related like *T and T and share methods.
 

> yes. The consumer can decide how to consume the value,
> according if its provided/defined type is star/nostar.
>
> //defined
> var x &T{} // put on heap
> var x T // put on stack
>

This is definitely a misconception: Allocation on heap vs stack is
totaly unrelated to value methods vs pointer methods. Both examples
might be allocated on the stack or on the heap and this depends
on other factors than methods of T.
 

>
> // provided
> //func (r Value) n(x T) {(&x).Hello()} // x passed from stack (there might 
> be some magic here, not the point, i think)
> //func (r Value) n(x *T) {(*x).Hello()} // always get x from heap
> //func (r Value) n(x InterfaceDef){x.Hello()} // x is pointer to value 
> that matches intf.
>

None of these explanations are accurate.
 

>
> Why does it matter that the declarer knows about this in its receiver ? 
> I can t find much examples about that, besides testing if the receiver is 
> nil.
>
> That the declarer defines a type to be handled by copy 
> needs proper out values,
> not only nostar def on the receiver,
> does it ?
>

I'm sorry, I do not understand what you are asking.
 

>
> yes, i m really focused about the receiver.
>
> by incidence i come to think about the struct, indeed somehow,
>
> type S ref { a int64; b[3]complex128 } // prevent copy of S
> type S value { a int64; b[3]complex128 } // prevent referencing to S
> type S struct { a int64; b[3]complex128 } // does not matter
>

It would be helpful if you would define what you mean exactly
when you say "prevent copy" or "prevent referencing" as "referencing"
is pretty vague. How would a=b work if b was of "prevent copy" type?


What can i do with `func (x *T)...` i can not do with `func (x T)`,
> except checking for T==nil ?
>

Like explained several times in this thread:
func (x *T) lets you modify *x 

 
>> A "non-star" receiver would be a method on a value
>> (non-pointer, non-interface) type.
>> This would basically disallow methods to mutate the receiver
>> state as only a copy of the receiver would be mutated.
>> Are you proposing that methods on values should not
>> operate on a copy of the value? 
>>
>
> The consumer can tell about it.
>
> If he receives a value `func (x T)` he can say `x.Hello()` or 
> `(&x).Hello()`
> If he receives a pointer `func (x *T)` he can say `x.Hello()` or 
> `(*x).Hello()` 
>
> if he defines `var x T` and do  `(&x).Hello()` is weird.
> if he defines `var x *T` and do  `(*x).Hello()` is weird.
>
>
Again: I have to admit I'm lost and have no idea what you
try to express.
  
Regards

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.

[go-nuts] Re: Delve v1.0.0-rc.1 release

[ojucie]

Derek, I want to say a big "thank you" to you and all people involved in 
this project.

Delve became an indispensible tool for me. I feel much safer after 
executing new code step by step, and I am sure I am not alone.

I owe you one, guys.

-- 
You received this message because you are subscribed to the Google 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: Delve v1.0.0-rc.1 release

[Derek Parker]

Really glad to hear it's been a useful tool for you, always great to hear!


On Tuesday, May 9, 2017 at 12:04:23 PM UTC-7, JuciÊ Andrade wrote:
>
> Derek, I want to say a big "thank you" to you and all people involved in 
> this project.
>
> Delve became an indispensible tool for me. I feel much safer after 
> executing new code step by step, and I am sure I am not alone.
>
> I owe you one, guys.
>
>

-- 
You received this message because you are subscribed to the Google 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: Delve v1.0.0-rc.1 release

[Derek Parker]

Really glad that it's been a useful tool for you, always great to hear!

On Tuesday, May 9, 2017 at 12:04:23 PM UTC-7, JuciÊ Andrade wrote:
>
> Derek, I want to say a big "thank you" to you and all people involved in 
> this project.
>
> Delve became an indispensible tool for me. I feel much safer after 
> executing new code step by step, and I am sure I am not alone.
>
> I owe you one, guys.
>
>

-- 
You received this message because you are subscribed to the Google 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] unexpected numerical behavior in float64 conversions

[Ed Vielmetti]

Consider the following code snippet, at https://play.golang.org/p/hUUF9O-p-k

Using go 1.8.1 (same thing with current master branch)

package main
func main() {
x := float64(-1)
println(uint64(x))
println(int64(x))
println(uint64(int64(x)))
}

On ARM64:
0
-1
18446744073709551615
 
On x86:
 
18446744073709551615
-1
18446744073709551615


The comment from the ARM engineer: "It seems on arm we are using FCVTZU, 
for rounding to unsigned, which is what the code example is doing. Except 
on x86 they are rounding to signed int, and then dropping the sign."

I'd like to know what the results are on other non-ARM, non-x86 platforms 
(Power, Z, MIPS) to know what level of variety exists in this result and 
then adjust the code path everywhere to do the right thing.

thanks

Ed

Ed Vielmetti, e...@packet.net

-- 
You received this message because you are subscribed to the Google 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] unexpected numerical behavior in float64 conversions

[Ian Lance Taylor]

On Tue, May 9, 2017 at 2:10 PM, Ed Vielmetti  wrote:
>
> Consider the following code snippet, at https://play.golang.org/p/hUUF9O-p-k
>
> Using go 1.8.1 (same thing with current master branch)
>
> package main
> func main() {
> x := float64(-1)
> println(uint64(x))
> println(int64(x))
> println(uint64(int64(x)))
> }
>
> On ARM64:
> 0
> -1
> 18446744073709551615
>
> On x86:
>
> 18446744073709551615
> -1
> 18446744073709551615
>
>
> The comment from the ARM engineer: "It seems on arm we are using FCVTZU, for
> rounding to unsigned, which is what the code example is doing. Except on x86
> they are rounding to signed int, and then dropping the sign."
>
> I'd like to know what the results are on other non-ARM, non-x86 platforms
> (Power, Z, MIPS) to know what level of variety exists in this result and
> then adjust the code path everywhere to do the right thing.

For the record, the spec says, in
https://golang.org/ref/spec#Conversions: "In all non-constant
conversions involving floating-point or complex values, if the result
type cannot represent the value the conversion succeeds but the result
value is implementation-dependent."  That is the case that applies
here: you are converting a negative floating point number to uint64,
which can not represent a negative value, so the result is
implementation-dependent.  The conversion to int64 works, of course.
And the conversion to int64 and then to uint64 succeeds in converting
to int64, and when converting to uint64 follows a different rule:
"When converting between integer types, if the value is a signed
integer, it is sign extended to implicit infinite precision; otherwise
it is zero extended. It is then truncated to fit in the result type's
size."

So, basically, don't convert a negative floating point number to an
unsigned integer 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.

[go-nuts] Re: Creating shared-libraries which override existing system functions?

[Donovan]

make the return type in your go program C.int and it'll compile.

then using LD_PRELOAD against the so should work.

On Monday, May 8, 2017 at 5:44:09 PM UTC-4, Tony Walker wrote:
>
> Hi All,
>
> I'd like to experiment writing a shared library that will override system 
> functions via LD_LIBRARY_PATH. I'd like to achieve something like the basic 
> functionality demonstrated here where rand() is overridden.
>
> If I write a simple function to overwrite it (see here 
> ) I get the following error when 
> trying to compile with go build -o rand.so -buildmode=c-shared test.go (Go 
> 1.7.4 - same with 1.8 but a slightly different error):
>
> # command-line-arguments
> In file included from $WORK/command-line-arguments/_obj/_cgo_export.c:3:0:
> /tmp/go-build613177413/command-line-arguments/_obj/_cgo_export.h:55:14: 
> error: conflicting types for ‘rand’
>  extern GoInt rand();
>   ^~~~
> In file included from $WORK/command-line-arguments/_obj/_cgo_export.c:2:0:
> /usr/include/stdlib.h:335:12: note: previous declaration of ‘rand’ was here
>  extern int rand (void) __THROW;
> ^~~~
> /tmp/go-build613177413/command-line-arguments/_obj/_cgo_export.c:17:7: 
> error: conflicting types for ‘rand’
>  GoInt rand()
>^~~~
> In file included from $WORK/command-line-arguments/_obj/_cgo_export.c:2:0:
> /usr/include/stdlib.h:335:12: note: previous declaration of ‘rand’ was here
>  extern int rand (void) __THROW;
> ^~~~
> I'm not clear whether I simply need to find a way to declare an equivalent 
> signature which matches the stdlib, or whether creating a function which is 
> already defined is just not allowed.
>
> Can anyone help here?
>
> Thanks,
>
> Tony
>

-- 
You received this message because you are subscribed to the Google 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.