fluid-work IRC Logs-2013-11-19

[08:04:10 CST(-0600)] <Justin_o> cindyli: i filed this one for the issue i found yesterday http://issues.fluidproject.org/browse/FLUID-5213

[08:05:02 CST(-0600)] <cindyli> thanks, Justin_o, i will take a look later

[08:05:26 CST(-0600)] <Justin_o> cindyli: Thanks

[08:26:36 CST(-0600)] <Justin_o> Bosmon: i have a grade merging question for you

[08:27:54 CST(-0600)] <Justin_o> Bosmon: when we try to add gradeNames through the auxiliary schema it causes an error that says the sourceApplier for the subpanels are null... the grade in the auxiliary schema is added to the subpanel. The strange part though is that the sub panel has a merge policy of "no merge" for the sourceApplier

[08:29:10 CST(-0600)] <Justin_o> the gradeName from the auxiliary schema is being added to the first position of the grade names.. if i add this same grade to the sub panel component directly things work and the grade is in a different position in the gradeNames

[08:37:47 CST(-0600)] <Bosmon> Justin_o - can you be more specific about the situation?

[08:38:03 CST(-0600)] <Bosmon> At what point does it say that the sourceApplier is null, and which part of the grade implementation is interested in this?

[08:42:07 CST(-0600)] <Justin_o> Bosmon: it's in a call to fluid.addSourceGuardedListener probably as the modelRelay

[08:49:06 CST(-0600)] <Bosmon> Justin_o - so the call occurs somehow as part of the grade resolution process?

[08:49:16 CST(-0600)] <Bosmon> Can you tell exactly what causes it to execute?

[09:07:42 CST(-0600)] <Justin_o> Bosmon: not really sure what you mean, but the modelRelay automatically makes those calls to fluid.addSourceGuardedListener on create

[09:07:59 CST(-0600)] <Bosmon> Ok

[09:08:04 CST(-0600)] <Bosmon> So it is during "onCreate"?

[09:08:25 CST(-0600)] <Justin_o> Bosmon: yes.. this happens as the components are trying to initialize

[09:08:43 CST(-0600)] <Bosmon> Justin_o - ok, so the grade merging process has already finished by this point

[09:08:54 CST(-0600)] <Bosmon> Which implies that it is not an order of evaluation issue

[09:09:11 CST(-0600)] <Justin_o> Bosmon: yes.. but the grade merging seems to be removing the sourceApplier option

[09:09:59 CST(-0600)] <Bosmon> Justin_o - do you have a sourceApplier: null option written in any of the grades, by any chance?

[09:10:13 CST(-0600)] <Justin_o> i don't think so, but i'll take a look

[09:11:13 CST(-0600)] <Justin_o> Bosmon: there is in the base grade of modelRelay

[09:11:26 CST(-0600)] <Bosmon> Justin_o - seems dodgy

[09:11:33 CST(-0600)] <Bosmon> I would get rid of it : P

[09:12:47 CST(-0600)] <Justin_o> Bosmon: hmm.. seems to have done the trick.. so it only matters because of the order of the gradeNames?

[09:13:08 CST(-0600)] <Justin_o> Bosmon: also how would we then represent it in the base grade?

[09:13:23 CST(-0600)] <Bosmon> Justin_o - yes, since FLUID-5085, grade order is crucial in merging

[09:13:32 CST(-0600)] <Bosmon> Justin_o - there is no need to represent it in the base grade, since it has no useful default value

[09:14:04 CST(-0600)] <Justin_o> Bosmon: so we should just leave a comment about it?

[09:14:12 CST(-0600)] <Bosmon> Justin_o - yes

[09:14:20 CST(-0600)] <Justin_o> Bosmon: okay

[09:14:33 CST(-0600)] <Justin_o> Bosmon: can i set it to undefined.. it seems to work

[09:14:45 CST(-0600)] <Bosmon> Although it's worth trying to understand why you got an extra copy of the modelRelay grade inserted into the grade hierarchy

[09:14:50 CST(-0600)] <Bosmon> Justin_o - I wouldn't rely on that

[09:15:00 CST(-0600)] <Bosmon> There is a fix to that "bug" in my ChangeApplier branch : P

[09:15:23 CST(-0600)] <Justin_o> oh okay

[09:15:48 CST(-0600)] <Justin_o> Bosmon: hmm.. that is a good question about where the extra model relay comes from.

[09:16:26 CST(-0600)] <Justin_o> Bosmon: ah the grade i'm adding is also of type fluid.prefs.panel which has a modelRelay in it

[09:16:34 CST(-0600)] <Justin_o> as a base grade that is

[09:17:07 CST(-0600)] <Justin_o> i suppose this could have just been a little component since i'm only using it to add on configuration

[09:17:09 CST(-0600)] <Justin_o> Bosmon: ^

[09:17:12 CST(-0600)] <Bosmon> Justin_o - yes

[09:17:24 CST(-0600)] <Bosmon> It's useful to remove "unnecessary" grades from a hierarchy

[09:17:37 CST(-0600)] <Bosmon> I had to make a change like this in UIO when I implemented FLUID-5085 in the first place

[09:17:54 CST(-0600)] <Bosmon> Congrats on yesterday's Rob Ford vote btw

[09:18:09 CST(-0600)] <Justin_o> Bosmon: okay.. i had though we were supposed to use a similar grade to what it would be applied to, like what we did for the starterGrades.. or maybe this is what you changed

[09:19:22 CST(-0600)] <Justin_o> Bosmon: yes.. now we have a leader with less power than his subordinate. This whole situation is making us look so bad though is it big news over there too?

[09:19:58 CST(-0600)] <Bosmon> Justin_o - certainly it's top headlines in almost every news outlet.... only the Obamacare rollout and the typhoon rank higher : P

[09:20:52 CST(-0600)] <colinclark> I've received several jokes about it here in Madrid

[09:20:55 CST(-0600)] <colinclark> what a bummer

[09:21:11 CST(-0600)] <Justin_o> colinclark: i hope they were at least funny

[09:21:25 CST(-0600)] <Justin_o> colinclark, Bosmon: did you guys see the SNL skit?

[09:22:01 CST(-0600)] <colinclark> I haven't yet, no

[09:22:12 CST(-0600)] <colinclark> The Fox News interview with Ford himself was funny enough

[09:22:36 CST(-0600)] <Justin_o> colinclark: are you planning on voting for him to be prime minister?

[09:22:52 CST(-0600)] <colinclark>

[09:23:02 CST(-0600)] <colinclark> I think I will pass on that one

[09:24:43 CST(-0600)] <Justin_o> I'm still hoping that one day there'll be a -1 option for election ballots

[09:31:55 CST(-0600)] <colinclark> hey yzen

[09:32:08 CST(-0600)] <yzen> colinclark: hi

[09:32:18 CST(-0600)] <colinclark> Tony Atkins is sitting beside me

[09:32:27 CST(-0600)] <colinclark> he was asking if there are any super-simple examples of Kettle apps

[09:32:33 CST(-0600)] <colinclark> I told him I thought we just weren't there yet

[09:32:47 CST(-0600)] <colinclark> but I thought I should check with our Kettle Master just in case something occurred to you

[09:32:55 CST(-0600)] <colinclark> as a good place to just sort of check out how it should be used

[09:33:03 CST(-0600)] <colinclark> without being as complex as, say, the Flow Manager

[09:33:29 CST(-0600)] <Justin_o> Bosmon: when you get a chance can you also review this one https://github.com/fluid-project/infusion/pull/425

[09:33:46 CST(-0600)] <Justin_o> i think it's just awaiting another round of code review from you

[09:34:16 CST(-0600)] <yzen> colinclark: i think you can point him to other apps we have in universal , such as device reporter , it's pretty simple

[09:34:47 CST(-0600)] <yzen> colinclark: also my GPII-75 branch of kettle has quite a bit of test configs that might be useful too

[09:36:20 CST(-0600)] <Bosmon> cindyli - can you say what you would write without the "fluid.tests.uiEnhancer" component?

[09:36:35 CST(-0600)] <Bosmon> I'm not quite clear on how an IoCSS selector would substitute for this

[09:49:59 CST(-0600)] <cindyli> Bosmon: i guess you are referring to https://github.com/fluid-project/infusion/pull/425 for the "fluid.tests.uiEnhancer" component

[09:50:35 CST(-0600)] <Bosmon> cindyli - yes

[09:55:50 CST(-0600)] <cindyli> Bosmon: "fluid.tests.uiEnhancer" is in place because "fluid.prefs.uiEnhancerConnections" is added as a base grade of fluid.prefs.enactor as a work around for http://issues.fluidproject.org/browse/FLUID-5193. This introduces the dependency btw uiEnhancer and enactors.

[09:56:04 CST(-0600)] <cindyli> any idea of a better work-around?

[10:00:15 CST(-0600)] <Bosmon> cindyli - can you explain what you would write if FLUID-5193 were resolved?

[10:02:00 CST(-0600)] <cindyli> Bosmon: i would use a distributeOptions block to pass fluid.prefs.uiEnhancerConnections as a grade to all enactors

[10:04:26 CST(-0600)] <Bosmon> cindyli - it seems that the effect of your temporary grade is different - it creates a new enhancer for each grade rather than arranging to share an applier

[10:06:46 CST(-0600)] <cindyli> Bosmon: do you mean i can use a fake enhancer as long as it has an applier rather than creating a whole real enhancer?

[10:07:21 CST(-0600)] <cindyli> i can certainly do that

[10:07:38 CST(-0600)] <Bosmon> cindyli - well, right now I'm not sure how your temporary grade is equivalent to the uiEnhancerConnections grade

[10:07:46 CST(-0600)] <Bosmon> How does one thing have the effect of another?

[10:08:52 CST(-0600)]

[10:09:20 CST(-0600)] <cindyli> with its reference on uiEnhancer, i need this component on the tree

[10:28:06 CST(-0600)] <Bosmon> cindyli - so I am still confused

[10:28:15 CST(-0600)] <Bosmon> You say, " i would use a distributeOptions block to pass fluid.prefs.uiEnhancerConnections as a grade to all enactors"

[10:28:31 CST(-0600)] <Bosmon> But then you say that it is because of the uiEnhancerConnections grade that your fluid.tests.uiEnhancer grade exists

[10:28:39 CST(-0600)] <Bosmon> Which implies that uiEnhancerConnections is already applied

[10:28:41 CST(-0600)] <Bosmon> Can you explain?

[10:33:05 CST(-0600)] <cindyli> Bosmon: if 5193 is resolved, we can add a distributeOptions block on "fluid.prefs.starterEnactors" to pass down fluid.prefs.uiEnhancerConnections to its sub-components which are enactors. To work around 5193, fluid.prefs.uiEnhancerConnections is currently added to enactors directly. since fluid.prefs.uiEnhancerConnections requires the presence of uiEnhancer which leads to having fluid.tests.uiEnhancer in unit tests for all enactors

[10:33:19 CST(-0600)] <cindyli> let me know if i made it clear

[10:36:01 CST(-0600)] <Bosmon> cindyli - ok, I see now, that you apply the connections grade manually in the auxBuilder

[10:37:31 CST(-0600)]

[10:37:46 CST(-0600)] <Bosmon> I ass you have also added the connections grade to fluid.prefs.enactor itself, where it probably might not belong

[10:38:24 CST(-0600)] <Bosmon> Actually there seems to be a duplication here since the connections is present within fluid.prefs.enactor as well as being encoded in the AuxBuilder

[10:48:51 CST(-0600)] <cindyli> you are right, Bosmon, a duplication in the aux builder. it would make sense again once ur IoCSS expression is applied and uiEnhancerConnections is removed from the grade list of fluid.prefs.enactor

[12:13:14 CST(-0600)] <Justin_o> Bosmon: have you had a chance to look at the FLUID-5205 branch again https://github.com/fluid-project/infusion/pull/433

[12:13:23 CST(-0600)] <cindyli> Bosmon: the pull request for 5191 (https://github.com/fluid-project/infusion/pull/425) is ready for more reviews

[12:13:27 CST(-0600)] <Justin_o> it should be ready to go for another round of code review

[13:43:16 CST(-0600)] <Justin_o> Bosmon: i'm having another issue with model relay and composite panels.. when the sub panel has a fluid decorator in it's tree we need to setup the model relay for it.. part of which is to pass in the parent's applier. However this reference is sourced at render time but after render the sub panel is recreated so the decorators refers to an old applier. The

[13:43:16 CST(-0600)] <Justin_o> result of this is kind of strange... changing the model of the decorator component updates the composite panel's model correctly, but doesn't update the sub panels at all.. I assume this is because the old applier is updating the composite panel, but should't the change in the composite panel have filtered back down to the sub panel. Updating the composite

[13:43:16 CST(-0600)] <Justin_o> panel's model directly will in fact update the sub panel.

[13:44:09 CST(-0600)] <Justin_o> Bosmon: i can only theorize that somehow it appears that the sources are the same and the model isn't being relayed

[13:44:14 CST(-0600)] <Justin_o> Bosmon: any thoughts?

[13:50:43 CST(-0600)] <Bosmon> Justin_o - this is most likely a result stemming from your workaround to the model update timing problems you were describing last week

[13:51:19 CST(-0600)] <Bosmon> It sounds like the solution to this was to fall back to a ancestral model involving "model sharing" between the components, which was something we had hoped to eliminate with the use of model relay systems

[13:51:39 CST(-0600)] <Bosmon> The fact that you are seeing "update leakage" between the composite panel's model and the subpanel suggests that these have become aliased together

[13:51:49 CST(-0600)] <Justin_o> Bosmon: i wasn't able to get the timing to actually work, i had to instead just modify how the rebasing worked

[13:51:59 CST(-0600)] <Bosmon> Justin_o: exactly

[13:52:16 CST(-0600)] <Bosmon> And I assume that "modifying how the rebasing worked" involved aliasing some of the models together throughout the component tree

[13:52:35 CST(-0600)] <Justin_o> Bosmon: no not at all.. i'll send you some code

[13:52:49 CST(-0600)] <Bosmon> Justin_o - but it sounds from your description that they are indeed aliased

[13:53:01 CST(-0600)] <Bosmon> Given you said " Updating the composite panel's model directly will in fact update the sub panel."

[13:53:38 CST(-0600)] <Justin_o> Bosmon: here's the rebasing change

[13:53:38 CST(-0600)] <Justin_o> https://github.com/jobara/infusion/blob/ec00cedb90f1efabdc450ec10ef523a3dd8498c0/src/framework/preferences/js/Panels.js#L510-L512

[13:53:57 CST(-0600)] <Justin_o> so basically i just source the value from the composite panel instead of from the sub panel

[13:54:15 CST(-0600)] <Justin_o> Bosmon: so if we have a set of components set up like this

[13:54:26 CST(-0600)] <Justin_o> compositePanel -> subPanel -> decorator

[13:54:47 CST(-0600)] <Justin_o> if i call requestChange on compositePanel, subPanel's model will be correctly updated

[13:55:05 CST(-0600)] <Justin_o> but the decorator is not

[13:55:30 CST(-0600)] <Justin_o> if i call requestChange on the decorator, the compositePanel's model is updated, but the subPanel's isn't

[13:55:34 CST(-0600)] <Justin_o> Bosmon: ^

[13:55:35 CST(-0600)] <Bosmon> Justin_o - I assume by a decorator you mean a "renderer decorator"

[13:55:42 CST(-0600)] <Justin_o> Bosmon: that's correct

[13:55:58 CST(-0600)] <Bosmon> That is, a view-bearing Fluid component which is rendered using the "fluid" decorator type in the "old renderer"

[13:56:11 CST(-0600)] <Justin_o> Bosmon: it has the applier from the old sub panel by old i mean, before it is recreated after rendering

[13:56:22 CST(-0600)] <Justin_o> Bosmon: yes.. that is correct

[13:56:48 CST(-0600)] <Bosmon> This stuff is all very dangerous.... which is why we would prefer to do this kind of thing via model relay

[13:56:58 CST(-0600)] <Bosmon> By "this stuff" I mean the business of sharing model references and applier references

[13:57:18 CST(-0600)] <Justin_o> Bosmon: it is the intention to use the model relay.. in fact it is setup to do so

[13:58:07 CST(-0600)] <Bosmon> Justin_o - ok - the idea of an "old applier" sounds hazardous

[13:58:22 CST(-0600)] <Bosmon> If you have a two-step linkage, this should be done by two levels of model relay

[13:58:43 CST(-0600)] <Justin_o> Bosmon: yes.. but i don't know how to correct that since the decorator is created on render, and the sub panel is recreated after the rendering

[13:58:48 CST(-0600)] <Bosmon> You say, " this reference is sourced at render time but after render the sub panel is recreated so the decorators refers to an old applier"

[13:58:53 CST(-0600)] <Justin_o> this is all because the composite panel handles it's sub panel's rendering

[13:59:13 CST(-0600)] <Bosmon> Firstly I must say that I am very sorry to have landed you with this mess

[13:59:27 CST(-0600)] <Bosmon> Which you would not have if we had i) a sensible model relay system, and ii) a sensible renderer : P

[13:59:59 CST(-0600)] <Justin_o> Bosmon: no worries.. it's just the state of progress we are currently at

[14:00:04 CST(-0600)] <Bosmon> It is all extremely unsatisfactory

[14:00:12 CST(-0600)] <Bosmon> So - can you describe where this "old applier" is sourced from?

[14:00:18 CST(-0600)] <Bosmon> Which component did it belong to?

[14:01:21 CST(-0600)] <Bosmon> Personally I would try to do without the renderer decorator entirely if you can, and just try to use a "createOnEvent" traditional subcomponent

[14:01:46 CST(-0600)] <Bosmon> Trying to tunnel configuration through the renderer's interpretation mechanism will only multiply your problems

[14:02:53 CST(-0600)] <Justin_o> Bosmon: sure.. 1) we create but don't render the sub panels so that we can get things from them like their produceTree function 2) we render - at his point the decorator has the applier supplied as a reference to the sub panel it is bound to. currently this is correct 3) after render we recreate the sub panels to establish the correct bindings to the DOM -

[14:02:53 CST(-0600)] <Justin_o> at this point the sub panel is given a new applier thus severing the connection to the rendered decorator

[14:04:30 CST(-0600)] <Bosmon> Justin_o - have you verified that the listeners bound by the old renderer decorator have been correctly unbound when it is destroyed?

[14:04:32 CST(-0600)] <Justin_o> Bosmon: funny.. i've been advocating for not using renderer decorators and using subcomponents instead.. i guess this may be the final straw. Although i had hoped it would still be possible to use if the implementor preferred.

[14:04:53 CST(-0600)] <Bosmon> Justin_o - the implementor doesn't really get the choice here, given that renderer decorators are a doomed feature

[14:05:08 CST(-0600)] <Bosmon> Just as with demands blocks, we would hope to have as few of them as possible around when the renderer is destroyed

[14:05:28 CST(-0600)] <Bosmon> So I would strongly recommend you reimplement this setup using subcomponents which will at least help us to study the problem better

[14:05:29 CST(-0600)] <Justin_o> Bosmon: no i have not.. i tried stepping through the model relay but there are so much being relayed i just got lost

[14:06:03 CST(-0600)] <Justin_o> Bosmon: i would hope the problem would just go away with subcomponents

[14:06:12 CST(-0600)] <Justin_o> since they will be created along with the sub panel

[14:07:08 CST(-0600)] <Justin_o> Bosmon: okay.. i'll reimplement with subcomponents instead.. i'll let you know if i run into any more issues

[14:07:32 CST(-0600)] <Justin_o> anastasiac: you might want to add this to your documentation.. fluid renderer decorators are not supported in subpanels

[14:07:33 CST(-0600)] <Bosmon> Justin_o - you may have to start tracing this through carefully, making use of the "changeid" field which is attached to each applier in order to distinguish them

[14:08:02 CST(-0600)] <anastasiac> Justin_o: good to know!! thanks for the heads-up

[14:08:04 CST(-0600)] <Bosmon> That looks like the name for it which is currently in trunk

[14:08:23 CST(-0600)] <Justin_o> Bosmon: does the changeid refer to the applier's id?

[14:08:25 CST(-0600)] <Bosmon> You can see it being attached in the changeApplier's creator:

[14:08:25 CST(-0600)] <Bosmon> var that = {

[14:08:26 CST(-0600)] <Bosmon> changeid: fluid.allocateGuid(),

[14:08:26 CST(-0600)] <Bosmon> model: model

[14:08:26 CST(-0600)] <Bosmon> };

[14:08:28 CST(-0600)] <Bosmon> Justin_o - yes

[14:08:37 CST(-0600)] <Bosmon> Each ChangeApplier will have a unique id attached to it

[14:09:02 CST(-0600)] <Bosmon> So if you get lost, you will have to start writing down these ids on a small piece of paper : P

[14:09:36 CST(-0600)] <Bosmon> The system's trajectory will be deterministic (or should be) and so you should be able to rely on these being stable from run to run (minus the variable prefix referring to the Fluid instance)

[14:09:57 CST(-0600)] <Justin_o> Bosmon: yes.. i was trying to step through looking at the changeapplier, but i think it took 10+min to trace through all of the relays... there are quite a large number in the demo i'm using.. i'll try to comment out a bunch of the other configuration, that should simplify it

[14:10:10 CST(-0600)] <Bosmon> These kinds of debugging techniques end up being essential in the more complex scenarios we first started to encounter in the CSpace days

[14:10:34 CST(-0600)] <Bosmon> Justin_o - another important technique is the use of conditional breakpoints to only stop on the instances of the framework's code that refer to the objects that you are interested in

[14:10:48 CST(-0600)] <Bosmon> Without which it can indeed take hours to trace through a system of relays : P

[14:11:09 CST(-0600)] <Bosmon> But there are intended to be enough "landmarks" in the system (component ids, applier ids, and instantiator contents) to help you find your way around

[14:12:04 CST(-0600)] <Justin_o> Bosmon: thanks.. i'll give it a try

[14:12:11 CST(-0600)] <Bosmon> Justin_o - good luck

[14:12:23 CST(-0600)] <Justin_o> thanks

[14:12:25 CST(-0600)] <Bosmon> It should be a substantial simplification in any case to get rid of the renderer decorators

[14:12:34 CST(-0600)] <Bosmon> Especially given they are things that we will not be supporting

[14:12:43 CST(-0600)] <Justin_o> after i trace through this and let you know what i find.. then i'll switch to subcomponents

[14:12:51 CST(-0600)] <Bosmon> Subcomponents with createOnEvent will always be supported

[14:13:08 CST(-0600)] <Bosmon> But the "new renderer" will provide slightly more compact ways of expressing them

[14:13:21 CST(-0600)] <Bosmon> But they will still essentially appear as traditional subcomponents

[14:13:31 CST(-0600)] <Justin_o> cool... that will simplify things

[14:40:04 CST(-0600)] <Justin_o> Bosmon: here's the output of the model relays http://pastie.org/private/trdoydkvbjz4z0rtboelhw

[14:40:35 CST(-0600)] <Justin_o> i'd assume that it's only the tops of those stacks that are interesting.. also i don't know what 86 is..

[14:42:02 CST(-0600)] <Bosmon> Justin_o - the sourceApplier with id 86?

[14:42:23 CST(-0600)] <Bosmon> That is quite a bewildering number of relays

[14:42:28 CST(-0600)] <Bosmon> Do you know why there are so many?

[14:42:38 CST(-0600)] <Justin_o> Bosmon: so you can see that is it in fact using the old applier when trying to update values from the textStepper, which is the decorator... and this applier is still bound to relay changes to increaseSize

[14:42:52 CST(-0600)] <Bosmon> It would appear that either i) a large number of redundant relays are being created and/or ii) listeners are not being unbound to old relays

[14:43:37 CST(-0600)] <Justin_o> Bosmon: yes.. sourceApplier 86.. and i have no idea why there are so many.. there is model binding to the enhancers.. but 269 and 263 seem to happen excessively

[14:59:14 CST(-0600)] <Justin_o> Bosmon: i did single test of converting one of the sub panels to use subcomponents instead of decorators and it works now.. i'll change the rest

[15:48:39 CST(-0600)] <Bosmon> Justin_o - great