[08:36:57 CST(-0600)] <Justin_o> Bosmon: i'm trying out the conditional panels on some of alex's code and noticing it is quite slow

[08:37:06 CST(-0600)] <Justin_o> Bosmon: any thoughts on how we might improve this

[08:37:39 CST(-0600)] <Justin_o> Bosmon: i'm guess it's all the over head of having to generate all the trees and etc. before hand

[08:44:41 CST(-0600)] <Justin_o> anastasiac: i wonder if we can remove this page again now.. http://wiki.fluidproject.org/display/docs/Demand+Resolution i've moved over the diagram and value resolution parts, although they aren't yet finished to http://wiki.fluidproject.org/display/docs/How+to+Use+Infusion+IoC.

[08:44:56 CST(-0600)] <Justin_o> anastasiac: and there are 6 incoming links to the demand resolution page still

[08:45:18 CST(-0600)] <anastasiac> Justin_o, that's probably a question for Bosmon. I had actually removed it, but he restored it. And if we remove it, we should clean up the incoming links first.

[09:03:57 CST(-0600)] <amilchev> Justin_o: are having telco today?

[09:04:02 CST(-0600)] <amilchev> are we*

[09:08:29 CST(-0600)] <amilchev> kasparnet, jessm, what's the link for the PCP/PMT meeting?

[09:12:59 CST(-0600)] <kasparnet> amilchev: access4all

[09:13:00 CST(-0600)] <kasparnet> oops that wasn't it

[09:13:12 CST(-0600)] <kasparnet> it's https://global.gotomeeting.com/join/619028605

[09:13:17 CST(-0600)] <amilchev> thanks!

[09:21:51 CST(-0600)] <jessm> we're up in gotomeeting having a UX chat

[09:21:58 CST(-0600)] <jessm> fluid-everyone: ^

[09:48:42 CST(-0600)] <cindyli> justin, do you want to take a look on my pull request for passing down grade names supplied in the aux schema? https://github.com/fluid-project/infusion/pull/438

[09:52:59 CST(-0600)] <cindyli> Justin_o: ^

[09:53:15 CST(-0600)] <Justin_o> cindyli: okay

[09:58:20 CST(-0600)] <Bosmon> Justin_o - have you tried running it in one or other of the profilers?

[09:58:51 CST(-0600)] <Bosmon> It's most likely you'll discover that the cost is actually lying in some unnecessary DOM manipulations, even with our slow framework, manipulating and instantiating those component trees shouldn't take much time

[09:59:17 CST(-0600)] <Bosmon> Especially given you discovered all those redundant ChangeAppliers, you'll most likely discover a storm of unnecessary model change events

[10:02:41 CST(-0600)] <Justin_o> Bosmon: haven't tried that yet.. i can take a look now.. i was going to look at cindy's latest pull request.. unless you'd prefer to do that..

[10:09:04 CST(-0600)] <anastasiac> Justin_o, I'm restructuring the instructional demo code for the conditional panels, and I'm rediscovering an issue with the template prefix

[10:09:50 CST(-0600)] <anastasiac> the template prefix is used for the templates I'm using in my panel, but the same prefix is also used to seek out the SepratedPanelPrefsEditorFrame.html; I'd rather just use the one that comes with the framework, but the same prefix location is used for both

[10:10:47 CST(-0600)] <anastasiac> the only way to tell the prefsEditor to use the framework version is with a blechy option to iframeRenderer

[10:11:50 CST(-0600)] <anastasiac> otherwise, I have to copy it into my templates folder and rewrite the paths in its headers

[10:15:43 CST(-0600)] <anastasiac> Justin_o, do you know if there's any other way to tell the prefsEditor to just use the framework's iframe template? or maybe cindyli knows? was anything put in for this?

[10:15:58 CST(-0600)] <Justin_o> anastasiac: i'd defer to cindyli but i don't know of way

[10:17:52 CST(-0600)] <cindyli> anastasiac: r u using aux schema for this?

[10:17:58 CST(-0600)] <anastasiac> yes, cindyli

[10:18:34 CST(-0600)] <cindyli> if one path is exceptional than others, you can specify the full path for that template url, anastasiac

[10:19:01 CST(-0600)] <cindyli> without using %prefix

[10:19:19 CST(-0600)] <anastasiac> yes, but the exceptional path is the one for the iframe template, cindyli; can I specify that in the schema? it's in the markupProps option to the iframerenderer...

[10:20:28 CST(-0600)] <Justin_o> anastasiac: is that in the auxSchema?

[10:20:35 CST(-0600)] <cindyli> which part is the iframe for? preview? anastasiac

[10:20:36 CST(-0600)] <Justin_o> if so you might be able to use the @ references

[10:20:49 CST(-0600)] <anastasiac> no preview

[10:52:22 CST(-0600)] <anastasiac> cindyli and Justin_o, I've filed an issue for that problem I found with the iFrame template: http://issues.fluidproject.org/browse/FLUID-5218

[10:53:23 CST(-0600)] <anastasiac> and I've added it to the iteration page

[11:29:07 CST(-0600)] <cindyli> hi Bosmon, just a reminder that the pull request for adding uiEnhancerConnections is ready. https://github.com/fluid-project/infusion/pull/425

[11:29:38 CST(-0600)] <Bosmon> thanks. cindyli

[11:29:54 CST(-0600)] <cindyli> thank you for reviewing it, Bosmon

[12:38:31 CST(-0600)] <anastasiac> cindyli, I see that FLUID-5190 has been fixed and merged (the textfieldSlider 'value' model path issue). Does this mean I can now use whatever model path I want for my sliders? Is there anything in particular I need to know?

[12:50:18 CST(-0600)] <cindyli> yes, anastasiac

[12:50:37 CST(-0600)] <cindyli> the new textfield slider makes use of model relay, let me find u an example

[12:51:22 CST(-0600)] <cindyli> https://github.com/cindyli/infusion/blob/master/src/framework/preferences/js/Panels.js#L479-L490

[12:53:30 CST(-0600)] <anastasiac> thanks, cindyli

[12:53:37 CST(-0600)] <cindyli> anastasiac: Justin_o recently found an timing issue with having textfieldSlider rendered as a decorator on the protoTree when the panel is a subpanel of a composite panel. the safer way is to make textfieldSlider a subcomponent

[12:53:59 CST(-0600)] <anastasiac> right: no decorators in composite panels

[12:54:05 CST(-0600)] <Justin_o> anastasiac: yes.. decorators are not allowed

[12:54:07 CST(-0600)] <cindyli> anastasiac: example again - https://github.com/cindyli/prefsEditors/blob/GPII-153_GPII-187/src/shared/adjusters/js/speakTextPanels.js#L32-L69

[12:54:09 CST(-0600)] <anastasiac> hm

[12:54:12 CST(-0600)] <anastasiac> but it works for me

[12:54:25 CST(-0600)] <Justin_o> anastasiac: it can work, but if you need to share things from the parent like an applier it won't

[12:55:13 CST(-0600)] <anastasiac> what would the use case for having to share the applier from the parent, Justin_o?

[12:55:53 CST(-0600)] <cindyli> anastasiac: to pass down sourceApplier for model relay

[12:56:13 CST(-0600)] <anastasiac> but when would I need to do that? I'm not doing it now, and everything works fine...

[12:56:46 CST(-0600)] <cindyli> anastasiac: depends on ur use case i think.

[12:57:22 CST(-0600)] <anastasiac> hm. well, I'd love to understand a use case that would require me to pass down the sourceApplier

[12:57:54 CST(-0600)] <cindyli> well, anastasiac, the 2nd example is the use case you need: https://github.com/cindyli/prefsEditors/blob/GPII-153_GPII-187/src/shared/adjusters/js/speakTextPanels.js#L32-L69

[13:37:11 CST(-0600)] <Justin_o> Bosmon: michelled and i found the main culprit.. i had been calling the creation event too many times because it was accidentally placed inside of a loop instead of out.

[13:37:29 CST(-0600)] <Bosmon> cool

[13:37:36 CST(-0600)] <Bosmon> How many duplicates are you down to now

[13:37:50 CST(-0600)] <Justin_o> Bosmon: the components do still need to be created twice to 1) get the produce tree 2) recreate after rendering to re-establish any dom bindings

[13:38:03 CST(-0600)] <Justin_o> just the 2 that we could see

[13:38:43 CST(-0600)] <Justin_o> Bosmon: by the way, i've fixed this in my FLUID-5205 branch

[13:40:29 CST(-0600)] <Bosmon> Justin_o - thanks

[13:40:43 CST(-0600)] <Bosmon> If the performance is still poor, it may be worth making a new lifecycle for the components whereby their DOM binder can be recreated

[13:41:00 CST(-0600)] <Bosmon> Since a 100% speedup still shouldn't be sneezeed at

[13:41:38 CST(-0600)] <Justin_o> Bosmon: interesting... what would happen to this-ist invokers those

[13:42:00 CST(-0600)] <Bosmon> Those could be turned into "slow invokers"

[13:42:04 CST(-0600)] <Bosmon> That is, with dynamic: true

[13:42:13 CST(-0600)] <Bosmon> Shifting some of the cost from render time to runtime

[13:42:21 CST(-0600)] <Justin_o> Bosmon: okay.. what about this-ist listeners that do things onCreate?

[13:42:48 CST(-0600)] <Bosmon> Justin_o - those could be moved to listen to a new event, say "onDomBind"

[13:43:27 CST(-0600)] <Justin_o> Bosmon: I guess the thing i'd be worried about is that these panels should be usable in and out of a composite panel

[13:43:38 CST(-0600)] <Justin_o> so as a top level or subpanel

[13:43:55 CST(-0600)] <Bosmon> Justin_o - yes

[13:44:01 CST(-0600)] <Bosmon> This could be mediated by a suitable "mixin grade"

[13:44:20 CST(-0600)] <Bosmon> By default, there would be a single listener to onCreate which just fires onDomBind

[13:44:31 CST(-0600)] <Bosmon> And when they are in the context of the composite panel, this listener would be removed

[13:45:09 CST(-0600)] <Justin_o> Bosmon: interesting

[13:45:42 CST(-0600)] <Justin_o> that might work.. it is a bit of an extra burden on the implementor to keep these things all straight

[13:45:52 CST(-0600)] <Bosmon> Well, it should be no burden on them

[13:45:59 CST(-0600)] <Bosmon> Just on the poor sap who wrote the aux builder

[13:46:26 CST(-0600)] <Justin_o> haha

[13:46:52 CST(-0600)] <Justin_o> Bosmon: but i mean the implementor would have to write the listener against onDomBind instead of onCreate

[13:47:03 CST(-0600)] <Bosmon> Justin_o - yes

[13:47:08 CST(-0600)] <Bosmon> But they would be instructed to do this

[13:47:12 CST(-0600)] <Bosmon> By our documentation

[13:47:39 CST(-0600)] <Justin_o> Bosmon: right, but it would be added cognitive burden for them.. although the performance improvement may be worth it

[13:47:48 CST(-0600)] <Justin_o> anastasiac: do you have an opinion on this?

[13:47:58 CST(-0600)] <Bosmon> I don't think it would be much extra burden... in fact it might well simplify things

[13:48:05 CST(-0600)] <Bosmon> We register far too many things on "onCreate"

[13:48:09 CST(-0600)] <anastasiac> Justin_o, how far back should I start reading?

[13:48:13 CST(-0600)] <Bosmon> And this lifecycle point will be an important one in the "new renderer"

[13:48:19 CST(-0600)] <Bosmon> So we had better start getting used to it

[13:48:36 CST(-0600)] <Justin_o> anastasiac: from about 2:41

[13:48:49 CST(-0600)] <Justin_o> Bosmon: oh so it will be a real thing..

[13:49:32 CST(-0600)] <Bosmon> We're certainly not going to have renderer components in the new world that are obliged to destroy and recreate themselves when they render something : P

[13:49:48 CST(-0600)] <Justin_o>

[13:49:55 CST(-0600)] <Justin_o> Bosmon: thankfully

[13:50:13 CST(-0600)] <Justin_o> Bosmon: okay.. i'm going to file this under a new jira though.. i don't think it should hold up FLUID-5205

[13:50:18 CST(-0600)] <Bosmon> ok

[13:50:19 CST(-0600)] <Justin_o> does that make sense to you?

[13:50:25 CST(-0600)] <Bosmon> How is the performance now?

[13:50:30 CST(-0600)] <anastasiac> it sounds from the discussion that this onDomBind will be a formal framework lifecycle point, and I don't think it would be too unreasonable to expect developers to learn the difference between it and onCreate, and to understand when to use one or the other

[13:50:49 CST(-0600)] <anastasiac> if I'm understanding correctly

[13:50:55 CST(-0600)] <Justin_o> anastasiac: i think for the moment though it will only apply to panels

[13:51:04 CST(-0600)] <Bosmon> Very few things will go on "onCreate" in the future

[13:51:08 CST(-0600)] <anastasiac> ok, so part of the prefs framework

[13:51:30 CST(-0600)] <anastasiac> but still, it seems ok to me, from the integrator/documentation perspective

[13:52:15 CST(-0600)] <Justin_o> anastasiac: thanks

[13:52:48 CST(-0600)] <Justin_o> Bosmon: i would say definitely feels like less than a second if FF with firebug open.. i can put things back and get you some real numbers if you like

[13:53:21 CST(-0600)] <Bosmon> "definitely less than a second" is still far from great : P

[13:53:27 CST(-0600)] <Bosmon> Although firebug does make a huge difference

[13:53:53 CST(-0600)] <anastasiac> FYI, Justin_o and Bosmon, I have a FLUID-5205 branch now that has the conditional adjuster instructional demos in place more formally. It's not quite ready for a pull request - there are some styling issues - but it's close, in case you want to merge it in for testing, Justin_o

[13:54:24 CST(-0600)] <anastasiac> Justin_o, it's based on your latest FLUID-5205 branch

[13:54:38 CST(-0600)] <Justin_o> anastasiac: did you just do an update, because i just made a change

[13:55:01 CST(-0600)] <anastasiac> ok, no, not that recently

[13:55:04 CST(-0600)] <anastasiac> in progress

[13:55:08 CST(-0600)] <Justin_o> thanks

[13:55:55 CST(-0600)] <anastasiac> ok, Justin_o, merged and pushed

[13:56:49 CST(-0600)] <Justin_o> anastasiac: thanks

[13:56:54 CST(-0600)] <Justin_o> i guess i should merge yours into mine

[13:57:20 CST(-0600)] <Justin_o> Bosmon: so before it took 1.841s now it takes 0.699s

[13:58:01 CST(-0600)] <Bosmon> Not as much of an improvement as expected

[13:58:16 CST(-0600)] <Justin_o>

[13:58:42 CST(-0600)] <Bosmon> But implementing "onDOMBind" should definitely get it below 0.5s at least

[13:58:50 CST(-0600)] <Bosmon> Which is probably an important barrier

[13:59:35 CST(-0600)] <Bosmon> You can do that in a new branch as you say

[13:59:53 CST(-0600)] <Bosmon> Once we get anastasiac's stuff merged into this current one we should be good to go

[13:59:58 CST(-0600)] <Justin_o> Bosmon: thanks.. i'll file a new jira for that

[14:00:11 CST(-0600)] <Bosmon> Btw anastasiac - when you prepare your branch, could you also prepare a page describing "acceptance tests"?

[14:00:24 CST(-0600)] <Bosmon> That is, for each one of your instructional demos, what the user should expect to see when they operate the component

[14:00:55 CST(-0600)] <Justin_o> Bosmon: anastasiac's code is merged into my FLUID-5205 branch.. it should be up in the pull request now

[14:01:07 CST(-0600)] <anastasiac> Bosmon, I can add that in a readme in the folder - is that what you're thinking of? Or perhaps in the HTML page of the demo, so that when they run it they see it?

[14:01:45 CST(-0600)] <Bosmon> In the demo page would be even better, yes

[14:02:02 CST(-0600)] <Bosmon> It would be useful to the "instructees" to know what they should expect the component to do

[14:02:06 CST(-0600)] <Bosmon> Just as to "testers"

[14:02:58 CST(-0600)] <anastasiac> will do

[14:03:12 CST(-0600)] <Bosmon> thanks, anastasiac!

[14:03:33 CST(-0600)] <anastasiac> FYI, Bosmon and Justin_o, the instructional demos that are now in Justin_o's 5205 branch aren't styled very well, I'm still working on that

[14:12:50 CST(-0600)] <cindyli> Bosmon: wonder if you have time to look at one of my another pull request - https://github.com/fluid-project/infusion/pull/438

[14:27:24 CST(-0600)] <Justin_o> Bosmon: filed a new jira for the performance upgrades http://issues.fluidproject.org/browse/FLUID-5220

[18:20:57 CST(-0600)] <cindyli> hi Bosmon

[18:21:17 CST(-0600)] <Bosmon> Hey cindyli

[18:21:24 CST(-0600)] <Bosmon> At home now?

[18:21:28 CST(-0600)] <cindyli> i'm lucky

[18:21:31 CST(-0600)] <cindyli> ya at home

[18:21:37 CST(-0600)] <cindyli> a question about fluid.merge

[18:22:25 CST(-0600)] <cindyli> a test case: http://pastie.org/8499755

[18:23:29 CST(-0600)] <cindyli> Bosmon: rather than getting "expected", what i get is

[18:23:31 CST(-0600)] <cindyli> {

[18:23:31 CST(-0600)] <cindyli> "options": {

[18:23:31 CST(-0600)] <cindyli> "path": "undefined source1 source2"

[18:23:31 CST(-0600)] <cindyli> }

[18:23:31 CST(-0600)] <cindyli> }

[18:24:00 CST(-0600)] <Bosmon> cindyli - a lot depends on what is in fluid.tests.merge

[18:24:25 CST(-0600)] <cindyli> right, missed pasting that. one sec

[18:25:17 CST(-0600)] <cindyli> Bosmon: http://pastie.org/8499762

[18:26:07 CST(-0600)] <Bosmon> cindyli - you can always expect to be called with any number of instances of "undefined" with the current framework

[18:26:19 CST(-0600)] <Bosmon> You will just have to filter out "falsy" values yourself

[18:26:45 CST(-0600)] <cindyli> meaning, filter out "undefined" in fluid.tests.merge?

[18:27:08 CST(-0600)] <Bosmon> Yes, if either target or source is falsy, you should just return the other one

[18:27:43 CST(-0600)] <Bosmon> But why do you want this space-separated string in the first place?

[18:27:52 CST(-0600)] <cindyli> so, if i'm using fluid.arrayConcatPolicy, which is provided by framework, i will need to create a wrapper function to filter out falsy ones?

[18:28:16 CST(-0600)] <Bosmon> arrayConcatPolicy will already ignore undefined values since they get converted to [] by fluid.makeArray

[18:29:44 CST(-0600)] <cindyli> of course, u r right. modified my unit test and it's proved. thanks, Bosmon

[18:30:00 CST(-0600)] <Bosmon> It is one of its main improvements

[18:30:09 CST(-0600)] <Bosmon> Compared to the idiotic $.makeArray which just crashes : p

[18:32:36 CST(-0600)] <cindyli> ah ha. certainly an useful improvement

[19:03:29 CST(-0600)] <cindyli1> Bosmon: your comments on pull request https://github.com/fluid-project/infusion/pull/438 have been addressed. ready for more. thanks.

[19:07:25 CST(-0600)] <Bosmon> Thanks, cindyli1

[19:07:27 CST(-0600)] <Bosmon> The code itself looks good

[19:07:33 CST(-0600)] <cindyli1> yay!

[19:07:41 CST(-0600)] <Bosmon> but there is a bit of a gap between the description in the JIRA and the work which was done

[19:07:47 CST(-0600)] <Bosmon> Do you think you could improve the description a bit?

[19:07:59 CST(-0600)] <Bosmon> In particular, to describe the need for the "validationFunc" etc.

[19:08:09 CST(-0600)] <Bosmon> Since these seem well outside the scope of FLUID-5213 itself

[19:08:45 CST(-0600)] <cindyli1> sure. in action

[19:14:59 CST(-0600)] <Bosmon> Was there a call or a piratepad where this functionality was designed?

[19:15:04 CST(-0600)] <Bosmon> Or an email thread?

[19:40:26 CST(-0600)] <cindyli1> sorry, Bosmon, just saw ur msg. no, nothing in doc to decide on this design. all from my imagination. hope it's not a overkill

[19:40:55 CST(-0600)] <cindyli1> btw, the jira description has been modified. feel free to make changes

Browser not supported