Re: [go-nuts] go for robotic control, walking balance, quad flight control

Soft realtime just needs fast responses within say 1/10 of the controlled system's smallest time constant. Most modern CPUs are fast enough for that even with elefantine Linux OS, no RTOS required. Hard realtime (e.g. for safety apps) needs interrupt handlers, triggered by hardware signals or

Re: [go-nuts] Are defered function calls executed?

In case of a non-nil error Close will not be executed and that is exactly what you want. The power of defer becomes obvious with more code after the defer which does not have to deal with any cleanup of previous steps because of the defer. Am Fr., 4. Jan. 2019 um 07:09 Uhr schrieb 伊藤和也 : > In the

Re: [go-nuts] Are defered function calls executed?

On Thu, Jan 3, 2019 at 11:10 PM 伊藤和也 wrote: > > In the first example, "ok" was not printed. > > func main() { >if(true) { > return >} >defer fmt.Println("ok") > } > > So in the second example, is the Close function executed after an error > occurs and returned. > > func main() {

[go-nuts] Are defered function calls executed?

In the first example, "ok" was not printed. func main() { if(true) { return } defer fmt.Println("ok") } So in the second example, is the Close function executed after an error occurs and returned. func main() { src, err := os.Open("text.txt") if err != nil { retur

[go-nuts] Re: C++ 11 to Golang convertor

I read somewhere that you can do some of the needed work using swig++, but like others have said, I don't think it would produce perfectly ported idiomatic code out of the box... -kdd -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscr

Re: [go-nuts] C++ 11 to Golang convertor

Quoting Andy Balholm (2019-01-03 18:34:35) >It's at [1]https://github.com/rsc/c2go. It might be a good starting >place, but there is one significant difference in approach from what >Eric is proposing. Russ incorporated all of the manual cleanup into the >tool (or config files) as s

Re: [go-nuts] Re: if/switch statements as expressions

yes. lisp was early (first?) to support unevaluated arguments via hold and other mechanisms. quite useful for this situation. On Thu, Jan 3, 2019 at 3:33 PM Milan Zamazal wrote: > alanfo writes: > > > Some languages which don't support the conditional operator or if/else > > expressions have an

Re: [go-nuts] C++ 11 to Golang convertor

It’s at https://github.com/rsc/c2go . It might be a good starting place, but there is one significant difference in approach from what Eric is proposing. Russ incorporated all of the manual cleanup into the tool (or config files) as special cases, rather than leaving

[go-nuts] [go-sql-driver/go]can't exec Rows.Close() when Rows.Scan/Rows.Next

when use QueryContext,data trace appear，but I think there is no problem on [go-sql-driver/go]。because QueryContext call initContextClose, call awaitDone asynchronous. when context timeout，awaitDone channel trigger。 will release buffer's data when Next/Scan。 I think Rows.close(err) should ad

[go-nuts] Re: Closure, recursion and higher-order functions

very often 在 2018年12月30日星期日 UTC+8上午12:07:38，伊藤和也写道： > > How often do you use closure, recursion and higher-order functions? > -- 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

[go-nuts] Re: if/switch statements as expressions

alanfo writes: > Some languages which don't support the conditional operator or if/else > expressions have an Iif function (or similar) instead. > > If generics are added to Go, it might be worth including something like > this in the standard library to cut down on boilerplate for simple cases

Re: [go-nuts] Re: C++ 11 to Golang convertor

On Thu, Jan 03, 2019 at 02:46:39PM -0800, Eric Raymond wrote: > On the other hand, I believe graceful, comment-preserving C to idiomatic-Go > transpilation is almost possible. By 'almost' I mean that the tool would > pass through a small enough percentage of untranslated residuals for > correct

[go-nuts] Re: C++ 11 to Golang convertor

On Thursday, January 3, 2019 at 12:11:06 PM UTC-5, Jake Montgomery wrote: > > I would note that any tool that ports from C++, or even C, to Go is going > to produce ugly, unmaintainable, and non-idiomatic code, at best. > These are two different cases. I agree that graceful C++ to Go transpilat

Re: [go-nuts] C++ 11 to Golang convertor

You don’t use CGo; you just translate all the libraries you depend on as well. :-P But you’re definitely right about pthreads; that would be a nightmare. Andy > On Jan 3, 2019, at 10:01 AM, Robert Engels wrote: > > I am pretty sure the other task is impossible, unless the generated code used

Re: [go-nuts] C++ 11 to Golang convertor

I am pretty sure the other task is impossible, unless the generated code used CGo for all of its work. It gets really difficult for multithreaded apps, pthread does not translate to Go routines, no TLS, etc. I think correcting the converted Go would be more daunting that just rewriting it in

Re: [go-nuts] C++ 11 to Golang convertor

I’ve been working on a tool (called leaven) to convert LLVM IR (intermediate representation) to Go. So you can compile C to LLVM with clang, and then convert the result to Go. It’s actually pretty easy, because LLVM instructions are such simple operations. But it’s not very readable; given this:

[go-nuts] Re: C++ 11 to Golang convertor

There are so, so many ways to go about porting functionality from one language to another. I hope you have seriously considered why you want to make such a port. The answer to that will likely, in part, drive your strategy. In addition the nature and size of the code base, and your timeline, wi

[go-nuts] Re: pprof labels usage details

I have built a quick demo that shows that the labels are `inherited` by the spawning goroutine for profiling. (I clearly hit the golang-nuts button too quickly for this question) https://play.golang.org/p/SbgtWB1fIKB Here we have a fairly pointless function which calculates Fibonacci a number

[go-nuts] Re: pprof labels usage details

Please note the original example won't run properly. `pprof.Labels()` takes an even number of strings, since it's setting key/value pairs. func handleFoo(ctx context.Context) { labels := pprof.Labels("foo", "foo") pprof.Do(ctx, labels, func(ctx context.Context) { go interestingFun

Re: [go-nuts] When to use panic?

On Thu, 3 Jan 2019 06:24:24 -0800 (PST) 伊藤和也 wrote: > When to use panic? When your code can NOT safely proceed. I.e. if some error state is not recoverable. You should NOT use panic in a library you write for others. Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You

Re: [go-nuts] When to use panic?

Typically explicit panics should only be used when an error occurs that callers are not expected to handle. For expected errors, functions should return an extra error return value, that callers can check. On Thu, Jan 3, 2019 at 8:24 AM 伊藤和也 wrote: > When to use panic? > > -- > You received this

[go-nuts] Re: Quirk with width of format string like %#05x

To keep backwards compatibility with go1 changing fmt to count in the 0x for the padding was discussed and abandoned in https://go-review.googlesource.com/c/go/+/22136/. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this g

[go-nuts] When to use panic?

When to use panic? -- 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/o

[go-nuts] pprof labels usage details

I would like to use pprof labels, but it seems like I would need to pass a `context.Context` into all new goroutines and re-call pprof.Do at each of these stages. Am I mistaken here. specifically if we had unc handleFoo(ctx context.Context) { pprof.Do(ctx, pprof.Labels("foo"), func(ctx con

Re: [go-nuts] Are deferred function calls stored in a stack?

Logically, they are stored in a last-in, first-out stack, yes. As Jan says, though, there might not be any actual stack data structure present at runtime. On Thu, 3 Jan 2019 at 10:43, 伊藤和也 wrote: > Are deferred function calls stored in a stack? > > -- > You received this message because you are

Re: [go-nuts] Are deferred function calls stored in a stack?

It's an implementation detail only. The compiler is free to select any mechanism satisfying the specification semantics. On Thu, Jan 3, 2019, 11:43 伊藤和也 wrote: > Are deferred function calls stored in a stack? > > -- > You received this message because you are subscribed to the Google Groups > "g

[go-nuts] Are deferred function calls stored in a stack?

Are deferred function calls stored in a stack? -- 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 h