Re: [go-nuts] Algorithm Club

This is just what I dream of. (Well, not dream really as I do it already with a macro processor, but I dream of it being integrated and robust.) On Sat, Mar 25, 2017 at 8:30 PM Will Faught wrote: > Generics is polymorphism, though; actually, it's a kind of polymorphism >

Re: [go-nuts] Algorithm Club

Generics is polymorphism, though; actually, it's a kind of polymorphism called parametric polymorphism. It's program behavior that doesn't depend on the types of the data it uses. It's useful for algorithms for types that contain variable types. There are numerous slice, map, and chan utility

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

You may also run into subtle races when you mix pointer and value receivers, as seen here: https://dave.cheney.net/2015/11/18/wednesday-pop-quiz-spot-the-race On Friday, March 24, 2017 at 6:20:06 PM UTC-7, st ov wrote: > > Is it idiomatic to mix-&-match pointer and value method receivers for a

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

A ANSI-C (probably with GNU extension if helpful) transpiler/backend would be much more useful than a C++ one. C is far more widespread and easier to integrate. C *and* C++ projects can both integrate C source. But C projects cannot integrate C++ source. The users who want to build the gc

Re: [go-nuts] Re: Algorithm Club

The simplest design I can think of (that does what you seem to want) is to add parameterized packages. Here's a stereotypical example: package stack(T)// parameterized on stack element type import "fmt" type Type struct { rep []T func New() *Type { {} } func (stk *Type)Push(t

Re: [go-nuts] Re: Algorithm Club

Hmmn, we may be thinking different things... I *think* I'm looking for a way to say "an X of Y", and see composition as a possible approach. I just don't know if it will be a, the, or not the answer (;-)) --dave On 24/03/17 11:21 PM, Michael Jones wrote: I think I was saying that what I seem

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

> it might considerably lower the bar for adopting Go I think Go as a language and the tooling make the bar quite low already. With a small time investment it becomes a very productive language for most developers. Choosing a project which makes sense to completely write in Go, and sharing

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

I think it's a fine idea. For a decade C++ was actually compiled to C, via cfront. It well past time that Go returns the favour. This would also help flush out a lot of unspoken assumptions about what a Go program requires from the underlying operating system. -- You received this message

[go-nuts] Re: Assembly jump instruction operands

https://github.com/golang/go/issues/19718 On Saturday, March 25, 2017 at 4:42:31 PM UTC-7, Keith Randall wrote: > > I think you're talking about conditional branches > > 0x008c 00140 (s.go:7) JLT $0, 55 > > There is sometimes an optional constant $0 or $1 in addition to the > destination. $0

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

My thought was that the translation would be one-way - you would avoid hacking on the C++ part unless you were completely abandoning the Go part. I see the point on the disparity between what it would take to migrate a project to Go vs the effort to build such a project. Although part of my

Re: [go-nuts] template Funcs with ParseFile and Execute

Please check the error on the line that calls template.New. I believe it's reporting failure. -rob On Sat, Mar 25, 2017 at 9:56 AM, priyank pulumati < pulumati.priy...@gmail.com> wrote: > Sry for little info, template.Base is a constant ("templates/base.html", a > path) and the same for

Re: [go-nuts] template Funcs with ParseFile and Execute

Sry for little info, template.Base is a constant ("templates/base.html", a path) and the same for templateName passed from my controller. But what do i pass in template.New() ? On Saturday, March 25, 2017 at 10:17:23 PM UTC+5:30, Yves Junqueira wrote: > > Your ParseFiles call has a

Re: [go-nuts] template Funcs with ParseFile and Execute

Sry for little information, templateName is passed from my controllers with a constant (like "templates/home.html"), so there is no problem with that. In template.new(), what do i pass ? On Saturday, March 25, 2017 at 10:17:23 PM UTC+5:30, Yves Junqueira wrote: > > Your ParseFiles call has a

Re: [go-nuts] template Funcs with ParseFile and Execute

Your ParseFiles call has a "templateName" argument in it. The ParseFiles function only takes file paths, not template names. And templates.New takes a template name, not a file path. Hope this helps. On Sat, Mar 25, 2017 at 9:14 AM, priyank pulumati < pulumati.priy...@gmail.com> wrote: >

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

That is a worry, but escape analysis can handle this case. It understands flow of pointers through unsafe.Pointer and uintptr. As a consequence, in this example it forces the array to be allocated on the heap. The runtime has on occasion a need to hide values from escape analysis. It has to

[go-nuts] Re: template Funcs with ParseFile and Execute

Error when i say template.New(templates.BASE) template: templates/base.html: "templates/base.html" is an incomplete or empty template -- 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

[go-nuts] template Funcs with ParseFile and Execute

hello, im building a go web app and facing an issue with Executing templates with custom functions func CustomTemplateExecute(res http.ResponseWriter, req *http.Request, templateName string, data map[string]interface{}) { // Append common templates and data structs and execute template var

[go-nuts] Re: LLDB only works for project contains one go source file

hi, I have meet the same question, did you solved it ? 在 2016年10月26日星期三 UTC+8下午7:20:01，Leopold Freeman写道： > > Hi: > I upgraded my MBP to macOS Sierra, and gdb was broke because Apple > tightened security policy. So I compiled LLDB from trunk according to here >

[go-nuts] problem about lldb debug go code

down votefavorite if code and binary program is not in the same directory, use gdb and lldb to debug golang program, it will only show assembly code, not go code, with gdb, we can add add-auto-load-safe-path

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

On Sat, 25 Mar 2017 03:49:55 -0700 (PDT) andrewchambe...@gmail.com wrote: > Its a bad idea for many reasons. > > - The actual implementation is harder than convincing someone to just > use the official Go compiler. > - Some features don't map cleanly to C++ > - C++ programmers won't like it, and

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

Its a bad idea for many reasons. - The actual implementation is harder than convincing someone to just use the official Go compiler. - Some features don't map cleanly to C++ - C++ programmers won't like it, and neither will go programmers. - Nobody will fund the maintenance of this compiler and

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

On Saturday, March 25, 2017 at 9:20:06 AM UTC+8, 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