<div dir="ltr"><div>Indeed, that's what I'm thinking of and it is quite unlikely.<br><br></div>Dustin<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 4, 2015 at 10:28 AM, Роман Донченко <span dir="ltr"><<a href="mailto:dpb@corrigendum.ru" target="_blank">dpb@corrigendum.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Alright, I'll start working on the merge request, then.<br>
<br>
I don't see how a cycle is possible here, BTW. (Unless you mess with a Transform object after it's been created, which is definitely user error.)<br>
<br>
Dustin J. Mitchell <<a href="mailto:dustin@v.igoro.us" target="_blank">dustin@v.igoro.us</a>> писал в своём письме Sun, 04 Oct 2015 17:23:40 +0300:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ah, I see that the distinction is deeper than just allowing asynchronous<br>
returns -- Transform works on other renderables, whereas renderer creates<br>
new renderables (which take the build `b` as an argument).<br>
<br>
I like that this allows multiple renderables as input - nice design!<br>
<br>
There's a risk of circular dependencies, but I think we can consider that<br>
"user error" and not do anything to try to prevent it (cycle detection<br>
would be pretty hard here!).<br>
<br>
So yes, I think this would be a good addition to the property support.<br>
<br>
Dustin<br>
<br>
On Sun, Oct 4, 2015 at 10:12 AM, Роман Донченко <<a href="mailto:dpb@corrigendum.ru" target="_blank">dpb@corrigendum.ru</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't see how that would work.<br>
<br>
IMO, renderer and Transform are very different things. The former creates<br>
a new renderable based on a user-defined function; the latter combines<br>
existing renderables based on a user-defined transformation. They can't<br>
(and shouldn't) be implemented by the same function.<br>
<br>
Dustin J. Mitchell <<a href="mailto:dustin@v.igoro.us" target="_blank">dustin@v.igoro.us</a>> писал в своём письме Sun, 04 Oct<br>
2015 16:55:46 +0300:<br>
<br>
<br>
Could you possibly extend renderer to handle that case?<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Dustin<br>
<br>
On Fri, Oct 2, 2015 at 4:17 PM, Роман Донченко <<a href="mailto:dpb@corrigendum.ru" target="_blank">dpb@corrigendum.ru</a>><br>
wrote:<br>
<br>
Pierre Tardy <<a href="mailto:tardyp@gmail.com" target="_blank">tardyp@gmail.com</a>> писал в своём письме Fri, 02 Oct 2015<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
00:25:36 +0300:<br>
<br>
Hi Roman,<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There is already a renderer function which is similar simplification of<br>
the<br>
renderable pattern.<br>
You can do<br>
<br>
renderer(lambda _: datetime.date.today().isoformat()<br>
renderer(lambda b: os.path.relpath(p.getProperty('buildir'))<br>
<br>
The latter is a little bit more chars than your solution, but probably<br>
more<br>
easy to follow.<br>
<br>
<br>
</blockquote>
I know this, but it doesn't work when the arguments are arbitrary<br>
renderables (since you have to account for the possibility that they<br>
return<br>
a Deferred). The brevity is nice to have, too.<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@buildbot.net" target="_blank">devel@buildbot.net</a><br>
<a href="https://lists.buildbot.net/mailman/listinfo/devel" rel="noreferrer" target="_blank">https://lists.buildbot.net/mailman/listinfo/devel</a><br>
<br>
</blockquote></blockquote></blockquote></blockquote>
</blockquote></div><br></div>