I was puzzled by something you said earlier:
> The template is the only entity that knows exactly which data from the
data set is needed.
You've just given a bit more information, but I still don't quite
understand.
You have some C code that you don't control and it's producing some
Your solution is certainly nice. It has the same limitation that mine does.
I'll take a look, I like how you don't have to modify the funcmap in yours.
--
Michael
On Friday, June 2, 2017 at 4:41:14 AM UTC-5, rog wrote:
>
> On 2 June 2017 at 10:35, roger peppe
> wrote:
> >
On 2 June 2017 at 10:35, roger peppe wrote:
> Here's a proof-of-concept of a somewhat general mechanism
> for making template functions concurrent. It involves some
> fun reflection code (first time I've used FuncOf, MakeFunc,
> StructOf and MapOf for real).
>
>
Here's a proof-of-concept of a somewhat general mechanism
for making template functions concurrent. It involves some
fun reflection code (first time I've used FuncOf, MakeFunc,
StructOf and MapOf for real).
https://play.golang.org/p/7qXx5pCh9N
On 1 June 2017 at 07:02, Michael Brown
Great! If I had checked this thread when you posted this I (probably) could
have saved myself 3 hours of work.
I got it working with a two-pass scheme using text/template and some
channels.
Here is what I came up with:
package main
import (
"text/template"
"bytes"
"context"
We do this exact thing except using closure templates
https://blog.gopheracademy.com/advent-2014/soy-programmable-templates/
--
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
And after I re-read your answer, I realize that I probably just restated
very badly what you wrote, Egon. Thanks! I'll have some time this evening
to hack on it.
On Wednesday, May 31, 2017 at 2:51:51 PM UTC-5, Michael Brown wrote:
>
> Ah! I think I have the kernel of a usable idea here. Thanks.
Ah! I think I have the kernel of a usable idea here. Thanks.
How does this sound: template 1 outputs template 2. Input to template 1
kicks off the goroutines and places {{ get_results token_xyz }} as the
output, but also has an output channel that we can wait on for all of the
answers Then,
This is almost certainly going to be a case where you have the correct
solution and I don't have the go experience to properly understand it. I
wasn't quite understanding how your code was "patching" the results and how
the template package knows to wait for it. Let me describe my problem.
I
Both of my described approaches run the funcs serially however it does not
wait for the response and later patxhes the results.
Can you describe the whole thing you are building? Piecing the requirements
and purpose together from comments is difficult.
I.e. how much memory, how big is request
The best thing I can think of is to modify text/template to add futures
support, and then do multi-pass rendering. The place to add this looks
relatively simple, however the implementation looks complicated (and I just
wrote my first program in go a couple weeks ago...)
The problem that I see
The best idea I can think of (without digging and modifying text/template)
is to use special tokens and replace them afterwards...
Of course this approach has limitations in what it can do.
*// note: code untested and incomplete*
type Token string
type Queries struct {
pending
12 matches
Mail list logo