fluid-work IRC Logs-2011-03-30
[03:02:34 CDT(-0500)] <pulkit> Hi
[03:03:57 CDT(-0500)] <pulkit> What are the high priority image processing algorithms expected other than cropping, resizing and tagging?
[08:24:20 CDT(-0500)] <kasper> yura_:
[08:24:24 CDT(-0500)] <yura_> kasper:
[08:24:32 CDT(-0500)] <kasper> do you have a sec to look at my code
[08:24:43 CDT(-0500)] <kasper> or answer a question anyways
[08:24:52 CDT(-0500)] <kasper> so.. the recordeditor tests are failing for me
[08:25:16 CDT(-0500)] <kasper> complaining about pageBuilderIO
[08:25:31 CDT(-0500)] <kasper> (ooops, just realizing we're in fluid-channel)
[08:26:44 CDT(-0500)] <Justin_o> kasper: you're welcome to complain in here
[08:26:58 CDT(-0500)] <Justin_o> harriswong: how did the jquery ui upgrade go?
[08:28:04 CDT(-0500)] <heidi> Justin_o added linearizing notes to wiki as 1.4 subpage http://wiki.fluidproject.org/display/fluid/Linearizing+issues
[08:28:17 CDT(-0500)] <harriswong> Justin_o: i replaced the files with 1.8.11 and they are sitting on the branch, i haven't went into testing them yet.
[08:28:29 CDT(-0500)] <Justin_o> harriswong: ah okay
[08:28:50 CDT(-0500)] <harriswong> Justin_o: Is there a particular test plan for doing jquery ui upgrade?
[08:29:16 CDT(-0500)] <Justin_o> harriswong: not really.. i guess just make sure everything that was using it still works
[08:29:22 CDT(-0500)] <kasper> Justin_o: haha, I dont know if you'll still say that after 4 days of me constantly whining to yura
[08:29:47 CDT(-0500)] <Justin_o> kasper: if it's to yura_ i have no problem
[08:29:54 CDT(-0500)] <harriswong> Justin_o: ok.
[08:29:57 CDT(-0500)] <kasper> haha
[08:30:09 CDT(-0500)] <harriswong> Justin_o: i have also created a jira and have pushed it to my github yesterday.
[08:31:38 CDT(-0500)] <Justin_o> harriswong: thanks.. that's good.. i guess for testing you should start with the unit tests... particularly the tooltip one... since that is a wrapper around their tooltip.. from there you can look at the test plans and just do the state tests
[08:32:03 CDT(-0500)] <Justin_o> harriswong: also try running the tests in IE 9 if you can, since things like our reorderer weren't working there before
[08:52:25 CDT(-0500)] <harriswong> Justin_o: ok
[09:10:46 CDT(-0500)] <michelled> cindyli: did you start looking at ui options?
[09:12:13 CDT(-0500)] <cindyli> michelled: cloned branch, haven't looked into yet. spending most time this morning chatting with gsoc students and reviewing their proposals
[09:12:41 CDT(-0500)] <michelled> ok, let me know when you're ready to get started and I'll come over there so we can pair
[09:22:19 CDT(-0500)] <harriswong> mlam: can you try running the unit tests for uploader and see if it is working?
[09:23:40 CDT(-0500)] <mlam> in your branch ? or from the master?
[09:24:04 CDT(-0500)] <harriswong> mlam: mm master please.
[09:25:13 CDT(-0500)] <mlam> sure
[09:27:53 CDT(-0500)] <jhung> anastasiac: something to keep in mind when doing platform research for tech docs...
[09:28:18 CDT(-0500)] * anastasiac leans in expectantly
[09:28:28 CDT(-0500)] <jhung> we'll probably want some sort of ability to handle code snippts well. So fixing width of code snippit boxes, proper indentation, wrapping, maybe numbering.
[09:29:24 CDT(-0500)] <mlam> harriswong: weird, 2 of the files aren't even executing any tests and the filequeueview tests are all broken
[09:30:35 CDT(-0500)] <mlam> i'm going to try them out in FF3.6
[09:32:45 CDT(-0500)] <mlam> harriswong: so there's a broken test in HTML5, looks like the fluid.makeChangeApplier isn't found, and then a few tests in the fileQueueView. are you getting the same?
[09:34:09 CDT(-0500)] <harriswong> mlam: Yep i have the makeChangeApplier not found, and i had a fluid.alias error before but now it's gone.
[09:35:02 CDT(-0500)] <mlam> are you free to help get them fixed?
[09:38:28 CDT(-0500)] <harriswong> mlam: sure. the test case i wrote is now failing on flash as well, fixing.
[09:38:45 CDT(-0500)] <mlam> cool, thanks
[09:41:53 CDT(-0500)] <cindyli> michelled: anytime when you are ready
[10:00:23 CDT(-0500)] <pulkit> What are the high priority algorithms to be implemented for image editor?
[10:12:50 CDT(-0500)] <jessm> pulkit: i'm guessing you're talking about the GSoC project?
[10:13:44 CDT(-0500)] <michelled> yura_: are there debugging supports for IoC now?
[10:13:44 CDT(-0500)] <pulkit> yyesyyes
[10:13:53 CDT(-0500)] <pulkit> yes
[10:14:04 CDT(-0500)] <yura_> michelled: there is much better logging now
[10:14:14 CDT(-0500)] <yura_> and i think mentioned that he added something recently
[10:14:21 CDT(-0500)] <yura_> but i didnt update to new infusion just yet
[10:14:39 CDT(-0500)] <michelled> yura_: ya, I remember a commit log mentioning it but somehow can't find it right now
[10:14:51 CDT(-0500)] <michelled> I think I need to include the debugging file
[10:15:14 CDT(-0500)] <yura_> michelled: oh
[10:15:18 CDT(-0500)] <yura_> i didnt know about that
[10:15:47 CDT(-0500)] <jessm> pulkit: and did you look here? http://wiki.atutor.ca/display/atutorwiki/Google+Summer+of+Code+2011#GoogleSummerofCode2011-FluidProjects
[10:16:23 CDT(-0500)] <michelled> pulkit: the Image Editor project comes out of the Decapod project. Some of the features we want to support are cropping, resizing and marking regions on an image
[10:16:58 CDT(-0500)] <pulkit> Yes. I looked there. Apart from those, are there any other features that have a high priority?
[10:17:36 CDT(-0500)] <michelled> from talking to jameswy it sounds like we want some images tagging for the Floe project
[10:17:59 CDT(-0500)] <michelled> pulkit: one of the most important features is that everything should be accessible.
[10:18:00 CDT(-0500)] <jessm> pulkit: as michelled mentioned – that project is part of this http://sites.google.com/site/decapodproject/ take a look at the work in the wiki to date too: http://wiki.fluidproject.org/display/fluid/Decapod and get to know michelled as she'll be the mentor
[10:19:24 CDT(-0500)] <michelled> pulkit: meaning that it should be doable using either a keyboard or a mouse and should provide enough information to an adaptive technology to communicate how to use the feature and the results of using it
[10:20:42 CDT(-0500)] <pulkit> Okay. Thanks
[10:26:12 CDT(-0500)] <michelled> yura_: From the commit log "New powerful improvement in IoC diagnostics - file and line number tracking for fluid.demands! Include file "FluidDebugging.js" to get access to this facility on Firefox. "
[10:26:42 CDT(-0500)] <colinclark> Those diagnostics are going to be awesome, I think
[10:26:56 CDT(-0500)] <yura_> michelled: I should check it out
[10:46:46 CDT(-0500)] <colinclark> mlam, harriswong: So, can you guys elaborate on the test failures you mentioned at standup?
[10:47:03 CDT(-0500)] <colinclark> And can I reproduce them against the latest version of the project repo, just by running all of Uploader's unit tests?
[10:47:21 CDT(-0500)] <mlam> colinclark: The test that's failing in the FileQueueView are related to null events in the progress component
[10:47:35 CDT(-0500)] <mlam> Yes, I downloaded a fresh copy from the master and ran the tests
[10:47:38 CDT(-0500)] <colinclark> When did it start failing?
[10:48:02 CDT(-0500)] <mlam> Either yesterday or today. The last update I did was Monday
[10:48:19 CDT(-0500)] <colinclark> Ok
[10:48:26 CDT(-0500)] <colinclark> How does it relate to the ChangeApplier?
[10:48:47 CDT(-0500)] <mlam> With the HTML5 tests failing, one was broke on a call to the ChangeApplier. It was just before stand up, so I didn't look much further
[10:48:53 CDT(-0500)] <colinclark> ok
[10:49:20 CDT(-0500)] <colinclark> michelled: Do you have five minutes to help me with a Git question, or are you in the midst of coding?
[10:49:36 CDT(-0500)] <michelled> I can help
[10:50:07 CDT(-0500)] <michelled> colinclark: want me to come there?
[10:50:14 CDT(-0500)] <colinclark> that'd be great
[10:55:51 CDT(-0500)] <colinclark> mlam: Revision 9ab11c05ad2813f8baefff6abcd2c27b41e4ed92 worked
[10:56:16 CDT(-0500)] <colinclark> For both sets of tests--the FileQueueView and the BrowseButtonView tests
[10:56:40 CDT(-0500)] <colinclark> So the first set of Bosmon2's commits yesterday, db474aab142b1a91032a72bb06f4909315127af9, seemed to cause the regression
[10:57:06 CDT(-0500)] <colinclark> With michelled's help, I checked that by following key commits backwards with "git log"
[10:58:30 CDT(-0500)] <colinclark> and, one by one, used "git reset --hard <revision hash>"
[10:58:37 CDT(-0500)] <colinclark> And then ran the tests
[10:58:45 CDT(-0500)] <colinclark> the key issue is the point michelled raised at a dev meeting a few weeks ago
[10:59:04 CDT(-0500)] <colinclark> You have to watch for merge points as key milestones when the project repo actually changes
[10:59:16 CDT(-0500)] <colinclark> other commits will be there, but will have happened at some other point
[10:59:40 CDT(-0500)] <colinclark> the good news is that the master branch hasn't been merged into in over a week--Justin_o and Bosmon2 have been working directly in master
[10:59:50 CDT(-0500)] <colinclark> so each commit actually represents a real point in the history of the proejct repo
[11:01:16 CDT(-0500)] <colinclark> mlam, harriswong: My first guess for the failing browseButtonView test is that Bosmon2 accidentally introduced a dependency on DataBinding.js, but our test file doesn't include it.
[11:01:22 CDT(-0500)] <colinclark> We'll need to see if that is by design or by error
[11:01:33 CDT(-0500)] <mlam> that's a pretty cool feature...i like that
[11:03:42 CDT(-0500)] <mlam> colinclark: adding the DataBinding dependency worked
[11:05:01 CDT(-0500)] <colinclark> Do you know why that fixed it, mlam?
[11:05:32 CDT(-0500)] <mlam> No, where did the DataBinding dependency happen?
[11:05:58 CDT(-0500)] <colinclark> I poked around in the debugger for a bit.
[11:06:21 CDT(-0500)] <colinclark> I think it's probably an error in the test-we should have been including DataBinding.js-we do in the Uploader's own HTML file, as well as in the demo
[11:06:41 CDT(-0500)] <colinclark> but the reason it suddenly broke is a change in the framework, which was apparent from using my debugger
[11:07:22 CDT(-0500)] <colinclark> So, if you look at the stack trace of the error, it's clear that it's failing to find fluid.makeChangeApplier() while in the midst of doing fluid.initView()
[11:07:39 CDT(-0500)] <colinclark> If you remember, the browseButtonHandler is, like any component that uses the DOM, a View component
[11:07:53 CDT(-0500)] <colinclark> So we have recently introduced the concept of "grades" into the framework
[11:08:09 CDT(-0500)] <colinclark> Coming from a Java background, it's tempting to think of them as types
[11:08:24 CDT(-0500)] <colinclark> there are handful of grades, and they are compositions--one grade may be composed of several other grades
[11:08:43 CDT(-0500)] <colinclark> so browseButtonView has a View grade
[11:08:57 CDT(-0500)] <colinclark> The View grade is composed of several other grades
[11:09:18 CDT(-0500)] <colinclark> You can see our grades defined started at line 835 of Fluid.js
[11:09:34 CDT(-0500)] <colinclark> At line 866, you'll see the grade of "fluid.viewComponent"
[11:10:08 CDT(-0500)] <colinclark> and so you'll notice that a View component is composed of three important grades: Little Component, Model Component, and Evented Component
[11:10:29 CDT(-0500)] <michelled> yura_: are you using the createOnEvent feature of IoC?
[11:10:39 CDT(-0500)] <yura_> yes
[11:10:42 CDT(-0500)] <colinclark> at the risk of misleading you with Java analogies, you can think of the View Grade implementing the Little, Model, and Evented interfaces, mlam
[11:10:43 CDT(-0500)] <yura_> michelled: ^
[11:10:57 CDT(-0500)] <michelled> yura_: do you know if it can be used without autoinit?
[11:11:03 CDT(-0500)] <yura_> michelled: yes
[11:11:23 CDT(-0500)] <yura_> it shouldnt matter whether you have autoinit or not
[11:11:24 CDT(-0500)] <michelled> yura_: does it matter where I call init dependents in that case?
[11:11:26 CDT(-0500)] <mlam> colinclark: making sense ^^
[11:11:32 CDT(-0500)] <colinclark> Now, looking at each of those grades, it's the fluid.modelComponent grade that is most important for this error
[11:11:39 CDT(-0500)] <yura_> michelled: no you can call them any time just like before
[11:11:46 CDT(-0500)] <yura_> the whole point is that it doesnt matter anymore
[11:11:51 CDT(-0500)] <michelled> ok thanks
[11:11:53 CDT(-0500)] <colinclark> A model component is a component that 1) has a model, and 2) has a ChangeApplier
[11:12:10 CDT(-0500)] <yura_> michelled: as long i guess as the event doesnt fire before initDependents
[11:12:22 CDT(-0500)] <michelled> ah, makes sense
[11:12:33 CDT(-0500)] <yura_> michelled: my personal collectionspace ui branch record_list has it in use
[11:12:36 CDT(-0500)] <yura_> listEditor.js
[11:12:49 CDT(-0500)] <colinclark> The change that broke our code was when Antranig fully introduced support for model components two revision ago
[11:13:00 CDT(-0500)] <colinclark> Which means that, by nature of being a View, we're also a Model component
[11:13:06 CDT(-0500)] <colinclark> And so we'll get a ChangeApplier for free
[11:13:16 CDT(-0500)] <colinclark> if our code was factored better, we'd be delighted by getting it for free
[11:13:22 CDT(-0500)] <colinclark> but in our case we weren't linking the correct file
[11:13:26 CDT(-0500)] <colinclark> and it was causing the error
[11:13:49 CDT(-0500)] <colinclark> make some sense/
[11:13:50 CDT(-0500)] <colinclark> ?
[11:13:54 CDT(-0500)] <mlam> ahhh cool, thanks for going through that with me. it was actually really really helpful
[11:14:07 CDT(-0500)] <colinclark> no problem
[11:14:12 CDT(-0500)] <colinclark> this stuff is, as you can tell, hot off the press
[11:14:23 CDT(-0500)] <colinclark> so it helps me to read the source code and try to ensure I understand it, too
[11:14:24 CDT(-0500)] <colinclark>
[11:14:37 CDT(-0500)] <colinclark> Let me commit your fix, and then let's go through the other issue in the same way
[11:14:42 CDT(-0500)] <colinclark> it may be more difficult
[11:16:46 CDT(-0500)] <colinclark> I guess one of the key differences between grades and interfaces is that they involve actual implementation
[11:17:06 CDT(-0500)] <colinclark> so it's not inheritance--we're not inheriting from some abstract grade base class, since these are being composed
[11:17:17 CDT(-0500)] <colinclark> but an interface would involve us having to implement code to conform to it
[11:17:32 CDT(-0500)] <colinclark> this is more like a mixin if you're familiar with the concept from other programming languages
[11:17:55 CDT(-0500)] <colinclark> in that some functionality is being added into our object for us, but outside of any inheritance relationship (which is a good thing)
[11:18:06 CDT(-0500)] <colinclark> any of these analogies aren't quite right, so don't take them too far
[11:18:07 CDT(-0500)] <mlam> right
[11:18:14 CDT(-0500)] <colinclark> but it at least helps to compare them to concepts we're all familiar with
[11:18:22 CDT(-0500)] <mlam> yes, definitely
[11:21:51 CDT(-0500)] <colinclark> mlam: So I'm starting to trace back the FileQueueView test failure
[11:21:58 CDT(-0500)] <colinclark> and you're right, it's failing inside Progress.js
[11:22:11 CDT(-0500)] <colinclark> So the first thing is to trace it back up to a point near the top
[11:22:48 CDT(-0500)] <colinclark> And I can see from the stack trace that the error is occurring inside the fileQueueView when we're instantiating the progress bar for a file
[11:22:57 CDT(-0500)] <colinclark> Line 195 on FileQueueView.js
[11:23:14 CDT(-0500)] <colinclark> So, the question is, why?
[11:23:40 CDT(-0500)] <colinclark> I'm going to stick a breakpoint there and explore a bit of the instantiation process for a Progress bar
[11:24:45 CDT(-0500)] <colinclark> The other thing that's interesting is that Progress' tests are all failing, too
[11:24:50 CDT(-0500)] <colinclark> Which actually simplifies things a lot for us
[11:25:03 CDT(-0500)] <colinclark> We know now that this error is not Uploader's fault
[11:25:13 CDT(-0500)] <colinclark> In other words, it occurs in isolation, too
[11:28:13 CDT(-0500)] <colinclark> So, mostly, my process is in debugging is pretty ad-hoc
[11:28:29 CDT(-0500)] <colinclark> I'm sticking a breakpoint at the point where we instantiate a Progress component, and then diving in
[11:28:38 CDT(-0500)] <colinclark> into fluid.initView()
[11:28:49 CDT(-0500)] <colinclark> into fluid.initLittleComponent
[11:29:08 CDT(-0500)] <colinclark> but I know to go deeper by simply stepping through code and watching the state of things and waiting for the error to actually occur
[11:29:21 CDT(-0500)] <colinclark> So I was able to see right away that inside fluid.Progress(), the error was happening inside fluid.initView()
[11:29:38 CDT(-0500)] <colinclark> and then, next, realizing that the error was happening somewhere inside fluid.initLittleComponent()
[11:29:52 CDT(-0500)] <colinclark> now I'm to the point where I can see the error is occurring sometime during options merging
[11:30:33 CDT(-0500)] <colinclark> In other words, the call to fluid.mergeComponentOptions() inside fluid.initLittleComponent() is failing
[11:30:50 CDT(-0500)] <mlam> yes
[11:33:24 CDT(-0500)] <colinclark> ...now into fluid.expandComponentOptions()
[11:33:34 CDT(-0500)] <colinclark> We're getting right into the guts of the options merging process
[11:39:32 CDT(-0500)] <colinclark> Okay, so I accidentally uncovered half the problem
[11:39:57 CDT(-0500)] <colinclark> The Progress tests suffer from the same problem as HTML5 tests did
[11:40:06 CDT(-0500)] <colinclark> they don't include DataBinding.js, despite being a View
[11:40:20 CDT(-0500)] <colinclark> If I had to guess, the Progress demo has the same problem
[11:40:47 CDT(-0500)] <colinclark> yep
[11:41:27 CDT(-0500)] <mlam> pretty juicy stuff. it was good to follow the process
[11:41:44 CDT(-0500)] <colinclark> Interestingly, we still have a problem
[11:41:55 CDT(-0500)] <colinclark> There's something about the fact that Progress has this viewComponent grade
[11:42:10 CDT(-0500)] <colinclark> Check Progress' options at line 251 of Progress.js
[11:42:23 CDT(-0500)] <colinclark> you'll see that, at some point, Progress was given a grade of View Component
[11:42:27 CDT(-0500)] <colinclark> which makes sense, since it is
[11:42:51 CDT(-0500)] <colinclark> but, it looks to me like, when Progress is instantiated via IoC (as we do for the total progress bar in Uploader), it succeeds
[11:43:01 CDT(-0500)] <colinclark> but when calling fluid.Progress() directly, things are exploding
[11:43:04 CDT(-0500)] <colinclark> I'm not quite clear why yet
[11:45:59 CDT(-0500)] <colinclark> I guess I'm starting to see how yura_ feels, with the earth constantly moving below his feet
[11:46:11 CDT(-0500)] <colinclark> Although, I guess, it's yura_ who asks for the earth to move in the first place
[11:47:36 CDT(-0500)] <yura_> colinclark: i guess so
[11:48:13 CDT(-0500)] <colinclark> Any guesses on what would make a perfectly ordinary component suddenly refuse to merge its options properly when not being invoked via IoC, yura_?
[11:48:22 CDT(-0500)] <mlam> hahaha
[11:49:12 CDT(-0500)] <yura_> colinclark: maybe something to do with grades?
[11:49:22 CDT(-0500)] <yura_> as a wild guess
[11:49:22 CDT(-0500)] <colinclark> yes, definitely that
[11:49:33 CDT(-0500)] <colinclark> yura_: The component has a grade of fluid.viewComponent
[11:49:40 CDT(-0500)] <colinclark> when I remove this grade, happiness
[11:49:57 CDT(-0500)] <colinclark> but of course, removing the grade will presumably cause unhappiness in cases where we were instantiating it via IoC
[11:50:59 CDT(-0500)] <yura_> do the options correspond to the argument map of view component?
[11:51:03 CDT(-0500)] <yura_> colinclark: ^
[11:51:11 CDT(-0500)] <colinclark> good question
[11:51:19 CDT(-0500)] <colinclark> yes, they do
[12:40:18 CDT(-0500)] <Bosmon2> mlam, colinclark: Sorry to break the tests
[12:40:25 CDT(-0500)] <colinclark> Ah, you've arrived
[12:40:34 CDT(-0500)] <colinclark> I was seconds away from going for lunch
[12:40:36 CDT(-0500)] <Bosmon2> Somehow it didn't occur to me that the FLUID-4165 fix could break anything elsewhere, since it was a fix primarily to rendererComponent
[12:40:38 CDT(-0500)] <colinclark> but I'll stay and we can chat
[12:40:41 CDT(-0500)] <Bosmon2> I will fix it up now
[12:40:45 CDT(-0500)] <colinclark> So, I guess there are two things
[12:41:07 CDT(-0500)] <colinclark> We introduced the requirement for all View components to link to DataBinding.js
[12:41:08 CDT(-0500)] <colinclark> which seems fine
[12:41:30 CDT(-0500)] <colinclark> Do you know what the problem with Progress is? It's clearly happening deep within the options expansion machinery
[12:42:00 CDT(-0500)] <Bosmon2> I can't imagine what it is, but I will know very soon...
[12:42:02 CDT(-0500)] <colinclark> And, I guess my last question-or comment-is that this sort of dovetails in an intriguing way with mlam's mission to write comprehensive integration tests for Uploader
[12:42:06 CDT(-0500)] <colinclark> I was mulling it over this morning
[12:42:12 CDT(-0500)] <colinclark> But this seems to be a category of problems
[12:42:23 CDT(-0500)] <colinclark> a component instantiated on its own vs. via IoC
[12:42:38 CDT(-0500)] <colinclark> And I guess it raises the question "should a component's own tests cover that?"
[12:42:55 CDT(-0500)] <colinclark> I've looked over your test code in the Uploader demo
[12:43:10 CDT(-0500)] <colinclark> and there's a part of me that wonders why Uploader itself should be testing these variations at all
[12:43:24 CDT(-0500)] <colinclark> I mean, I get the pragmatic reason, specific to the Uploader
[12:43:38 CDT(-0500)] <Bosmon2> Well, "in theory" this could be covered by yet more tests covering the framework itself
[12:43:47 CDT(-0500)] <colinclark> yeah
[12:43:58 CDT(-0500)] <colinclark> in the big picture, this is something all components are subject to
[12:44:11 CDT(-0500)] <Bosmon2> But it would be hard to tell "what particularly" about the Uploader, a particularly complex piece of IoC-driven machinery, is being exercised by any test case failing to cover all of it
[12:45:06 CDT(-0500)] <colinclark> But I guess the point we're seeing here is that, in absence of "theoretical tests," every component now needs to, for itself, be tested in various IoC and non-IoC configurations
[12:45:43 CDT(-0500)] <Bosmon2> Well, I guess we just need "even more theoretical tests"
[12:45:44 CDT(-0500)] <colinclark> Which I find slightly unsettling, if clearly useful
[12:45:53 CDT(-0500)] <colinclark> ok
[12:46:02 CDT(-0500)] <Bosmon2> I will add some now to prevent this particular regression
[12:46:08 CDT(-0500)] <colinclark> So Uploader, due to its complexity and status, should implement these sorts of tests itself
[12:46:23 CDT(-0500)] <colinclark> and in the long run we will hope for greater framework-level coverage to benefit other components
[12:46:57 CDT(-0500)] <colinclark> After the dev meeting, I'll walk mlam through recreating your demo tests as unit tests for Uploader
[12:47:06 CDT(-0500)] <colinclark> I really had to struggle through that code
[12:47:28 CDT(-0500)] <colinclark> it's the sort of stuff we'll never expect newcomers to be able to handle
[12:47:52 CDT(-0500)] <colinclark> if anything, it's an active repellent to IoC
[12:48:05 CDT(-0500)] <colinclark> "That stuff's great in theory, but it's so complex, why would I bother?"
[12:48:07 CDT(-0500)] <colinclark> that sort of thing
[12:48:13 CDT(-0500)] <Bosmon2> Yes
[12:48:15 CDT(-0500)] <Bosmon2> That sort of thing
[12:48:35 CDT(-0500)] <Bosmon2> But perhaps, test cases are, and should be, some of the MORE complex code we have to write
[12:49:28 CDT(-0500)] <colinclark> I'm okay with that
[12:52:21 CDT(-0500)] <colinclark> But I guess the thing you and I need to remember...
[12:52:37 CDT(-0500)] <colinclark> is that there are currently three people in the universe who could actually write such unit tests in short order
[12:52:42 CDT(-0500)] <colinclark>
[12:52:53 CDT(-0500)] <colinclark> Maybe only two, I just like to flatter myself
[12:56:24 CDT(-0500)] <Bosmon2> "And one of them has just forgotten"
[12:57:03 CDT(-0500)] <Bosmon2> You remember the story about the student at his final interview, where his examiners put him the final question.... "What is electricity?"
[12:57:17 CDT(-0500)] <Bosmon2> He replies... "I'm sorry... I used to know, but I seem to have forgotten"
[12:57:39 CDT(-0500)] <colinclark> lol
[12:57:46 CDT(-0500)] <colinclark> I must have forgotten that one
[12:58:14 CDT(-0500)] <colinclark> okay, i'm going to grab a samwich and will be back shortly
[12:58:24 CDT(-0500)] * colinclark 's sandwich
[12:58:31 CDT(-0500)] <Bosmon2> The examiner turns round to his colleagues and says... "Gentlemen! This is an extremely sad day! Since... as of yesterday, there were just three men in the world who understood what electricity is.... and now, it seems, that one of them, has FORGOTTEN!"
[12:58:39 CDT(-0500)] <colinclark>
[13:00:50 CDT(-0500)] <Bosmon2> I guess it feels like there are a lot of IoC tests, but I guess, numerically, really there aren't
[13:01:03 CDT(-0500)] <Bosmon2> The test file is only 100 lines longer than the implementation file
[13:01:12 CDT(-0500)] <Bosmon2> Whereas I guess, as a ballpark guide, it should really be about 3x as long
[13:40:13 CDT(-0500)] <michelled> fluid-everyone: is there anyone how wants to join the dev meeting through skype?
[13:41:03 CDT(-0500)] <michelled> Avipar, pulkit: everyone is invited to the dev meeting if you are interested in joinging
[13:41:08 CDT(-0500)] <michelled> joining
[13:41:41 CDT(-0500)] <Avipar> aah sure
[13:41:42 CDT(-0500)] <Avipar>
[13:41:50 CDT(-0500)] <Avipar> dev meeting
[13:42:09 CDT(-0500)] <michelled> you can send me your skype name privately and I'll add you
[15:09:25 CDT(-0500)] <Bosmon2> colinclark, Justin_o, all
[15:09:33 CDT(-0500)] <colinclark> yes?
[15:09:34 CDT(-0500)] <Bosmon2> So I committed a small change to qunit just now
[15:09:44 CDT(-0500)] <Bosmon2> Along with my fix for the breakage of most of Uploader
[15:10:06 CDT(-0500)] <Bosmon2> Which gets around an issue I have frequently found extremely annoying... that a call to "expect" is not cumulative
[15:10:19 CDT(-0500)] <Bosmon2> Somehow you have to apprehend up front the total number of test cases a function is going to issue
[15:10:25 CDT(-0500)] <Bosmon2> Which makes it very hard to write them in composable units
[15:12:57 CDT(-0500)] <Justin_o> Bosmon2: i think this should have gone into jqunit
[15:14:16 CDT(-0500)] <Bosmon2> Justin_o: in what way?
[15:14:54 CDT(-0500)] <Justin_o> well.. when we update qunit again you'll lose your new feature
[15:14:57 CDT(-0500)] <Bosmon2> It could have gone into jqunit, if we decided to "deprecate" the use of the unnamespaced functions that qunit makes
[15:15:15 CDT(-0500)] <Bosmon2> I actually made a namespaced pass-through for expect()
[15:15:19 CDT(-0500)] <Justin_o> Bosmon2: we could start using jqunit.expect
[15:15:22 CDT(-0500)] <colinclark> Can we put it into a jqUnit.expect()?
[15:15:24 CDT(-0500)] <Bosmon2> But thought it would be too much to patch everything
[15:15:32 CDT(-0500)] <Bosmon2> Yes, I made a jQunit.expect()
[15:15:37 CDT(-0500)] <colinclark> ah, great
[15:15:42 CDT(-0500)] <Bosmon2> If we agree to deprecate the use of the unnamed functions, we can move the implementation
[15:15:46 CDT(-0500)] <colinclark> I think we should just deprecate use of expect()
[15:15:47 CDT(-0500)] <colinclark> yes
[15:15:49 CDT(-0500)] <colinclark> +1
[15:15:52 CDT(-0500)] <Bosmon2> cool
[15:15:58 CDT(-0500)] <colinclark> For the record, I was thinking this weekend just how useless expect() is for exactly the reason you state
[15:16:00 CDT(-0500)] <Justin_o> i'm +1 for not using expect anymore
[15:16:14 CDT(-0500)] <colinclark> I mean, I'm probably writing a whack of tests. How could I possibly know up front how many there will be?
[15:16:20 CDT(-0500)] <colinclark> Or, alternatively, I'm adding new tests
[15:16:23 CDT(-0500)] <colinclark> Same question
[15:16:41 CDT(-0500)] <Justin_o> colinclark: i think it's really useful for testing if a an event occurs or something like that
[15:16:49 CDT(-0500)] <Justin_o> where the test just may not happen if there is a problem
[15:16:53 CDT(-0500)] <colinclark> right
[15:17:00 CDT(-0500)] <colinclark> i agree with that
[15:17:22 CDT(-0500)] <Justin_o> i don't really think its that useful when you know all the tests will run
[15:17:40 CDT(-0500)] <Justin_o> I don't think we need to use it then, sometimes it just becomes a burden to keep up to date
[15:18:09 CDT(-0500)] <Bosmon2> Justin_o: I think we are all agreeing that it continues to be useful
[15:18:15 CDT(-0500)] <Bosmon2> it is made more useful by being cumulative
[15:20:59 CDT(-0500)] <colinclark> yes
[15:21:06 CDT(-0500)] <Bosmon2> So, yura_ is just discussing with me an issue which sheds some interesting light on the issue of... "should we code with giant renderer trees, or with IoC trees"
[15:21:18 CDT(-0500)] <colinclark> The latter!
[15:21:41 CDT(-0500)] <colinclark> Bosmon2, mlam: Do you have a few minutes to chat about Uploader testing here in the channel?
[15:21:45 CDT(-0500)] <Bosmon2> That's a most unsocratic remark
[15:21:49 CDT(-0500)] <colinclark> lol
[15:21:54 CDT(-0500)] <Bosmon2> Sure, yes
[15:21:55 CDT(-0500)] <mlam> sure
[15:21:59 CDT(-0500)] <colinclark> Once you're done with yura, maybe, Bosmon2?
[15:23:11 CDT(-0500)] <Bosmon2> Well, let's talk Uploader first
[15:23:15 CDT(-0500)] <colinclark> ok
[15:23:23 CDT(-0500)] <colinclark> mlam: Bosmon2 and I were chatting earlier about it
[15:23:35 CDT(-0500)] <mlam> ok
[15:23:42 CDT(-0500)] <colinclark> and I pointed out that there are probably two people on this planet who could reasonably decipher the Uploader demo
[15:23:51 CDT(-0500)] <Bosmon2> "demo"
[15:23:53 CDT(-0500)] <colinclark>
[15:24:11 CDT(-0500)] <colinclark> So, let's maybe walk through it and see if we can figure out how we'd turn that stuff into your unit tests
[15:24:21 CDT(-0500)] <colinclark> and how much coverage we'll want
[15:24:44 CDT(-0500)] <colinclark> I was also arguing that In The Future, we hopefully won't have to write these kinds of tests on a per component basis
[15:24:58 CDT(-0500)] <colinclark> lemme just dig up a link
[15:25:15 CDT(-0500)] <Bosmon2> Hopefully not, no
[15:25:24 CDT(-0500)] <colinclark> Okay, so this is the file: https://github.com/fluid-project/infusion/blob/master/src/webapp/demos/uploader/js/uploader.js
[15:25:27 CDT(-0500)] <Bosmon2> Once we have 5000 lines of test cases for FluidIoC, it should no longer be necessary
[15:25:40 CDT(-0500)] <colinclark> So, we can probably just start by skimming it to see what it does
[15:25:45 CDT(-0500)] <colinclark> since all the details are pretty complex
[15:25:53 CDT(-0500)] <colinclark> I see three things...
[15:25:55 CDT(-0500)] <colinclark> three buttons
[15:26:12 CDT(-0500)] <colinclark> In the HTML: https://github.com/fluid-project/infusion/blob/master/src/webapp/demos/uploader/html/uploader.html
[15:26:23 CDT(-0500)] <colinclark> 1. "Concrete Uploader"
[15:26:29 CDT(-0500)] <colinclark> 2. "IoC-driven Uploader"
[15:26:37 CDT(-0500)] <colinclark> 3. "IoC-driven Uploader with demands"
[15:26:49 CDT(-0500)] <colinclark> These represent three different ways in which someone might instantiate an Uploader
[15:27:09 CDT(-0500)] <colinclark> Case #1 being a plain old function call, like, "fluid.uploader(container, options)"
[15:27:18 CDT(-0500)] <colinclark> Case #2 being how yura_ uses the Uploader
[15:27:33 CDT(-0500)] <colinclark> In other words, the Uploader a subcomponent for one of his components
[15:27:41 CDT(-0500)] <colinclark> meaning he's got a demands block somewhere for it
[15:27:48 CDT(-0500)] <colinclark> Is that about right, Bosmon2?
[15:28:09 CDT(-0500)] <Bosmon2> Yes
[15:28:20 CDT(-0500)] <colinclark> I guess case #3 is the one with the demands block
[15:28:29 CDT(-0500)] <colinclark> Case #2 is no demands block, but configured as a subcomponent
[15:28:31 CDT(-0500)] &