fluid-work IRC Logs-2013-11-07

[07:32:33 CST(-0600)] <Justin_o> Bosmon7: hello.. i've been wondering how namespacing works with modelListeners

[07:33:07 CST(-0600)] <Bosmon7> Justin_o - I imagine that it will fail with the current implementation

[07:35:25 CST(-0600)] <Bosmon7> In general I advise you not to depend on it until the new ChangeApplier is implemented

[07:35:36 CST(-0600)] <Bosmon7> It's possible that if you tried it now you might get some results

[07:35:45 CST(-0600)] <Bosmon7> It would help if you could describe your use case

[07:35:54 CST(-0600)] <Bosmon7> Gosh, doesn't everyone get into work early : P

[07:37:05 CST(-0600)] <Justin_o> Bosmon7: will you start coming in early now too

[07:37:17 CST(-0600)] <Bosmon7> Not for much longer

[07:38:02 CST(-0600)] <Justin_o> Bosmon7: i'll try to take advantage while i can then

[07:38:31 CST(-0600)] <Justin_o> Bosmon7: so i'm using the modelListeners for my composite panel work, for the creation of of sub panels based on model values

[07:39:35 CST(-0600)] <Justin_o> Bosmon7: you can see it here https://github.com/jobara/infusion/blob/FLUID-5205/src/framework/preferences/js/Panels.js#L310-L314

[07:39:43 CST(-0600)] <Justin_o> currently i'm just stuffing them into an array

[07:40:08 CST(-0600)] <Justin_o> i still have to write unit tests for this.. so for now i'm only assuming that this actually works

[07:40:59 CST(-0600)] <Bosmon7> Justin_o - you have the wrong syntax

[07:41:06 CST(-0600)] <Bosmon7> ModelListeners is a hash whose key is the model path

[07:41:07 CST(-0600)] <Bosmon7> Not an array

[07:41:42 CST(-0600)] <Bosmon7> I guess you meant to write modelListeners[pref] on that highlighted line

[07:41:48 CST(-0600)] <Bosmon7> Anyway, what use do you have for the namespace?

[07:42:12 CST(-0600)] <Justin_o> ah yes.. thanks for spotting that..

[07:42:49 CST(-0600)] <Justin_o> then i could assign these to unique namespaces instead of the array... i suppose for this case it doesn't really matter.. as i doubt we'd want them to be deleted or overridden

[07:43:35 CST(-0600)] <Justin_o> Bosmon7: but i was curious about it when looking at the modelListeners.. also what does gaurdSource do?

[07:43:46 CST(-0600)] <Bosmon7> It was actually hard for me to think of a clear use case for selectively overriding model listeners

[07:43:53 CST(-0600)] <Bosmon7> Especially given that they are all listening to variously different paths

[07:44:17 CST(-0600)] <Bosmon7> I thought we needed this functionality carried over from conventional listeners, but I managed to convince myself in the new implementation that we probably don't

[07:44:32 CST(-0600)] <Bosmon7> The path "guardSource" allows you to prevent a listener triggering for a change with a particular "source"

[07:44:47 CST(-0600)] <Bosmon7> You can ask cindyli about this since she has experience of the old utilities with the videoPlayer : P

[07:45:46 CST(-0600)] <Justin_o> Bosmon7: okay... so i probably won't need to worry about it and if i run into something i'll check with cindyli

[07:46:01 CST(-0600)] <Justin_o> Bosmon7: any comments on my general approach for FLUID-5205

[07:47:29 CST(-0600)] <Justin_o> I think these are the changes specific to FLUID-5205 https://github.com/jobara/infusion/compare/FLUID-5200...FLUID-5205

[07:47:34 CST(-0600)] <Bosmon7> Justin_o - thanks

[07:47:55 CST(-0600)] <Justin_o> i'm probably going to remove the custom refreshView, i don't think i'll need the extra event anymore

[07:48:46 CST(-0600)] <Bosmon7> Justin_o - the name "fluid.prefs.compositePanel.subPanelCreationTiming" seems misleading

[07:48:57 CST(-0600)] <Bosmon7> It doesn't seem to really return anything related to timing : P

[07:49:31 CST(-0600)] <Justin_o> Bosmon7: it sets the createOnEvent properties

[07:49:34 CST(-0600)] <Bosmon7> And also the general approach seems a bit wobbly, in that it seems odd to render parts of panels and then only hide them later if you find they are "inactive"

[07:49:54 CST(-0600)] <Bosmon7> Justin_o - it seems to do a good deal more than that

[07:50:58 CST(-0600)] <Justin_o> Bosmon7: i'm not sure of a way around that.. see the template for the composite panel has the containers for the sub panels to render into.. we don't want those to show up if the panels themselves aren't rendered

[07:51:26 CST(-0600)] <Justin_o> Bosmon7: and at the same time they need to be present when the component is created (but not rendered) since the sub panels require the dom container for initialization

[07:51:47 CST(-0600)] <Justin_o> Bosmon7: also any recommendations for a more suitable name

[07:51:58 CST(-0600)] <Bosmon7> Justin_o - well, what does it do

[07:53:20 CST(-0600)] <Justin_o> Bosmon7: it adds the events that will be used to for the createOnEvent, adds the createOnEvent properties, binds modelListener events and handles these as well as afterRender and onCreate for knowing when to trigger the create event or destroy the component

[07:53:39 CST(-0600)] <Justin_o> Bosmon7: it really does quite a bit

[07:53:57 CST(-0600)] <Justin_o> Bosmon7: maybe something like subPanelLifeCycleBindings

[07:54:14 CST(-0600)] <Bosmon7> Sounds reasonable

[07:59:47 CST(-0600)] <Justin_o> Bosmon7: okay.. thanks.. i'll change that.. going back to the other issue with the hiding of the containers.. do you have more thoughts on that?

[07:59:51 CST(-0600)] <Justin_o> or anything else for that matter

[08:01:15 CST(-0600)] <Bosmon7> The approach looks broadly reasonable

[08:01:25 CST(-0600)] <Bosmon7> Some commenting wouldn't go amiss, since this logic is fairly intricate

[08:02:18 CST(-0600)] <Justin_o> Bosmon7: okay.. that also makes sense.. thanks

[08:23:38 CST(-0600)] <Justin_o> Bosmon7: made some changes based on your feedback https://github.com/jobara/infusion/compare/FLUID-5200...FLUID-5205

[08:35:44 CST(-0600)] <Bosmon7> Hi there yzen

[08:35:48 CST(-0600)] <yzen> Bosmon7: hi

[08:36:07 CST(-0600)] <Bosmon7> Unfortunately it looks like I can't resolve FLUID-5208 after all

[08:36:14 CST(-0600)] <yzen> oh noes

[08:36:21 CST(-0600)] <Bosmon7> I'm not sure what the reason was that I thought I couldn't do it before

[08:36:30 CST(-0600)] <Bosmon7> But certainly there are now new reasons why I can't do it : P

[08:36:44 CST(-0600)] <yzen> right

[08:36:50 CST(-0600)] <Bosmon7> There's just too much special-case processing for the "listeners" block now that implies it must be directly visible under the correct name

[08:36:50 CST(-0600)] <yzen> i found another bug that i will file

[08:36:55 CST(-0600)] <yzen> re dynamic grades

[08:37:14 CST(-0600)] <Bosmon7> For example we now have "expandCompact" as well as "annotateListeners"

[08:37:18 CST(-0600)]

[08:37:39 CST(-0600)] <Bosmon7> And so if the "listeners" block just consists of an IoC reference, its contents would "sneak in under the covers" without being pre-processed properly

[08:38:01 CST(-0600)] <Bosmon7> Unfortunately I got 90% of the way through the implementation work before discovering that it was impossible : P

[08:38:12 CST(-0600)] <yzen> ok

[08:38:22 CST(-0600)] <Bosmon7> yzen - what would you like "arguments" to evaluate to?

[08:38:36 CST(-0600)] <yzen> well no what i mean is that they just done get expanded

[08:38:39 CST(-0600)] <yzen> in dynamic grades

[08:38:54 CST(-0600)] <Bosmon7> ok

[08:38:55 CST(-0600)] <yzen> if i mention them in members block

[08:39:40 CST(-0600)] <Bosmon7> Do you mean in expanders?

[08:39:47 CST(-0600)] <Bosmon7> That is, in expanders in the members block

[08:40:05 CST(-0600)] <yzen> no

[08:40:21 CST(-0600)] <Bosmon7> Ok, if they are not in an expander, what should the value of "arguments" be?

[08:40:32 CST(-0600)] <yzen> brb

[09:15:32 CST(-0600)] <anastasiac> Justin_o, cindyli, I think the composite panels documentation page is ready to share, but I believe that there are still outstanding branches that would need to be merged before master actually works properly with composite panels, is that correct? And if so, should I hold off on letting the architecture list know about the composite panels until master is updated?

[09:38:31 CST(-0600)] <Justin_o> anastasiac: the fixes for those bugs you've found haven't gone in yet..

[09:38:38 CST(-0600)] <Justin_o> anastasiac: perhaps we should wait for those

[09:39:09 CST(-0600)] <anastasiac> ok, Justin_o, that's what I suspected

[09:39:10 CST(-0600)] <anastasiac> thanks

[10:01:12 CST(-0600)] <Bosmon7> yzen

[10:01:27 CST(-0600)] <yzen> Bosmon7:

[10:01:36 CST(-0600)] <Bosmon7> How is your "arguments" issue?

[10:02:21 CST(-0600)] <michelled> Bosmon7: we need to push Justin_o and cindyli's 5200 branch

[10:02:31 CST(-0600)] <Justin_o> https://github.com/fluid-project/infusion/pull/432

[10:02:36 CST(-0600)] <michelled> he was just about to take me through all the details of the fixes that they've done

[10:02:39 CST(-0600)] <Bosmon7> michelled - I'd like to get some clarity on that

[10:02:49 CST(-0600)] <michelled> what were you wondering Bosmon7?

[10:03:03 CST(-0600)] <Justin_o> Bosmon7, michelled: we also need this one in after that https://github.com/fluid-project/infusion/pull/431

[10:03:10 CST(-0600)] <Bosmon7> michelled - just what other commits it depends on in and in what order

[10:03:25 CST(-0600)] <Bosmon7> I think Justin_o had mentioned there was an interdependence between that and cindyli's textfieldSlider work

[10:03:46 CST(-0600)] <yzen> Bosmon7: ill make a JIRA and describe my case with an example

[10:03:50 CST(-0600)] <yzen> it will be more obvious

[10:04:02 CST(-0600)] <Bosmon7> yzen - thanks!

[10:04:03 CST(-0600)] <Justin_o> Bosmon7: my understanding is that https://github.com/fluid-project/infusion/pull/431 is dependent on https://github.com/fluid-project/infusion/pull/432

[10:07:05 CST(-0600)] <Bosmon7> I guess I'm hesitant to comment too much on something which is so urgent, especially if it is working

[10:07:19 CST(-0600)] <Bosmon7> But I wonder if you could explain the use of the component defaults at line 286

[10:07:30 CST(-0600)] <Bosmon7> https://github.com/fluid-project/infusion/pull/432/files#diff-4ea13c1c02992def09fa53326d6d5de8R286

[10:07:55 CST(-0600)] <Bosmon7> This seems in principle dodgy and I am wondering why it is not sufficient to inspect the options which are actually there?

[10:09:50 CST(-0600)] <Justin_o> Bosmon7: i'll try to remember if there was a specific reason

[10:11:04 CST(-0600)] <Justin_o> Bosmon7: the options there are the supplied options as opposed to the components default options.

[10:11:50 CST(-0600)] <Bosmon7> Justin_o - is it not likely that the actually present options are more relevant than the defaults?

[10:12:05 CST(-0600)] <Bosmon7> It seems that going for the defaults is liable to cause "unexpected effects" for the integrator

[10:12:07 CST(-0600)] <Justin_o> Bosmon7: i suppose they are both relevant

[10:12:16 CST(-0600)] <Bosmon7> I have commented the other place where you have used defaults too

[10:12:23 CST(-0600)] <Bosmon7> Other than these 3 issues I think the pull looks fine

[10:12:56 CST(-0600)] <Justin_o> Bosmon7: in the case of the sub panels i would expect the defaults to be valid, but i think it would be better if they were merged

[10:12:59 CST(-0600)] <Justin_o> what do you think?

[10:14:13 CST(-0600)] <Bosmon7> Justin_o - ok, I see the issue, you are inspecting the nested options set "ahead of time" ....

[10:14:27 CST(-0600)] <Justin_o> Bosmon7: yes.. exactly

[10:14:44 CST(-0600)] <Bosmon7> Ok

[10:15:11 CST(-0600)] <Bosmon7> In that case you should make a better attempt to simulate the real action of the framework at this point, although it will actually be quite hard to be completely accurate

[10:15:41 CST(-0600)] <Bosmon7> Since in addition to the options you can see, you could expect to have to account for the effects of any "distributeOptions" blocks which may have been elsewhere in the tree

[10:15:50 CST(-0600)] <Bosmon7> And, were they still existing, any demands blocks : P

[10:15:57 CST(-0600)] <Justin_o> Bosmon7:

[10:16:29 CST(-0600)] <Justin_o> it would be easier if i was working with the actual component instance, but in case of the isPanel function, i'm not sure i can

[10:16:51 CST(-0600)] <Justin_o> there are some cases that have to run before hand.. at time of gradeMerging

[10:18:03 CST(-0600)] <Bosmon7> Justin_o - as a first pass, I suggest you make a utility function which strings together the action of i) fluid.getGradedDefaults, ii) fluid.merge

[10:18:12 CST(-0600)] <Bosmon7> That should be "faithful" enough to be good for now

[10:18:59 CST(-0600)] <Bosmon7> You can supply the typeName and any gradeNames in the subcomponent record to fluid.getGradedDefaults to get a more accurate default

[10:19:14 CST(-0600)] <Bosmon7> And then merge that with the subcomponent's actual options using the mergePolicy that you can find in it

[10:19:25 CST(-0600)] <Bosmon7> Although this will still be inaccurate in a few important ways

[10:19:42 CST(-0600)] <Bosmon7> It would be better in the long term if you could think of a way of doing this "as the component instantiates" rather than ahead of time

[10:22:22 CST(-0600)] <Justin_o> Bosmon7: i'll investigate where i can make use of actual components instead, the only spot where I know that won't work is for things that are used to generate dynamic grades. At the moment that is in the fluid.prefs.compositePanel.assembleDistributeOptions function. There's another one coming in my FLUID-5205 branch as well.

[10:24:06 CST(-0600)] <Justin_o> Bosmon7: switching to use live components will also have the other issue of needing to rerun these functions when FLUID-5205 lands because of it's support for creating and destroying subpanels

[10:24:39 CST(-0600)] <Bosmon7> Justin_o - couldn't the generation of the dynamic grades also be done "live", by means of a contextualised invoker?

[10:25:08 CST(-0600)] <Justin_o> hmm.. what does that mean

[10:26:07 CST(-0600)] <Bosmon7> Justin_o - I mean, a gradeName which holds the name of an invoker

[10:26:18 CST(-0600)] <Bosmon7> An actually "dynamic grade"

[10:27:28 CST(-0600)] <Justin_o> Bosmon7: i'm not sure i follow..

[10:27:51 CST(-0600)]

[10:28:11 CST(-0600)] <Justin_o> Bosmon7: i think we had problems before when trying to add invokers with a dynamic grade because the invokers block is resolved ahead of time to facilitate calling it in the dynamic grade

[10:28:22 CST(-0600)] <Justin_o> Bosmon7: well i do have that

[10:28:30 CST(-0600)] <Bosmon7> Justin_o - I'm sorry, yes, I had been hoping to revisit that issue today

[10:28:38 CST(-0600)] <Bosmon7> Since I thought that it might have been fixed by some other recent work

[10:28:44 CST(-0600)] <Justin_o> oh

[10:28:44 CST(-0600)] <Bosmon7> Unfortunately I think I have run out of time for now

[10:28:54 CST(-0600)] <Justin_o>

[10:29:02 CST(-0600)] <Justin_o> that's too bad.. when do you think you'll be back

[10:29:22 CST(-0600)] <Bosmon7> I might reappear for a bit on Monday

[10:30:32 CST(-0600)] <Justin_o> Bosmon7: okay.. hope you have a good weekend.. do you think if i can address the issues you've mentioned now that michelled could push it in?

[10:30:41 CST(-0600)] <Bosmon7> Justin_o - yes

[10:31:14 CST(-0600)] <Bosmon7> If you can replace those sites where you make a raw call to the defaults, with, in both locations, a call to a common utility function which makes a better attempt at options merging, that will be fine

[10:36:34 CST(-0600)] <avtar> anastasiac: this http://sphinx-doc.org/ is the project michelled referred to

[10:39:19 CST(-0600)] <avtar> and free hosting of docs generated using sphinx is provided by this project https://read-the-docs.readthedocs.org/en/latest/getting_started.html

[10:39:49 CST(-0600)] <Justin_o> Bosmon7: thanks.. i'll work on that

[10:54:41 CST(-0600)] <cindyli> justin, one thing to confirm before I push in, in the structure we finalized yesterday, is the left side "prefKey" like this:

[10:54:41 CST(-0600)] <cindyli> "always": ["subPanel5"],

[10:54:41 CST(-0600)] <cindyli> "fluid.prefs.subPanel5": ["subPanel6"]

[10:54:41 CST(-0600)] <cindyli> "fluid.prefs.subPanel6": ["subPanel7", "subPanel8"]

[10:56:09 CST(-0600)] <cindyli> or it would be like:

[10:56:09 CST(-0600)] <cindyli> "always": ["subPanel5"],

[10:56:09 CST(-0600)] <cindyli> "subPanel5": ["subPanel6"]

[10:56:09 CST(-0600)] <cindyli> "subPanel6": ["subPanel7", "subPanel8"]

[10:56:29 CST(-0600)] <cindyli> my code is currently assuming the former.

[10:56:39 CST(-0600)] <cindyli> Justin_o: ^

[10:57:35 CST(-0600)] <Justin_o> cindyli: i was thinking the former as well.. if it works with "."

[10:59:05 CST(-0600)] <cindyli> "." seems working fine so far by confined in quotes, Justin_o

[10:59:24 CST(-0600)] <Justin_o> cindyli: great.. let's go with that.. i think it will be easier for an integrator

[10:59:44 CST(-0600)] <cindyli> cool

[11:03:06 CST(-0600)] <cindyli> Justin_o: changes on aux builder for 5205 has been pushed up - https://github.com/cindyli/infusion/commit/69469500098d72789efaacf9f9473613a17bcfe4

[11:03:22 CST(-0600)] <cindyli> actually, https://github.com/cindyli/infusion/tree/FLUID-5205

[11:03:35 CST(-0600)] <Justin_o> cindyli: thanks

[11:03:39 CST(-0600)] <cindyli> np

[13:07:27 CST(-0600)] <Justin_o> Bosmon7: are you still around?

[14:09:41 CST(-0600)] <Justin_o> cindyli: your pull request handles FLUID-5190 and FLUID-5903?

[14:11:54 CST(-0600)] <cindyli> Justin_o: it handles 5190 & 5203

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

[15:36:37 CST(-0600)] <colinclark> hey sgithens, are you around?

[15:38:18 CST(-0600)] <sgithens> colinclark: hey

[15:38:23 CST(-0600)] <colinclark> IT WORKS!

[15:38:25 CST(-0600)] <sgithens> !

[15:38:32 CST(-0600)] <sgithens> IRC ?

[15:38:35 CST(-0600)] <colinclark>

[15:38:44 CST(-0600)] <colinclark> MASTER!

[15:38:56 CST(-0600)] <colinclark> I had to write a horrific bash function

[15:38:57 CST(-0600)] <sgithens> FONT?

[15:39:02 CST(-0600)] <colinclark> and talkback!

[15:39:05 CST(-0600)] <sgithens>

[15:39:14 CST(-0600)] <sgithens> what did you have to write a bash function for?

[15:39:14 CST(-0600)] <colinclark> It's really, really exciting

[15:39:21 CST(-0600)] <sgithens>

[15:39:24 CST(-0600)] <colinclark> No more ESExplorer!

[15:39:27 CST(-0600)] <sgithens> that's awesome

[15:39:29 CST(-0600)] <sgithens> oh sweet

[15:39:32 CST(-0600)] <sgithens> you mounted the directory

[15:39:34 CST(-0600)] <colinclark> yes

[15:39:34 CST(-0600)] <sgithens> r/w

[15:39:37 CST(-0600)] <colinclark> with bash

[15:39:43 CST(-0600)] <sgithens> you should totally push that up

[15:39:47 CST(-0600)] <sgithens>

[15:39:52 CST(-0600)] <colinclark> michelled can attest to what an achievement that is for this point, point, click, clicker

[15:39:56 CST(-0600)] <sgithens> did you get if rom javi

[15:40:06 CST(-0600)] <michelled>

[15:40:38 CST(-0600)] <colinclark> I based it on that email he sent in response to you on the architecture list

[15:40:47 CST(-0600)] <sgithens> awesome!

[15:42:12 CST(-0600)] <colinclark> I'll make a pull request shortly

[15:42:25 CST(-0600)] <sgithens> I will totally test and merge that tonight

[15:43:14 CST(-0600)] <colinclark> thanks, if you have time

[15:43:52 CST(-0600)] <sgithens> Next on my merge list was Javi's UI for the activity, but I cna probably do both

[15:44:21 CST(-0600)] <sgithens> also, because I don't want ot use ES Explorer anymore either

[15:44:24 CST(-0600)] <sgithens>