Re: [go-nuts] Questions about assembly and calling conventions

[nsajko]

> On previous versions the assembly output reported the base register as FP 
but the offset was from SP.

That's it! Go 1.8 had a bug. ;)

Thanks

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

Re: [go-nuts] could not determine kind of name for C.uint32_t

[Ignazio Di Napoli]

Thank you! I found out: Ubuntu and MSYS2 ship two different versions that 
have different types in header according Go rules. That's why I cannot use 
the same code.

-- 
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: Best practice for Method Receivers

[peterGo]

Frequently Asked Questions (FAQ)
Should I define methods on values or pointers?
https://golang.org/doc/faq#methods_on_values_or_pointers

If some of the methods of the type must have pointer receivers, the rest 
should too, so the method set is consistent regardless of how the type is 
used.

Peter

On Friday, March 24, 2017 at 9:20:06 PM UTC-4, st ov wrote:
>
> Is it idiomatic to mix-&-match pointer and value method receivers for a 
> given type? 
> or in *general*, if a single method requires a pointer receiver than *all 
> methods* should take a pointer, regardless if a value receiver is 
> appropriate?
>
> For example, should Foo.SetVal also be a pointer receiver even though a 
> value receiver would be acceptable?
> https://play.golang.org/p/rd_6BLol8O
>
> type Foo struct{
> ref []int
> val int
> }
>
> // would not set if method receiver is value receiver (foo Foo)
> func (foo *Foo) SetRef(ref []int) {
> foo.ref = ref
> }
> func (foo Foo) SetVal(val int) {
> foo.val = val
> }
>
> func main() {
> foo := Foo{}
> foo.SetRef([]int{1,2,3})
> foo.SetVal(1)
> 
> fmt.Printf("%v",foo) // {[1 2 3] 0}
> }
>
>
>
>

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

Re: [go-nuts] Go -> C++ transpiler idea: Miracle child or horrible abomination?

[Raffaele Sena]

go get github.com/raff/walkngo 

If you use --lang=c it will actually generate c++ code.

It's not perfect but it does the bulk of the conversion. Unfortunately working 
with only the ast has it's limits (and I wrote this before the ssa stuff was 
available)

-- Raffaele

> On Mar 24, 2017, at 6:22 PM, Brad  wrote:
> 
> Interested in any feedback about the idea of making a Go -> C++ transpiler.  
> Here's the rationale:
> 
> * Go as a language has lots of awesome things that make it highly productive. 
>  Lots of Gophers would love to use Go for more projects but some common 
> issues include:
> * Trying to convince your team or management to adopt Go over a "more 
> traditional" language can be a tough sell: Your PHB is likely to tell you 
> it's not worth the risk, because the next developer he hires may not like Go 
> and he'll be screwed, whereas he knows he can find someone who will write C++ 
> or Java.
> * And there is also the issue of the environments in which Go will run.  On 
> embedded platforms (e.g. Parallax Propeller, Arduino) you can write C++, but 
> you're not going to get a Go compiler for it.
> * There's also the fact in a scenario where Go co-exists with C or C++, Go 
> has to have the main function and has to build the executable. Unless you 
> build a shared library, you can't just start implementing parts of your 
> project in Go and gradually phase things over.
> 
> It's also worth noting that some of these scenarios just will never support 
> all the features of the Go language, and so full support will not happen.  
> You probably won't get goroutines on an Arduino, for example. But, that 
> doesn't mean it wouldn't be useful to be able to write Go code in these cases 
> that doesn't use that feature and is otherwise 100% correct Go.
> 
> So, what if the following existed:
> 
> * Tool that converts Go to C++:
> * Comments and formatting are preserved - the resulting C++ is readable.  You 
> can tell your boss "there's no loss here - if this doesn't work, we'll throw 
> away the Go code and keep working on the C++", even though you know you will 
> burn in hell for doing that ;)
> * Language constructs which have an obvious simple mapping are just directly 
> converted (byte -> uint8_t, structs are structs, etc.)
> * Things that can be done with C++ code but are just ugly (e.g. defer, 
> implemented with goto) would be done like that - the transpiler would just 
> emit that code.
> * Features that are syntactic sugar around runtime implementations are emits 
> as calls to a stripped down version of the runtime that just does the bare 
> minimum to support what's needed: e.g. maps and slices are implemented with a 
> C++ template - the template is the same one that is just dropped in the 
> output as "map.h" and the transpiler emits code that uses it.
> * Heap allocations are mapped to a GC lib implemented in C++ - same as maps 
> above, just more complicated.  Same with channels.
> * Reflection could be done by emitting a bunch of type info and making all 
> that work, but probably wouldn't get around to doing this in a first version.
> * "go" gets mapped to pthread_create(), cognew() or whatever.
> * As much as possible this things are kept as some sort of simple template of 
> the corresponding C++ code to output, so you can easily adjust how 
> allocations or "go" or whatever are emitted for a particular environment.
> * The standard library would probably need to be forked, the things that are 
> heavily intertwined with the Go runtime ("runtime", "reflection", etc.) would 
> probably just not be available initially, and the ones that can be patched 
> and transpiled would be, and then some would probably just need a separate 
> implementation in C++ (e.g. "sync").  There would be an obvious way to do 
> this and it would be a normal thing in this scenario to say: "let's drop in 
> an implementation of fmt that supports only the barebones formatting for use 
> on embedded systems", etc.
> * Features/packages that are not supported would result in a transpiler 
> error.  I.e. some things "you just can't do" with this tool and that's okay.
> 
> Assuming this actually worked, it might considerably lower the bar for 
> adopting Go, and allow it to be used to develop in environments where we're 
> not likely to see a port of the compiler any time soon.  (Or where it's 
> literally impossible because there are things in the language that the 
> platform just can't do.)
> 
> I could potentially devote some time to building this out, but I wanted to 
> see if anyone had feedback on the concept.  I realize it's not a simple 
> project, but with the above setup it could be implemented incrementally.
> -- 
> 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 

[go-nuts] Go -> C++ transpiler idea: Miracle child or horrible abomination?

[Brad]

Interested in any feedback about the idea of making a Go -> C++ transpiler. 
 Here's the rationale:

* Go as a language has lots of awesome things that make it highly 
productive.  Lots of Gophers would love to use Go for more projects but 
some common issues include:
* Trying to convince your team or management to adopt Go over a "more 
traditional" language can be a tough sell: Your PHB is likely to tell you 
it's not worth the risk, because the next developer he hires may not like 
Go and he'll be screwed, whereas he knows he can find someone who will 
write C++ or Java.
* And there is also the issue of the environments in which Go will run.  On 
embedded platforms (e.g. Parallax Propeller, Arduino) you can write C++, 
but you're not going to get a Go compiler for it.
* There's also the fact in a scenario where Go co-exists with C or C++, Go 
has to have the main function and has to build the executable. Unless you 
build a shared library, you can't just start implementing parts of your 
project in Go and gradually phase things over.

It's also worth noting that some of these scenarios just will never support 
all the features of the Go language, and so full support will not happen. 
 You probably won't get goroutines on an Arduino, for example. But, that 
doesn't mean it wouldn't be useful to be able to write Go code in these 
cases that doesn't use that feature and is otherwise 100% correct Go.

So, what if the following existed:

* Tool that converts Go to C++:
* Comments and formatting are preserved - the resulting C++ is readable. 
 You can tell your boss "there's no loss here - if this doesn't work, we'll 
throw away the Go code and keep working on the C++", even though you know 
you will burn in hell for doing that ;)
* Language constructs which have an obvious simple mapping are just 
directly converted (byte -> uint8_t, structs are structs, etc.)
* Things that can be done with C++ code but are just ugly (e.g. defer, 
implemented with goto) would be done like that - the transpiler would just 
emit that code.
* Features that are syntactic sugar around runtime implementations are 
emits as calls to a stripped down version of the runtime that just does the 
bare minimum to support what's needed: e.g. maps and slices are implemented 
with a C++ template - the template is the same one that is just dropped in 
the output as "map.h" and the transpiler emits code that uses it.
* Heap allocations are mapped to a GC lib implemented in C++ - same as maps 
above, just more complicated.  Same with channels.
* Reflection could be done by emitting a bunch of type info and making all 
that work, but probably wouldn't get around to doing this in a first 
version.
* "go" gets mapped to pthread_create(), cognew() or whatever.
* As much as possible this things are kept as some sort of simple template 
of the corresponding C++ code to output, so you can easily adjust how 
allocations or "go" or whatever are emitted for a particular environment.
* The standard library would probably need to be forked, the things that 
are heavily intertwined with the Go runtime ("runtime", "reflection", etc.) 
would probably just not be available initially, and the ones that can be 
patched and transpiled would be, and then some would probably just need a 
separate implementation in C++ (e.g. "sync").  There would be an obvious 
way to do this and it would be a normal thing in this scenario to say: 
"let's drop in an implementation of fmt that supports only the barebones 
formatting for use on embedded systems", etc.
* Features/packages that are not supported would result in a transpiler 
error.  I.e. some things "you just can't do" with this tool and that's okay.

Assuming this actually worked, it might considerably lower the bar for 
adopting Go, and allow it to be used to develop in environments where we're 
not likely to see a port of the compiler any time soon.  (Or where it's 
literally impossible because there are things in the language that the 
platform just can't do.)

I could potentially devote some time to building this out, but I wanted to 
see if anyone had feedback on the concept.  I realize it's not a simple 
project, but with the above setup it could be implemented incrementally.

-- 
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: Algorithm Club

[Michael Jones]

I think I was saying that what I seem to want personally is the "simple,
weak, slight" thing that you likely see as failure.

The opposite end of that--where everything is a list and can be composed
without special regard (lisp) or everything is an object that can receive
any message (smalltalk) are comfortable for me, but just not what I find
myself wanting very often.

My own view is not important in the sense that a broad survey would be, but
since it seems much less than what people seem to dream of, I wanted to
share that maybe people could be happy with less than they seek.

Or maybe that ultimate typeless generality is what others really need
somehow. I would not know.

On Fri, Mar 24, 2017 at 6:13 PM David Collier-Brown 
wrote:

> We still don't understand genrality: the current generics are
> unimpressive. The proposals for Go are typically "let's do something that
> has failed already, in hopes that trying it agin will have a different
> result".  That, alas, is one of the definitions of insanity.
>
> Due caution is advised!
>
>
> --
> 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.
>
-- 
Michael T. Jones
michael.jo...@gmail.com

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

Re: [go-nuts] could not determine kind of name for C.uint32_t

[Justin Israel]

On Sat, Mar 25, 2017, 9:55 AM Ignazio Di Napoli  wrote:

> When I include stdints.h, the error is:
>
> cannot use C.uint32_t(bi.Time_reference_low) (type C.uint32_t) as type
> C.uint in assignment
>

If cgo follows the same rule as the Go spec, then it won't want to do
implicit conversations between types. Have you tried being explicit by
wrapping it in C.uint() ?


> on line:
>
> c.time_reference_low = C.uint32_t(bi.Time_reference_low)
>
> Even if in stdint.h there is:
>
>typedef unsigned int uint32_t;
>
> and the c is of type:
>
> #define SF_BROADCAST_INFO_VAR(coding_hist_size) \
> struct \
> { char description [256] ; \
> char originator [32] ; \
> char originator_reference [32] ; \
> char origination_date [10] ; \
> char origination_time [8] ; \
> unsigned int time_reference_low ; \
> unsigned int time_reference_high ; \
> short version ; \
> char umid [64] ; \
> char reserved [190] ; \
> unsigned int coding_history_size ; \
> char coding_history [coding_hist_size] ; \
> }
>
> I use gcc 6.2.0.
>
> Any idea?
>
> Thank you.
>
> --
> 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] Assembly jump instruction operands

[nsajko]

In the assembly output here: 
https://drive.google.com/open?id=0B63rdrZtwIE9R3M4cGxrSFhmT00

some jump instructions have 2 operands. What are their semantics?

-- 
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] Best practice for Method Receivers

[st ov]

Is it idiomatic to mix-&-match pointer and value method receivers for a 
given type? 
or in *general*, if a single method requires a pointer receiver than *all 
methods* should take a pointer, regardless if a value receiver is 
appropriate?

For example, should Foo.SetVal also be a pointer receiver even though a 
value receiver would be acceptable?
https://play.golang.org/p/rd_6BLol8O

type Foo struct{
ref []int
val int
}

// would not set if method receiver is value receiver (foo Foo)
func (foo *Foo) SetRef(ref []int) {
foo.ref = ref
}
func (foo Foo) SetVal(val int) {
foo.val = val
}

func main() {
foo := Foo{}
foo.SetRef([]int{1,2,3})
foo.SetVal(1)

fmt.Printf("%v",foo) // {[1 2 3] 0}
}



-- 
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: Algorithm Club

[David Collier-Brown]

We still don't understand genrality: the current generics are unimpressive. 
The proposals for Go are typically "let's do something that has failed 
already, in hopes that trying it agin will have a different result".  That, 
alas, is one of the definitions of insanity.

Due caution is advised!


-- 
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] Algorithm Club

[Michael Jones]

Type-based generally is all that I ever seem to want...making a macro-like
LLRB heap concrete to handle objects of my own type and with my own
comparison function.  I believe this is what Rob speaks of. I've personally
never needed to sort or order a bunch of unknown "things"

On Fri, Mar 24, 2017 at 12:16 PM Rob Pike  wrote:

> Algorithms are not helped by generic types as much as by polymorphism, a
> related but distinct subject.
>
> -rob
>
>
> On Fri, Mar 24, 2017 at 12:10 PM, Mandolyte  wrote:
>
> The recent survey reveled that generics was thing that would improve Go
> the most. But at 16%, the responses were rather spread out and only 1/3
> seemed to think that Go needed any improvement at all - see link #1. I
> think most will concede that generics would help development of algorithms,
> libraries, and frameworks. So in the spirit of friendly rivalry, here is a
> list of algorithms developed for Swift:
>
> https://github.com/raywenderlich/swift-algorithm-club
>
> As you might guess, it is chock-full of generics. Yeah, I'm a little
> envious. :-) enjoy...
>
>
>
> #1 https://blog.golang.org/survey2016-results
>
> --
> 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.
>
-- 
Michael T. Jones
michael.jo...@gmail.com

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

Re: [go-nuts] could not determine kind of name for C.uint32_t

[Ignazio Di Napoli]

When I include stdints.h, the error is:

cannot use C.uint32_t(bi.Time_reference_low) (type C.uint32_t) as type 
C.uint in assignment

on line:

c.time_reference_low = C.uint32_t(bi.Time_reference_low)

Even if in stdint.h there is:

   typedef unsigned int uint32_t;

and the c is of type:

#define SF_BROADCAST_INFO_VAR(coding_hist_size) \
struct \
{ char description [256] ; \
char originator [32] ; \
char originator_reference [32] ; \
char origination_date [10] ; \
char origination_time [8] ; \
unsigned int time_reference_low ; \
unsigned int time_reference_high ; \
short version ; \
char umid [64] ; \
char reserved [190] ; \
unsigned int coding_history_size ; \
char coding_history [coding_hist_size] ; \
}

I use gcc 6.2.0. 

Any idea?

Thank you.

-- 
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] Algorithm Club

[Rob Pike]

Algorithms are not helped by generic types as much as by polymorphism, a
related but distinct subject.

-rob


On Fri, Mar 24, 2017 at 12:10 PM, Mandolyte  wrote:

> The recent survey reveled that generics was thing that would improve Go
> the most. But at 16%, the responses were rather spread out and only 1/3
> seemed to think that Go needed any improvement at all - see link #1. I
> think most will concede that generics would help development of algorithms,
> libraries, and frameworks. So in the spirit of friendly rivalry, here is a
> list of algorithms developed for Swift:
>
> https://github.com/raywenderlich/swift-algorithm-club
>
> As you might guess, it is chock-full of generics. Yeah, I'm a little
> envious. :-) enjoy...
>
>
>
> #1 https://blog.golang.org/survey2016-results
>
> --
> 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] Algorithm Club

[Mandolyte]

The recent survey reveled that generics was thing that would improve Go the 
most. But at 16%, the responses were rather spread out and only 1/3 seemed 
to think that Go needed any improvement at all - see link #1. I think most 
will concede that generics would help development of algorithms, libraries, 
and frameworks. So in the spirit of friendly rivalry, here is a list of 
algorithms developed for Swift:

https://github.com/raywenderlich/swift-algorithm-club

As you might guess, it is chock-full of generics. Yeah, I'm a little 
envious. :-) enjoy...



#1 https://blog.golang.org/survey2016-results

-- 
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] Questions about assembly and calling conventions

[Rob Pike]

The assembly documentation in golang.org/doc/asm.html is accurate in this
respect, I believe. By "in this respect" I mean both what the assembler
accepts and interprets and what is intended.

The compiler output for -S has not been brought to the same standard and
may well use SP when FP would be more correct.

-rob


On Fri, Mar 24, 2017 at 11:27 AM, Caleb Spare  wrote:

> I hope someone else knows. I've also been confused by the difference
> in the offsets in the past, and when I asked about it I was told that
> the output of go tool compile -S is just different than what you write
> by hand. Unfortunately I don't think that the -S output is documented.
> You might have to read source to figure it out.
>
> On Fri, Mar 24, 2017 at 4:39 AM,   wrote:
> > Should not the first parameter of a function be passed in 0(FP)? See this
> > example assembly (produced by go tool compile -S), where 0(FP) gets
> skipped
> > over and the argument is apparently loaded from 8(FP):
> >
> > https://drive.google.com/open?id=0B63rdrZtwIE9dHZqWmoxdXIzNnc
> >
> > Another confusing thing is that conditional jumps are sometimes invoked
> with
> > two operands, see any of the 8 almost equal functions here:
> >
> > https://drive.google.com/open?id=0B63rdrZtwIE9R3M4cGxrSFhmT00
> >
> > (also, the first parameter is even further from 0(FP) now).
> >
> >
> > Regards,
> > Neven
> >
> > --
> > 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: Unsafe string/slice conversions

[Jerome Froelich]

It just occurred to me that there may actually be a problem with the 
conversion functions in the example. Specifically, since the Go 
compiler can allocate byte slices on the heap if they do not escape, the 
following function may be invalid:

func foo() string {
v := []uint64{1,2,3}
s := sliceToStringUnsafe(v)
return s
}

Admittedly, this is a contrived example but I think it can illustrate the 
issue. As noted on this previous thread 
 the 
compiler will allocate slices on the heap if it can prove they do not 
escape. Consequently, in the function above, the data for v can be 
allocated on the stack. In such a case, since sliceToStringUnsafe only 
adjusts pointers, the string it returns will point to this stack-allocated 
data. However, once foo returns, this data is no longer valid and can be 
overwritten by subsequent functions that are pushed on the stack.

On Thursday, March 23, 2017 at 9:05:48 PM UTC-4, Caleb Spare wrote:
>
> Filed: https://github.com/golang/go/issues/19687 
>
> On Thu, Mar 23, 2017 at 4:41 PM, 'Keith Randall' via golang-nuts 
>  wrote: 
> > 
> > 
> > On Thursday, March 23, 2017 at 4:24:40 PM UTC-7, Caleb Spare wrote: 
> >> 
> >> That's very good to know. Thanks, Ian. 
> >> 
> >> Unfortunately if I use this KeepAlive-based fix, p escapes and so the 
> >> function now allocates. I guess I'll stick with the original version 
> >> from my first email. 
> >> 
> >> Does this indicate a shortcoming of either compiler support for 
> >> KeepAlive or escape analysis in general? 
> >> 
> > 
> > KeepAlive shouldn't be making things escape.  If that is happening you 
> > should file a bug for it. 
> > The definition is: 
> > 
> > //go:noinline 
> > func KeepAlive(interface{}) {} 
> > 
> > which should be pretty easy to analyze :) 
> > 
> >> Caleb 
> >> 
> >> On Thu, Mar 23, 2017 at 10:26 AM, Ian Lance Taylor  
> >> wrote: 
> >> > On Thu, Mar 23, 2017 at 9:16 AM, Caleb Spare  
> wrote: 
> >> >> 
> >> >> Brief follow-up: does the seeming validity of the code rely at all 
> on 
> >> >> the fact that the indicated line is written as a single line? What 
> if, 
> >> >> instead, a *StringHeader var were extracted? 
> >> >> 
> >> >> func stringToSliceUnsafe(s string) []uint64 { 
> >> >> var v []uint64 
> >> >> h := (*reflect.StringHeader)(unsafe.Pointer()) // <-- 
> >> >> sh := (*reflect.SliceHeader)(unsafe.Pointer()) 
> >> >> sh.Data = h.Data 
> >> >> sh.Len = h.Len >> 3 
> >> >> sh.Cap = h.Len >> 3 
> >> >> return v 
> >> >> } 
> >> >> 
> >> >> (Play link: https://play.golang.org/p/BmGtYTsGNY) 
> >> >> 
> >> >> Does h keep s alive? A strict reading of rule 6 doesn't seem to say 
> >> >> that keeping a *StringHeader or *SliceHeader around keeps the 
> >> >> underlying string/slice alive (but it's sort of implied by the rule 
> 6 
> >> >> example code, which doesn't refer to s after converting it to a 
> >> >> *StringHeader). 
> >> > 
> >> > That is an interesting point.  I don't think there is anything 
> keeping 
> >> > s alive here.  I think this isn't quite the same as the example in 
> the 
> >> > docs, because that example is assuming that you are doing to use s 
> >> > after setting the fields--why else would you be doing that?  In this 
> >> > case it does seem theoretically possible that s could be freed 
> between 
> >> > the assignment to h and the use of h.Data.  With the current and 
> >> > foreseeable toolchains it's a purely theoretical problem, since there 
> >> > is no point there where the goroutine could be preempted and the fact 
> >> > that s is no longer referenced be detected.  But as a theoretical 
> >> > problem it does seem real.  One fix would be something like 
> >> > p :=  
> >> > h := (*reflect.StringHeader)(unsafe.Pointer(p)) 
> >> > sh := (*reflect.SliceHeader)(unsafe.Pointer()) 
> >> > sh.Data = h.Data 
> >> > sh.Len = ... 
> >> > sh.Cap = ... 
> >> > runtime.KeepAlive(p) 
> >> > 
> >> > 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...@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] Are these types discarded? Is this a compiler bug?

[Peter Kleiweg]

Op donderdag 23 maart 2017 20:58:53 UTC+1 schreef Ian Lance Taylor:
>
> On Thu, Mar 23, 2017 at 11:56 AM, Peter Kleiweg  > wrote: 
> > Op donderdag 23 maart 2017 17:46:18 UTC+1 schreef Ian Lance Taylor: 
> >> 
> >> On Thu, Mar 23, 2017 at 8:54 AM, Peter Kleiweg  
> wrote: 
> >> > Some code that includes C code compiles fine on Linux, but gives 
> strange 
> >> > errors on Darwin. 
> >> > 
> >> > 
> >> > In one source file, that doesn't include C, I have this: 
> >> > 
> >> > type reactor_socket struct { 
> >> > e State 
> >> > f func(State) error 
> >> > } 
> >> > 
> >> > and... 
> >> > 
> >> > reactor_socket{e: events, f: handler} 
> >> > 
> >> > 
> >> > 
> >> > In another file that does include C, I have this: 
> >> > 
> >> > type State int 
> >> > 
> >> > 
> >> > 
> >> > Compiling of the first source file gives these errors on the line 
> >> > creating 
> >> > the reactor_socket: 
> >> > 
> >> > workspace/go/src/github.com/pebbe/zmq4/reactor.go:57: cannot use 
> >> > events 
> >> > (type State) as type int in field value 
> >> > workspace/go/src/github.com/pebbe/zmq4/reactor.go:57: cannot use 
> >> > handler 
> >> > (type func(State) error) as type func(int) error in field value 
> >> > 
> >> > It looks like in one source file, the type State is preserved, while 
> in 
> >> > the 
> >> > other it is replaced by an int. 
> >> > 
> >> > 
> >> > Is this a compiler bug? What else could it be? 
> >> > 
> >> > Please see details at https://github.com/pebbe/zmq4/issues/97 
> >> 
> >> I suppose it could be a cgo bug.  I can't recreate it, but I'm using 
> >> GNU/Linux.  I tried both GCC and clang. 
> >> 
> >> Try running `go build -work` to preserve the temporary directory and 
> >> look at the generated .go files. 
> > 
> > 
> > There is no generated Go file corresponding to the file that generates 
> the 
> > error. 
>
> No, I wouldn't expect one, but it seems that the contents of the files 
> that are generated must be triggering the error somehow.  In 
> particular it might be interesting to compare the generated files on a 
> working system with the ones on a failing system. 
>

OK, here are all the 
differences: https://pkleiweg.home.xs4all.nl/go/diff.txt

-- 
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] could not determine kind of name for C.uint32_t

[Ignazio Di Napoli]

Thank you. Now it complains it cannot convert uint32_t to uint. It's a start. 
It just seems strange I can compile under Windows with MinGW 64bit and not 
Ubuntu 64bit.

-- 
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] could not determine kind of name for C.uint32_t

[Jan Mercl]

On Fri, Mar 24, 2017 at 4:54 PM Ignazio Di Napoli 
wrote:

> How can debug the problem?

Assuming the error comes from[0], I would try to add  to the list
of C includes near the top of that file.

  [0]:
https://github.com/mkb218/gosndfile/blob/14851e87aed3b4236528a981f805f969e08ef2f8/sndfile/command.go#L399

-- 

-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] could not determine kind of name for C.uint32_t

[Ignazio Di Napoli]

Hello everyone,

I get this error while compiling gosndfile under Ubuntu. The same code 
compiled fine under Windows using MSYS2.
I couldn't find any information on this problem, if not checking for blank 
lines before <>, that obviously are not there since it works 
under MSYS2. 
I also checked line endings and they're fine.
How can debug the problem?


Thank you
Ignazio

-- 
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] Missing x509.MarshalPKCS8PrivateKey

[James Hartig]

There's x509.ParsePKCS8PrivateKey but no x509.MarshalPKCS8PrivateKey, which 
is unlike the other x509.ParseTPrivateKey and x509.MarshalTPrivateKey 
combinations. It seems trivial, so I'm curious why it was omitted?

Assuming no objections, I'd be willing to make a patch in gerrit adding 
this.

-- 
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] Discussion on moving projects from syscall to sys/[platform]

[laboger]

I think the question was intended to be more general, not just to fix this
situation.  If users are supposed to migrate from the syscall package to
 sys/unix then all functionality in syscall needs to be available in 
sys/unix.
I don't think we want to have a mixture of references to syscall and 
sys/unix
because then it will be confusing when to use which one.

Here are the issues that were found so far:

syscall.Signal and syscall.Errno are used to convert signal and errno 
values to
the appropriate integer type for the target platform.  These can be handled 
as Ian suggests,
by defining a type in sys/unix that implement the interface from os.

There is also the struct SysProcAttr in syscall which does not appear in 
sys/unix, and is used by
os.  Not sure what to do with that.

I will open an issue to follow up with these.

On Tuesday, March 21, 2017 at 8:30:10 PM UTC-5, Ian Lance Taylor wrote:
>
> On Tue, Mar 21, 2017 at 12:21 PM,   > wrote: 
> > We've found a bug in the syscall package (see 
> > https://github.com/opencontainers/runc/issues/1364), and the better 
> solution 
> > seems to be to move from syscall to sys. I've started updating some of 
> the 
> > runc code to see how big of a change it would be, and have gotten a bit 
> off 
> > in the weeds. I'd like some advice on how to properly switch over. 
> > 
> > The thing that is initially confusing me is the use of syscall's Signal. 
> For 
> > example, "sig := syscall.Signal(s)" (when handling signals a user might 
> send 
> > to a container's processes). Instead of using type syscall.Signal, is 
> there 
> > a sys type that is a direct replacement for Signal? It doesn't look like 
> it 
> > to me. 
> > 
> > I don't see a direct translation for Signal(0), either, and digging 
> around 
> > in the syscall code, nothing jumped out. 
> > 
> > It seems that it might be simplest to leave in syscall in some places 
> but 
> > use x/sys most of the time. 
>
> Currently as you can see x/sys/unix still uses syscall.Signal.  That 
> should probably be cleaned up with a new type defined in x/sys/unix 
> (that still implements the os.Signal interface).  But the bug you are 
> encountering seems entirely independent of this Signal issue.  I 
> wouldn't worry about tackling Signal just to fix some terminal ioctls. 
>
> 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] Questions about assembly and calling conventions

[nsajko]

Should not the first parameter of a function be passed in 0(FP)? See this 
example assembly (produced by go tool compile -S), where 0(FP) gets skipped 
over and the argument is apparently loaded from 8(FP):

https://drive.google.com/open?id=0B63rdrZtwIE9dHZqWmoxdXIzNnc

Another confusing thing is that conditional jumps are sometimes invoked 
with two operands, see any of the 8 almost equal functions here:

https://drive.google.com/open?id=0B63rdrZtwIE9R3M4cGxrSFhmT00

(also, the first parameter is even further from 0(FP) now).


Regards,
Neven

-- 
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: Converting Panic into Error

[Val]

Nice.
I think we can generalize to accepting any func() that we may want to 
prevent panicking: https://play.golang.org/p/Gj1e0PllFu
When signature is not exactly func(), e.g. func bad2(x int), then wrap in a 
closure.

It kind of reminds me of template.Must 
, just doing the opposite thing.

Cheers
 Val

On Friday, March 24, 2017 at 9:50:47 AM UTC+1, Henry wrote:
>
> Thanks for the reply, Andrei. Your solution works. 
>
> Jerome's solution doesn't work. I think Jerome and I made the wrong 
> assumption that recover returns an error. Apparently, recover returns an 
> interface. That's why recover assignment to error doesn't work.
>
> Thanks again for all the replies.
>
>

-- 
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: Converting Panic into Error

[Henry]

Thanks for the reply, Andrei. Your solution works. 

Jerome's solution doesn't work. I think Jerome and I made the wrong assumption 
that recover returns an error. Apparently, recover returns an interface. That's 
why recover assignment to error doesn't work.

Thanks again for all the replies.

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

[go-nuts] Converting Panic into Error

[Jérôme LAFORGE]

Hello, 
Try this:


func MustNotPanic() (err error)  {
 defer func(){
  err=recover()
 }()
 PanicFunction()
}

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