/
fluid-work IRC Logs-2013-11-22

fluid-work IRC Logs-2013-11-22

Nov 22, 2013

[07:48:15 CST(-0600)] <Justin_o> cindyli1: good morning

[07:48:24 CST(-0600)] <cindyli1> morning, Justin_o

[07:48:37 CST(-0600)] <Justin_o> cindyli1: i see you've been talking to Bosmon

[07:48:46 CST(-0600)] <Justin_o> cindyli1: and your FLUID-5191 pull has been merged

[07:49:28 CST(-0600)] <cindyli1> ya

[07:49:59 CST(-0600)] <Justin_o> cindyli1: are you working on FLUID-5213 or waiting on Bosmon for code review

[07:50:24 CST(-0600)] <cindyli1> waiting on more code review. let me know if anything I can help with

[07:50:45 CST(-0600)] <Justin_o> cindyli1: are you working on anything in particular at the moment?

[07:51:30 CST(-0600)] <cindyli1> not really. Bosmon said the code itself looks good, i wonder if he has more suggestions on design

[07:51:55 CST(-0600)] <cindyli1> i mean the code for 5213

[07:58:27 CST(-0600)] <Justin_o> cindyli1: ah yes.. i see that up there..

[07:58:37 CST(-0600)] <Justin_o> cindyli1: okay.. did you want to help me with FLUID-5220

[07:59:14 CST(-0600)] <cindyli1> sure, meantime, i'm going thru the bug tracker for prefs framework to see if any other blockers

[07:59:26 CST(-0600)] <cindyli1> the only one left is: http://issues.fluidproject.org/browse/FLUID-5174

[07:59:28 CST(-0600)] <Justin_o> cindyli1: there are those 3 things i mentioned yesterday. 1) unit tests 2) updating all the panels 3) refactoring the composite panel

[07:59:49 CST(-0600)] <cindyli1> ok, carry on

[07:59:53 CST(-0600)] <Justin_o> that's it

[08:00:04 CST(-0600)] <Justin_o> cindyli1: i wonder if that one is related to the work in bosmon's last pull request

[08:00:47 CST(-0600)] <cindyli1> exactly, just tried one demo with ie8 and seems it's fixed. I will try others. if all works, will close that jira

[08:01:40 CST(-0600)] <cindyli1> Justin_o: let me know which one you'd prefer me to pick up for 5220. should we skype to chat?

[08:02:33 CST(-0600)] <Justin_o> cindyli1: sure

[08:14:25 CST(-0600)] <Justin_o> cindyli1: i forgot to put something gin the composite panel.. I need to actually have a function that refreshes the dom binder and that should trigger the onDomBind event.. it should still happen afterRender but there needs to be an intermediate process.. i'll work that in now and push up asap

[08:15:45 CST(-0600)] <cindyli1> thanks, Justin_o. i need some time to file a jira for an IE8 issue anyway. the good news is it's confirmed that 5174 is fixed

[08:16:16 CST(-0600)] <cindyli1> by Bosmon's fix on 5172

[08:17:33 CST(-0600)] <Justin_o> cindyli1: excellent

[08:39:35 CST(-0600)] <Justin_o> cindyli1: forgot to tell you that i pushed up the change to the events already

[08:40:23 CST(-0600)] <cindyli1> cool. thanks, Justin_o

[08:41:17 CST(-0600)] <Justin_o> cindyli1: thanks.. hacking on the composite panel code now..

[08:42:13 CST(-0600)] <cindyli1> ok. btw, i created a new jira for ie8 issue: http://issues.fluidproject.org/browse/FLUID-5221 don't think it's a blocker

[08:42:57 CST(-0600)] <Justin_o> cindyli1: thanks.. i think the css isn't supported

[08:43:08 CST(-0600)] <cindyli1> ya

[09:41:37 CST(-0600)] <Justin_o> cindyli1: did you push up all the changes for your work on FLUID-5220?

[09:41:56 CST(-0600)] <cindyli1> nothing changed for (2), working on (1)

[09:42:02 CST(-0600)] <Justin_o> cindyli1: okay.. thanks

[09:42:08 CST(-0600)] <cindyli1> np

[09:42:49 CST(-0600)] <Justin_o> cindyli1: i think i'm done my part of 3, except that i need to update the unit tests.. which i'm going to work on now.

[09:43:33 CST(-0600)] <cindyli1> go ahead, Justin_o, i'm working on a new unit test, not touching the ones already in there

[09:44:11 CST(-0600)] <Justin_o> cindyli1: great.. no collisions (smile)

[09:44:31 CST(-0600)] <cindyli1> (smile)

[09:48:07 CST(-0600)] <Justin_o> cindyli1: i pushed up my code changes.. working on the tests now.. you may want to wait till your tests pass before merging mine in though.. in case my changes are buggy.

[09:48:26 CST(-0600)] <cindyli1> ok. thanks, Justin_o

[09:52:40 CST(-0600)] <Justin_o> cindyli1: hmm.. there may be a problem with my code (sad)

[09:52:55 CST(-0600)] <cindyli1> oh, what's up

[09:53:06 CST(-0600)] <Justin_o> cindyli1: the container is wrong

[09:53:16 CST(-0600)] <Justin_o> i wonder how i can rebind the container

[09:53:24 CST(-0600)] <Justin_o> for the subpanels

[09:53:29 CST(-0600)] <cindyli1> at the 2nd refreshView?

[09:53:43 CST(-0600)] <Justin_o> cindyli1: afterRender

[09:53:55 CST(-0600)] <Justin_o> so the container of the component is still pointing at the old container that had been removed from the markup

[09:54:27 CST(-0600)] <cindyli1> umm..

[09:58:01 CST(-0600)] <Justin_o> cindyli1: haha.. that's my thoughts too

[09:58:20 CST(-0600)] <cindyli1> (smile)

[09:59:13 CST(-0600)] <cindyli1> Justin_o: not clear DOM at the first afterRender?

[10:00:19 CST(-0600)] <Justin_o> cindyli1: no.. that clears the dom binders cache.. probably only really needed if there was a use of fastlocate

[10:00:27 CST(-0600)] <Justin_o> but this is for the components container..

[10:00:45 CST(-0600)] <Justin_o> specifically the sub panels container

[10:04:42 CST(-0600)] <Justin_o> cindyli1: i'm drawing a blank.. I might have to talk to Bosmon about it

[10:06:06 CST(-0600)] <cindyli1> good idea, Justin_o. Bosmon - our life saver (wink)

[10:12:50 CST(-0600)] <Justin_o> (wink)

[10:12:55 CST(-0600)] <Justin_o> definitely

[10:15:12 CST(-0600)] <Justin_o> cindyli1: i think i have a work around... i don't know if Bosmon would approve of it or not

[10:15:46 CST(-0600)] <cindyli1> how?

[10:23:14 CST(-0600)] <Justin_o> cindyli1: something like this, but i'll change it around to work in the subpanl grade.

[10:23:15 CST(-0600)] <Justin_o> that.subPanel1.container = $(that.subPanel1.container.selector);

[10:23:15 CST(-0600)] <Justin_o> fluid.initDomBinder(that.subPanel1, that.subPanel1.selectors);

[10:26:04 CST(-0600)] <Justin_o> this example is from my test code where i'm playing with it

[10:33:07 CST(-0600)] <Justin_o> michelled, yzen: stand up

[11:25:43 CST(-0600)] <michelled> Justin_o: http://issues.fluidproject.org/browse/FLOE-108

[11:28:50 CST(-0600)] <michelled> Justin_o: I think that work should happen in its own repo

[12:10:55 CST(-0600)] <Bosmon> Justin_o - yes, that is correct

[12:11:02 CST(-0600)] <Bosmon> You will need to recreate the DOM binder complete

[12:11:03 CST(-0600)] <Bosmon> ly

[12:11:53 CST(-0600)] <Justin_o> Bosmon: cool.. FLUID-5220 is basically done.. cindyli is just writing up a couple new tests. she's stepped out for a bit but that should be ready to go today at some point

[12:12:11 CST(-0600)] <Bosmon> Justin_o - very good!

[12:12:15 CST(-0600)] <Bosmon> What's the render time now?

[12:12:50 CST(-0600)] <Justin_o> Bosmon: FLUID-5205 should be all ready now too.. i've merged in anastasiac's instructional demos in

[12:13:16 CST(-0600)] <Justin_o> Bosmon: hmm. not sure, but they looked fast.. we have to do a build to get it running with that other sample code.. so i've been holding off doing that

[12:13:52 CST(-0600)] <Justin_o> Bosmon: looked fast in anastasiac's examples that is

[12:15:30 CST(-0600)] <Justin_o> cindyli: good timing.. welcome back..

[12:15:39 CST(-0600)] <Justin_o> cindyli: i've finished up my work for FLUID-5220

[12:15:45 CST(-0600)] <Justin_o> it's all pushed up into my branch now

[12:16:05 CST(-0600)] <cindyli> oh yay. thanks. i will merge in

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

[12:23:58 CST(-0600)] <cindyli> Justin_o: the unit test for onDomBind is pushed up to my 5220 branch

[12:24:16 CST(-0600)] <Justin_o> cindyli: thanks

[12:24:21 CST(-0600)] <Justin_o> i'll pull that in and file a pull request

[12:24:21 CST(-0600)] <cindyli> np

[12:24:30 CST(-0600)] <cindyli> sounds good. thanks

[12:29:02 CST(-0600)] <Justin_o> Bosmon: the pull request for FLUID-5220 is also ready. https://github.com/fluid-project/infusion/pull/439

[12:29:12 CST(-0600)] <Bosmon> Thanks, Justin_o - quick work!

[12:29:18 CST(-0600)] <Justin_o> it includes the changes from the FLUID-5205 pull request, so that should probably go in first.

[12:29:29 CST(-0600)] <Justin_o> Bosmon: thanks.. hopefully it's up to par (smile)

[12:30:13 CST(-0600)] <Bosmon> I think somehow the diff view of FLUID-5205 has got stuck (sad)

[12:30:21 CST(-0600)] <Justin_o> Bosmon: really

[12:30:31 CST(-0600)] <Bosmon> Oh wait, there it is, in the middle..

[12:31:22 CST(-0600)] <Bosmon> Justin_o, anastasiac - didn't we in the end make a "one stop shop" function which creates and invokes a preferences editor in a single operation?

[12:31:41 CST(-0600)] <Bosmon> It seems extremely unnatural to expect a "standard integrator" to call framework functions such as fluid.invokeGlobalFunction

[12:32:12 CST(-0600)] <anastasiac> ah, right, the builder does create a function that the integrator can invoke. We should use that in our demos

[12:32:25 CST(-0600)] <Justin_o> Bosmon: well the grade exists to be used as you'd like.. we did something like that for uiOptions.. so we call fluid.uiOptions.prefsEditor i believe

[12:32:46 CST(-0600)] <anastasiac> the default grade name is not … ideal

[12:32:49 CST(-0600)] <Bosmon> Justin_o - I very much doubt that "as you'd like" includes arcana such as fluid.invokeGlobalFunction : P

[12:33:13 CST(-0600)] <Bosmon> The instructional demos should illustrate standard workflow

[12:33:25 CST(-0600)] <Bosmon> Which I imagine involves actually using the component you have defined : P

[12:33:34 CST(-0600)] <Justin_o> Bosmon: some people might like to type out longs function names that they may not know how to use (wink)

[12:34:36 CST(-0600)] <anastasiac> Justin_o, just double checking: it looks like the default namespace is "fluid.prefs.create" - is that right? so they'd invoke "fluid.prefs.create.prefsEditor();"?

[12:34:47 CST(-0600)] <anastasiac> assuming they don't specify a namespace

[12:34:50 CST(-0600)] <Justin_o> Bosmon: it is a shame that we've gotten the gpii folks into the habit of using this method.. these new demos should help them with that

[12:35:11 CST(-0600)] <Justin_o> anastasiac: i think that's correct

[12:35:15 CST(-0600)] <Justin_o> let me take a quick look

[12:35:38 CST(-0600)] <Justin_o> anastasiac: yes.. should be whatever the namespace is followed by prefsEditor

[12:36:44 CST(-0600)] <anastasiac> confirmed, that works, Justin_o. Do you want me to make this change to my branch and you can merge, or do you just want to do it?

[12:37:00 CST(-0600)] <Justin_o> i'll merge in your branch

[12:37:04 CST(-0600)] <Justin_o> anastasiac: ^

[12:37:11 CST(-0600)] <anastasiac> k

[12:39:32 CST(-0600)] <anastasiac> Justin_o, pushed

[12:39:44 CST(-0600)] <Justin_o> anastasiac: thanks.. i'll update my branch

[12:40:46 CST(-0600)] <Justin_o> Bosmon: FLUID-5205 has been updated with anastasiac's change

[12:48:53 CST(-0600)] <Justin_o> Bosmon: when you update tooltip for the new jQueryUI ... can you make sure that we can support custom content like http://jqueryui.com/tooltip/#custom-content

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

[12:50:22 CST(-0600)] <Bosmon> Could you add a note for that to our jQuery upgrade JIRA?

[12:50:33 CST(-0600)] <Bosmon> And - how bad is the contents of your branch? : P

[12:50:40 CST(-0600)] <Bosmon> Are there massive and widespread failures? : P

[12:50:47 CST(-0600)] <Justin_o> Bosmon: yes.. that makes sense.. i'll add a note..

[12:51:02 CST(-0600)] <Bosmon> I noticed that we will need to adopt the use of a custom plugin since it seems that $.browser has been withdrawn

[12:51:11 CST(-0600)] <Justin_o> Bosmon: no.. i think from what i remember it was only for things that used tooltip and tabs..

[12:51:15 CST(-0600)] <Bosmon> And, contrary to what the jQuery religion suggests, I don't believe it's practical to do without it

[12:51:39 CST(-0600)] <Justin_o> Bosmon: you don't think we can feature detect everything we need?

[12:52:05 CST(-0600)] <Bosmon> Justin_o - we certainly can't

[12:52:06 CST(-0600)] <Justin_o> Bosmon: i'm guessing they are relying more on things like modernizr

[12:53:13 CST(-0600)] <Justin_o> Bosmon: when do you think you'll have a chance to look at that by the way... i think i'm going to need the tooltip for the metadata work

[12:53:19 CST(-0600)] <Bosmon> I certainly appreciate the reasoning behind the elimination of browser detects, but for a practical person who actually wants things that work, many cases can't be eliminated

[12:53:30 CST(-0600)] <Bosmon> Especially where we find ourselves working around particular bugs in particular implementations

[12:53:52 CST(-0600)] <Justin_o> Bosmon: the solution to that is to drop support for that environment (smile)

[12:54:01 CST(-0600)] <Justin_o> if only we could do that

[12:54:05 CST(-0600)] <Bosmon> I just had to add another IE detection to my FLUID-5204 branch

[12:54:25 CST(-0600)] <Bosmon> Justin_o - I'm not aware of any particular brower implementations that are free of bugs that need to be worked around : P

[12:54:49 CST(-0600)] <Bosmon> Although I guess Safari is close to being a "neutral" environment that doesn't bring too many of its own quirks to the engine

[12:55:03 CST(-0600)] <Justin_o> Bosmon: yeah for safari..

[12:55:12 CST(-0600)] <Justin_o> that's my personal browser of choice these days

[12:57:48 CST(-0600)] <Bosmon> Unfortunately nothing these days performs as well as Chrome

[12:57:55 CST(-0600)] <Bosmon> As we are seeing with your rendering tests

[12:58:30 CST(-0600)] <Justin_o> Bosmon: yes.. it is pretty fast...

[12:59:05 CST(-0600)] <Bosmon> Justin_o - I can't understand the operation of the "fluid.prefs.create.prefsEditor" function that I see in the demo files now

[12:59:11 CST(-0600)] <Bosmon> Why doesn't it make reference to the operation of the builder?

[13:08:48 CST(-0600)] <Justin_o> Bosmon: that is the grade that is created by the builder by default for a prefsEditor.

[13:09:11 CST(-0600)] <Justin_o> Bosmon: an integrator could supply any namespace they'd want though..

[13:09:29 CST(-0600)] <Justin_o> Bosmon: does that make sense?

[13:11:47 CST(-0600)] <Justin_o> Bosmon: also i added a comment to FLUID-5185 about the tooltip upgrade http://issues.fluidproject.org/browse/FLUID-5185#comment-24025

[13:26:09 CST(-0600)] <Bosmon> Justin_o - I don't think it is desirable (the fixed grade)

[13:26:24 CST(-0600)] <Bosmon> There is still too much "magic" in this process

[13:26:49 CST(-0600)] <Bosmon> I think that what we should have is what was originally suggested, was a "one stop shop" method which defines and creates a preferences editor in one single operation

[13:26:59 CST(-0600)] <Bosmon> I think I've been saying this repeatedly, but perhaps it hasn't been understood (smile)

[13:27:11 CST(-0600)] <Bosmon> And the editor should have a unique grade name each time, if one is not specified

[13:27:20 CST(-0600)] <Bosmon> As well as being more reliable, this will be even easier for the integrator

[13:27:33 CST(-0600)] <Bosmon> It's very important to not have a "things that go bump in the night" implementation

[13:27:47 CST(-0600)] <Bosmon> That is, a thing which requires you to a) first do this, and b) then do this other apparently unrelated thing

[13:28:12 CST(-0600)] <Bosmon> The fixed name "fluid.prefs.create.prefsEditor" should be removed as a fixed name used by the implementors

[13:31:27 CST(-0600)] <Justin_o> Bosmon: i think we did talk this over before.. i'm trying to remember the details though..

[13:32:05 CST(-0600)] <Justin_o> Bosmon: i think one issue though is what you expect to get back.. so if it is something that runs a builder call internally, would you get the prefs editor back , or the builder, or a thing that includes a builder and a prefs editor

[13:32:16 CST(-0600)] <Bosmon> Justin_o - you would just get the prefs editor

[13:32:24 CST(-0600)] <Bosmon> The default user has no interest in the builder whatesolver

[13:32:28 CST(-0600)] <Bosmon> whatsoever

[13:32:52 CST(-0600)] <Bosmon> I would say that our current solution appears as a manifestation of the "POLTERGEIST ANTIPATTERN" : P

[13:32:53 CST(-0600)] <Bosmon> http://sourcemaking.com/antipatterns/poltergeists

[13:33:12 CST(-0600)] <Justin_o> i can't believe that's a real thing (smile)

[13:33:15 CST(-0600)] <Bosmon> hahahaha

[13:33:26 CST(-0600)] <Bosmon> It's quite an interesting book, although very old-fashioned

[13:34:22 CST(-0600)] <Justin_o> Bosmon: cool.. maybe i'll take a look at it sometime

[13:34:39 CST(-0600)] <Justin_o> Bosmon: anyways.. doesn't this break our convention where a component always returns itself

[13:35:13 CST(-0600)] <Bosmon> Justin_o - how is the user to know that our "build and create" function isn't a component?

[13:35:17 CST(-0600)] <Bosmon> It will look exactly like one

[13:35:26 CST(-0600)] <Bosmon> Given it takes i) a container, and ii) some options as an argument

[13:35:33 CST(-0600)] <Bosmon> And it returns a component

[13:35:37 CST(-0600)] <Bosmon> NOTHING COULD BE MORE LOGICAL : P

[13:35:50 CST(-0600)] <Justin_o> Bosmon: i guess what you are saying is that it isn't a component, but just a function

[13:36:12 CST(-0600)] <Justin_o> so you couldn't use it in say an IoC tree

[13:36:17 CST(-0600)] <Bosmon> The end user really doesn't care about whether "something is a component" or not, if they can call a function with a reasonable signature and get a component out of it

[13:36:18 CST(-0600)] <Justin_o> as you would a component

[13:36:21 CST(-0600)] <Bosmon> Right

[13:36:30 CST(-0600)] <Bosmon> But the end user in general doesn't care about that either

[13:36:43 CST(-0600)] <Bosmon> That is, the "particular kind of integrator" that we are targeting the instructional demos at

[13:36:59 CST(-0600)] <Bosmon> If they are at the level of sophistication where they care about whether they can use it in an IoC tree or not, we can point them at other documentation

[13:37:07 CST(-0600)] <Bosmon> but that already writes off 95% of our expected audience

[13:37:18 CST(-0600)] <Justin_o> (smile)

[13:37:37 CST(-0600)] <Justin_o> Bosmon: okay.. so what should we call this function.. fluid.prefs.something

[13:37:49 CST(-0600)] <Justin_o> something === createPrefsEditor ?

[13:37:50 CST(-0600)] <Bosmon> Something like "buildAndCreate" or so

[13:38:16 CST(-0600)] <Justin_o> Bosmon: how about fluid.prefs.create

[13:38:37 CST(-0600)] <Bosmon> Seems reasonable

[13:38:41 CST(-0600)] <Bosmon> By the "95% principle"

[13:38:51 CST(-0600)] <Bosmon> I guess the 95% aren't even interested that they have in fact invoked a 2-step process

[13:39:06 CST(-0600)] <Justin_o> Bosmon: cool (smile)

[13:39:32 CST(-0600)] <Justin_o> Bosmon: i'm going to file this under a different jira though

[13:40:34 CST(-0600)] <Justin_o> Bosmon: do you think we need a similar onestop function for the enhancer?

[13:42:34 CST(-0600)] <Bosmon> Justin_o - the use case for that isn't so powerful

[13:42:42 CST(-0600)] <Bosmon> In what situation does an integrator just want to create an enhancer?

[13:43:13 CST(-0600)] <Justin_o> Bosmon: i guess it would be for those case where you have single prefsEditor on your site, but each page needs to be enhanced.

[13:43:28 CST(-0600)] <Bosmon> Doesn't sound like a very powerful use case

[13:43:39 CST(-0600)] <Bosmon> Why would we have places where preferences are acted upon, but can't be adjusted?

[13:43:50 CST(-0600)] <Justin_o> Bosmon: yes..at any rate we can come back to it if need be.. starting with this should hit the majority

[13:44:19 CST(-0600)] <Justin_o> Bosmon: i don't know if we will anymore.. not in the newer designs anyways.. but i think that was the idea of the full page variants before

[13:46:29 CST(-0600)] <Justin_o> Bosmon: here's the new jira http://issues.fluidproject.org/browse/FLUID-5222

[13:50:11 CST(-0600)] <Justin_o> Bosmon: any thoughts on how to structure the options.. i guess there may be a distinction between options to the builder and those to the prefsEditor

[13:50:24 CST(-0600)] <Justin_o> Bosmon: or do you think it would be better to just accept a subset of possible options

[13:50:42 CST(-0600)] <Bosmon> Justin_o - yes, there should be two options areas

[13:50:53 CST(-0600)] <Bosmon> Or even three, depending on whether there is an enhancer

[13:51:05 CST(-0600)] <Justin_o> Bosmon: well there's always an enhancer.. (smile)

[13:51:08 CST(-0600)] <Justin_o> sometimes it

[13:51:16 CST(-0600)] <Justin_o> sometimes it's just empty, if you have no enactors

[13:52:04 CST(-0600)] <Justin_o> but those can be passed in to the prefsEditor since at this level it refers to the whole stack

[13:52:26 CST(-0600)] <Justin_o> perhaps there could be some renaming here since prefsEditor refers to both the stack and the UI portion

[13:52:33 CST(-0600)] <Justin_o> Bosmon: ^

[13:53:34 CST(-0600)] <Justin_o> Bosmon: so anyways.. i image you are expecting something like fluid.prefs.create(".container", {build: {}, prefsEditor: {});

[13:53:43 CST(-0600)] <Bosmon> Justin_o - exactly, yes

[13:54:17 CST(-0600)] <Justin_o> Bosmon: cool, that should be easy enough

[14:10:27 CST(-0600)] <Bosmon> Justin_o - I think another fantastic antipattern is the WOLF TICKET ANTIPATTERN : P

[14:10:29 CST(-0600)] <Bosmon> http://sourcemaking.com/antipatterns/wolf-ticket

[14:10:39 CST(-0600)] <Bosmon> It seems prettly clear that OAuth is one of these

[14:12:00 CST(-0600)] <Justin_o> Bosmon: is this true "Only 6 percent of information systems standards have test suites"

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

[14:12:14 CST(-0600)] <Bosmon> Where are the test suites for oauth?

[14:12:20 CST(-0600)] <Bosmon> I think by definition such a thing is impossible

[14:13:03 CST(-0600)] <Justin_o> you mean it's impossible to have tests for standards.. or specifically for OAuth

[14:13:16 CST(-0600)] <Bosmon> For Oauth in particular

[14:13:27 CST(-0600)] <Bosmon> Since the standard doesn't actually determine any particular behaviour

[14:13:45 CST(-0600)] <Justin_o> ah.. has that guy succeeded in making a replacement for it yet.. i remember watching that video you sent along before

[14:13:46 CST(-0600)] <Bosmon> WebGL is one of the few standards that have a test suite - but sadly, I don't think there is a single implementation which can pass them

[14:13:55 CST(-0600)] <Justin_o> Bosmon: (sad)

[14:14:11 CST(-0600)] <Bosmon> Justin_o - he hasn't, he just has a scrappy "scratch" project in github with no docs (smile)

[14:14:32 CST(-0600)] <Justin_o> sounds like a good start (wink)

[14:26:46 CST(-0600)] <cindyli> Bosmon: for the pull request for 5213: https://github.com/fluid-project/infusion/pull/438, wonder if you have more suggestions on design.

[14:45:10 CST(-0600)] <Justin_o> cindyli: i'm changing things up to have a one-stop build and create function.. as part of this i have to generate a unique namespace so that we can run it multiple times.. it seems reasonable to mean that this should be the default behaviour of the prefsFramework.. so i have it working but the auxBuilder tests are broken.. would you be able to help me fix

[14:45:11 CST(-0600)] <Justin_o> them.

[14:45:55 CST(-0600)] <cindyli> sure, Justin_o, is it 5220 branch? or 5205?

[14:46:11 CST(-0600)] <Justin_o> cindyli: it's FLUID-5222

[14:46:23 CST(-0600)] <Justin_o> i'll have something pushed up in one minute

[14:46:24 CST(-0600)] <cindyli> ah ha. another one. ok, Justin_o

[14:50:41 CST(-0600)] <Justin_o> cindyli: yes.. another one.. it's pushed up in my FLUID-5222 branch

[14:51:11 CST(-0600)] <cindyli> got it

[14:51:31 CST(-0600)] <Justin_o> cindyli: great, thanks

[14:51:37 CST(-0600)] <cindyli> np

[14:51:55 CST(-0600)] <Justin_o> cindyli: i'm going to update the demos to use the new single build and init functions

[14:51:58 CST(-0600)] <Justin_o> function

[14:52:06 CST(-0600)] <cindyli> ok

[15:05:04 CST(-0600)] <Justin_o> cindyli: i've updated the manual tests..

[15:05:22 CST(-0600)] <cindyli> ok, thanks. still fixing aux builder

[15:05:47 CST(-0600)] <cindyli> i mean the unit tests for aux builder

[15:08:58 CST(-0600)] <Justin_o> cindyli: this branch is based on master

[15:09:11 CST(-0600)] <Justin_o> cindyli: probably should have mentioned that earlier, so if things look different that's why

[15:09:31 CST(-0600)] <cindyli> ok

[15:20:22 CST(-0600)] <Justin_o> cindyli: how are things going.. i hope the changes i made make sense..

[15:21:25 CST(-0600)] <cindyli> getting close. why do we use a random string for namespace? to reduce the collision when 2 prefs editor on one page?

[15:22:30 CST(-0600)] <Justin_o> cindyli: yes.. basically.. and it's not good to call fluid.default on the same name more than once

[15:22:57 CST(-0600)] <Justin_o> cindyli: i have a startsWith function in the builder tests if that helps

[15:23:33 CST(-0600)] <Justin_o> cindyli: i'm going to head out now.. anything else before i go?

[15:25:00 CST(-0600)] <cindyli> Justin_o: unit tests are fixed and pushed up

[15:25:12 CST(-0600)] <Justin_o> cindyli: great thanks.. i'll file a pull request for it

[15:25:16 CST(-0600)] <cindyli> thanks, Justin_o

[15:26:36 CST(-0600)] <Justin_o> cindyli: is github down for you

[15:26:41 CST(-0600)] <Justin_o> i can't seem to open my repos (sad)

[15:27:31 CST(-0600)] <Justin_o> cindyli: if you are able to, could you send the pull request for FLUID-5222

[15:27:36 CST(-0600)] <cindyli> i can

[15:27:42 CST(-0600)] <cindyli> sure, i can send the pull request

[15:27:46 CST(-0600)] <Justin_o> cindyli: thanks

[15:27:50 CST(-0600)] <Justin_o> i just have bad luck i guess

[15:27:53 CST(-0600)] <cindyli> np. have a good weekend

[15:27:59 CST(-0600)] <Justin_o> thanks, you too

[15:28:11 CST(-0600)] <cindyli> save ur good luck for weekend then (wink)

[15:28:19 CST(-0600)] <Justin_o> (smile)

[15:39:14 CST(-0600)] <cindyli> Bosmon: Justin_o added a one-stop function to build and instantiate the prefs editor. the jira for this is FLUID-5222. here's the pull request - https://github.com/fluid-project/infusion/pull/440. can you review it when you have a chance? Thanks.

[15:39:23 CST(-0600)] <Bosmon> Thanks, cindyli

[15:39:33 CST(-0600)] <cindyli> np. thank YOU!

[15:40:12 CST(-0600)] <cindyli> btw, Bosmon, don't forget my pull request for 5213 - https://github.com/fluid-project/infusion/pull/438. thanks