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

> 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

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

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

[go-nuts] Re: Best practice for Method Receivers

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.

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

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

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

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

Re: [go-nuts] Re: Algorithm Club

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)

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

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

[go-nuts] Assembly jump instruction operands

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

[go-nuts] Best practice for Method Receivers

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

[go-nuts] Re: Algorithm Club

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!

Re: [go-nuts] Algorithm Club

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

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

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:

Re: [go-nuts] Algorithm Club

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

[go-nuts] Algorithm Club

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,

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

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

Re: [go-nuts] Re: Unsafe string/slice conversions

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}

Re: [go-nuts] Are these types discarded? Is this a compiler bug?

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

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

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

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

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]:

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

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

[go-nuts] Missing x509.MarshalPKCS8PrivateKey

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

Re: [go-nuts] Discussion on moving projects from syscall to sys/[platform]

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

[go-nuts] Questions about assembly and calling conventions

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

[go-nuts] Re: Converting Panic into Error

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

[go-nuts] Re: Converting Panic into Error

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

[go-nuts] Converting Panic into Error

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,