Do you have any references on the stability of the current plugin system
that I can use for reference? I'm building a system now that I contemplate
using with some plugins and I'd like to know up front the challenges.
On Friday, June 2, 2017 at 7:39:40 PM UTC-5, Ian Lance Taylor wrote:
>
> On Fr
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:
> > Here's a proof-of-co
I see previous threads with a solution to eliminating trailing commas for
text/template output when ranging over an array. (ie. the {{if
$index}},{{end}} trick)
I have the exact same problem when ranging over a map and it doesn't appear
that the array fix will work.
any thoughts?
--
Michael
I posted on another thread today one solution for this (Subj: "How to
parallelize text/template long-running functions")
I got something simple working using a two-pass template execution, and
somebody else pointed me
to https://blog.gopheracademy.com/advent-2014/soy-programmable-templates/
(w
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"
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 h
34:56 UTC+3, Michael Brown wrote:
>>
>> 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 res
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 latency, who gets the output,
> where do the templates come from...
>
gt;
> os.Stdout.Write(q.Patch(buf.Bytes))
>
> }
>
> The other approach would be to do multiple passes:
>
> 1. execute template
> 2. collect funcs that haven't been run yet
> 2.1. no funcs left --> output
> 3. execute these funcs, cache the func values
> 4
brary-googl>
> and
> isolate the precompute code to be near there, to make maintenance easier.
>
> Best,
> Tom
>
>
> On Wed, May 31, 2017 at 1:28 AM, Michael Brown > wrote:
>
>> I am designing a system that will heavily use text/template processing
>> and I'
This is interesting. I spent a lot of time on google trying to figure out
the answer to the exact same problem before posting basically the exact
same query last night (Still waiting for moderator approval).
I would be very interested if anybody can explain a technique to run all of
the calls i
I am designing a system that will heavily use text/template processing and
I've run into one issue that is going to be a show stopper for me if I
can't figure out a way around it.
Execute() on a template will run all of the functions in the template
serially.
For example, when you run the cod
My problem is that I have a very large data set that is very expensive
(memory/compute) to get, and only the template knows which data it needs to
use. Computing the data in go before template processing would waste a
whole lot of time/memory that I dont have.
On Tuesday, May 30, 2017 at 5:04:5
13 matches
Mail list logo
