fluid-tech IRC Logs-2013-07-17
[09:56:27 CDT(-0500)] <yzen> kasparnet: what's up?
[09:58:46 CDT(-0500)] <kasparnet> yzen: so I'm looking to move my integration test work to use the proper IOC testing framework
[09:59:08 CDT(-0500)] <yzen> kasparnet: nice
[09:59:14 CDT(-0500)] <kasparnet> yzen: bosmon gave me this nice documentation link: http://wiki.fluidproject.org/display/docs/The+IoC+Testing+Framework
[09:59:29 CDT(-0500)] <kasparnet> but I'm running into some issues
[09:59:35 CDT(-0500)] <kasparnet> https://github.com/kaspermarkus/linux/blob/GPII-20/tests/integrationTesting.js
[09:59:44 CDT(-0500)] <kasparnet> I've cut down everything to the minimum
[10:00:22 CDT(-0500)] <kasparnet> just getting a single function call to work
[10:00:34 CDT(-0500)] <yzen> kasparnet: you need to actually execute the tests
[10:01:10 CDT(-0500)] <kasparnet> WHAT? I though the testing framework was gonna do all the work for me
[10:01:23 CDT(-0500)] <yzen> kasparnet: look at the sort of working tests that i m still in process of rewriting for data source here
[10:01:24 CDT(-0500)] <yzen> https://github.com/yzen/kettle/blob/GPII-116/test/DataSourceTests.js
[10:02:54 CDT(-0500)] <kasparnet> yzen: oooh, thanks
[10:03:01 CDT(-0500)] <kasparnet> so basically I need a bastard like this: https://github.com/yzen/kettle/blob/GPII-116/test/DataSourceTests.js#L284-L287
[10:03:40 CDT(-0500)] <colinclark> zomg, so complex, kasparnet
[10:03:41 CDT(-0500)] <yzen> kasparnet: yes that bastard
[10:04:38 CDT(-0500)] <kasparnet> colinclark: hehe, damn you
[10:04:50 CDT(-0500)] <kasparnet> colinclark: you made it back to the top of my kill list
[10:04:57 CDT(-0500)] <colinclark>
[10:05:12 CDT(-0500)] <colinclark> yzen: One sarcastic comment, that's all it takes
[10:07:37 CDT(-0500)] <colinclark> kasparnet: It's actually quite amazing that I've managed to stay on top of that list
[10:07:58 CDT(-0500)] <colinclark> given our current state of Android development affairs
[10:09:33 CDT(-0500)] <kasparnet> colinclark: hahaha, true
[10:20:57 CDT(-0500)] <kasparnet> yzen: ok, getting an overflow/circularity in options merging, blabla error
[10:21:41 CDT(-0500)] <kasparnet> yzen: ah, nvm... found it
[10:21:56 CDT(-0500)] <yzen>
[10:28:28 CDT(-0500)] <colinclark> kasparnet and yzen, there's a doodle poll from Keith Hazelton
[10:28:36 CDT(-0500)] <colinclark> since I'm famous for forgetting to fill these out
[10:34:32 CDT(-0500)] <kasparnet> yzen: here: https://github.com/yzen/kettle/blob/GPII-116/test/DataSourceTests.js#L147 you have "modules" and the documentation has "testCases"
[10:34:36 CDT(-0500)] <kasparnet> which is correct
[10:34:49 CDT(-0500)] <kasparnet> (I'm still not having my damn function called)
[10:35:01 CDT(-0500)] <kasparnet> "which is correct" should have a question mark after it
[10:45:13 CDT(-0500)] <kasparnet> colinclark: did we ever get any source from bdigital
[10:46:41 CDT(-0500)] <colinclark> Unless you consider a .rar file and .war file "source," no.
[10:46:42 CDT(-0500)] <colinclark> https://github.com/marcelbdigital/Security-Gateway--OAuth-
[10:47:00 CDT(-0500)] <colinclark> A war file and a rar file are essentially both like a zip...
[10:47:04 CDT(-0500)] <colinclark> an binary archive
[10:47:14 CDT(-0500)] <colinclark> In this case, with the pull request comment
[10:47:16 CDT(-0500)] <colinclark> "source code"
[10:48:22 CDT(-0500)] <kasparnet> do you know you have a meeting with bdigital tomorrow, colin?
[10:48:27 CDT(-0500)] <kasparnet> colinclark: ^
[10:48:43 CDT(-0500)] <colinclark> kasparnet: I'm getting an echo
[10:48:44 CDT(-0500)] <colinclark>
[10:48:50 CDT(-0500)] <kasparnet> haha, yeah, gregg just told me
[11:05:39 CDT(-0500)] <clown> kasparnet, colinclark, is there a cloud4all meeting now? "GoToMeeting" is telling me "Waiting for an organizer to arrive…"
[11:05:50 CDT(-0500)] <colinclark> yes, sorry
[11:05:54 CDT(-0500)] <colinclark> we're in another meeting at the moment
[11:05:59 CDT(-0500)] <kasparnet> argh crap
[11:06:02 CDT(-0500)] <colinclark> so the meeting will be a bit delayed
[11:06:05 CDT(-0500)] <clown> foobar!
[11:06:06 CDT(-0500)] <kasparnet> I'll open the channel in a bit
[11:06:14 CDT(-0500)] * clown just getting into the spriit of thing.
[11:06:19 CDT(-0500)] * clown *things
[11:06:34 CDT(-0500)] <colinclark> jessm is going to start the architecture call
[11:06:38 CDT(-0500)] <clown> Okay, kasparnet, let me know. I'll be on standby.
[11:06:41 CDT(-0500)] <colinclark> you guys know the drill
[11:07:37 CDT(-0500)] <clown> one other thing: GoToMeeting says the subject is "Access4All". Is that correct, kasparnet?
[11:07:54 CDT(-0500)] <clown> never mind, connected...
[11:22:38 CDT(-0500)] <yzen> Bosmon: speaking of core uio in what cases can the target be undefined in that new function you added for 5091?
[11:25:23 CDT(-0500)] <Bosmon> yzen - it is the "mouse droppings" system that runs the "ginger world"
[11:25:48 CDT(-0500)] <Bosmon> That uses "any value" at a point in the structure as a representation of "this value has been evaluated"
[11:26:24 CDT(-0500)] <Bosmon> There is a JIRA http://issues.fluidproject.org/browse/FLUID-4930 which explains how inadequate this system is
[11:26:32 CDT(-0500)] <Bosmon> But it is the one we have for now
[11:27:17 CDT(-0500)] <Bosmon> So the target will be observed to be "undefined" in the case there has already been an attempt to evaluate the "components" member of the overall options, by the point the dynamic grades have been valuated
[11:27:20 CDT(-0500)] <yzen> Bosmon: as soon as i applied your branch in mine, i got an error in cases when target is undefined, that's why I'm asking
[11:27:20 CDT(-0500)] <Bosmon> evaluated
[11:27:58 CDT(-0500)] <Bosmon> yzen - that can't be true in general, since target is undefined in the test case you supplied
[11:28:05 CDT(-0500)] <Bosmon> So there must be some other criteria required for the error
[11:28:25 CDT(-0500)] <Bosmon> Can you tell me what cases you are getting the error in?
[11:28:30 CDT(-0500)] <Bosmon> Since all the test cases seemed to pass for me
[11:34:22 CDT(-0500)] <yzen> yes one sec
[11:34:23 CDT(-0500)] <yzen> well no it's not the test case that's failing
[11:34:23 CDT(-0500)] <yzen> it's in the builder for uio
[11:34:35 CDT(-0500)] <Bosmon> yzen - ok
[11:34:40 CDT(-0500)] <Bosmon> You may have to construct another test case
[11:35:05 CDT(-0500)] <Bosmon> http://cdn.meme.li/instances/300x300/39447157.jpg
[11:35:13 CDT(-0500)] <Bosmon> Just to get ahead of you
[11:36:42 CDT(-0500)] <yzen> lol
[11:37:16 CDT(-0500)] <yzen> i tried
[11:37:16 CDT(-0500)] <yzen> wel trying
[11:37:16 CDT(-0500)] <yzen> and failing
[11:43:34 CDT(-0500)] <yzen> so Bosmon, the way it fails in uio builder is on line 403 of data binding: delete pen.root[last]; where pen.root is undefined
[11:44:19 CDT(-0500)] <Bosmon> yzen - I guess the only way that could occur is that the overal root value of "options" has an undefined value?@
[11:44:25 CDT(-0500)] <Bosmon> That seems implausible
[11:44:29 CDT(-0500)] <Bosmon> Can you tell more about the situation?
[11:46:40 CDT(-0500)] <yzen> sure
[11:49:55 CDT(-0500)] <yzen> Bosmon: what exactly do you want to know?
[11:50:24 CDT(-0500)] <Bosmon> yzen - what is actually in the "target" block at the point the deletion occurs
[11:52:42 CDT(-0500)] <yzen> Bosmon: here's a paste of the failing https://etherpad.mozilla.org/EgJ1LJzT7V
[11:53:23 CDT(-0500)] <yzen> failing mergeBlocks block
[11:54:19 CDT(-0500)] <Bosmon> yzen - ok
[11:54:28 CDT(-0500)] <Bosmon> Do carry on trying to construct a test case
[11:54:58 CDT(-0500)] <yzen> Bosmon: any thoughts?
[11:55:20 CDT(-0500)] <yzen> hah
[11:57:01 CDT(-0500)] <Bosmon> yzen - none
[11:57:09 CDT(-0500)] <Bosmon> But do tell me what is inside the mergeBlock which causes the failure
[11:59:17 CDT(-0500)] <yzen> that link above ^
[12:00:36 CDT(-0500)] <Bosmon> yzen - couldn't see any mergeBlocks in there
[12:01:46 CDT(-0500)] <yzen> it's the one with target undefined
[12:04:07 CDT(-0500)] <Bosmon> yzen - can't see the text "undefined" anywhere in that pad
[12:05:59 CDT(-0500)] <yzen> oh i wonder if stringily got rid of it
[12:06:22 CDT(-0500)] <yzen> essentially target is undefined for that blcok
[12:06:22 CDT(-0500)] <yzen> block
[12:06:50 CDT(-0500)] <Bosmon> yzen - and what type of block is it?
[12:07:07 CDT(-0500)] <Bosmon> It would seem that "target" could only be undefined if "source" was undefined too
[12:07:19 CDT(-0500)] <Bosmon> Which seems peculiar, since this is a condition that doesn't arise in any other case in the framework
[12:08:20 CDT(-0500)] <yzen> ok one sec
[12:12:23 CDT(-0500)] <yzen> Bosmon: yes no target no source
[12:12:50 CDT(-0500)] <yzen> well target is undefined, source not in the mergeblock
[12:13:31 CDT(-0500)] <Bosmon> yzen - ok, so what is the type of the block
[12:13:36 CDT(-0500)] <Bosmon> And.... why does it have no source!
[12:15:22 CDT(-0500)] <yzen> Bosmon: recordType defaults, context that points to fatPanel
[12:15:45 CDT(-0500)] <yzen> this is during the uiEnhancer resolution
[12:16:00 CDT(-0500)] <Bosmon> Aha
[12:16:07 CDT(-0500)] <Bosmon> You have a component which has no defaults?
[12:23:42 CDT(-0500)] <kasparnet> Bosmon: Since I so managed to totally not attend the arch. meeting, should we have a chat about integration testing?
[12:24:46 CDT(-0500)] <kasparnet> yzen: here: https://github.com/yzen/kettle/blob/GPII-116/test/DataSourceTests.js#L147 you have "modules" and the documentation has "testCases" – which is correct? (I'm still not getting a call to my damned function)
[12:25:29 CDT(-0500)] <Bosmon> kasparnet - "modules" is correct
[12:25:40 CDT(-0500)] <Bosmon> Clearly the code is always correct
[12:26:21 CDT(-0500)] <kasparnet> Bosmon: hehe true ... but wasn't sure whether yura's code was still in sketch state
[12:26:35 CDT(-0500)] <Bosmon> Well you can always look at the framework test cases I pointed you to
[12:26:48 CDT(-0500)] <yzen> kasparnet: never
[12:27:47 CDT(-0500)] <yzen> kasparnet: i think modules is the right one here, you can try running my tests too if you don't believe me
[12:27:47 CDT(-0500)] <yzen>
[12:28:14 CDT(-0500)] <kasparnet> Bosmon: ah thanks – didn't see it till now – was hiding in a tab on safari!!! Things have a tendency of getting lost there
[12:28:27 CDT(-0500)] <Bosmon> THis is why I never use tabs
[12:28:31 CDT(-0500)] <Bosmon> But merely 120 top-level windows........
[13:03:01 CDT(-0500)] <colinclark> kasparnet, yzen, Bosmon: Hiya!
[13:03:22 CDT(-0500)] <colinclark> So, I'm thinking we've got some code review ahead of us
[13:03:31 CDT(-0500)] <colinclark> exciting code, fortunately
[13:04:18 CDT(-0500)] <colinclark> yzen: I'm hoping you might be able to spend some time on the pull requests for universal and prefsEditors
[13:04:38 CDT(-0500)] <colinclark> Particularly this one: https://github.com/GPII/universal/pull/125
[13:05:09 CDT(-0500)] <colinclark> and this one: https://github.com/GPII/prefsEditors/pull/2
[13:05:18 CDT(-0500)] <colinclark> The second one will probably require some time, attention, and explanation
[13:05:26 CDT(-0500)] <colinclark> since there's some pretty unusual stuff in it
[13:05:41 CDT(-0500)] <colinclark> but I think you're really well equipped to explain alternative ways of accomplishing the functinonality
[13:05:54 CDT(-0500)] <colinclark> and you're deeply familiar with the new UIO work being done
[13:06:22 CDT(-0500)] <colinclark> kasparnet and Bosmon: This one is pretty exciting: https://github.com/GPII/android/pull/1
[13:06:31 CDT(-0500)] <colinclark> And I'm not sure who is best to review it
[13:07:19 CDT(-0500)] <colinclark> But I'm thinking you two might be
[13:07:37 CDT(-0500)] <colinclark> along with help from jhernandez, who I just realized is not in this channel
[13:20:40 CDT(-0500)] <yzen> colinclark: sounds good
[13:21:31 CDT(-0500)] <colinclark> yzen: When do you think you can look at it?
[13:21:36 CDT(-0500)] <colinclark> Not because I want to put pressure on it
[13:21:38 CDT(-0500)] <colinclark> just so I can plan
[13:22:13 CDT(-0500)] <yzen> colinclark: i think as soon as the uio schema stuff is stabilized
[13:22:24 CDT(-0500)] <colinclark> cool
[13:22:29 CDT(-0500)] <colinclark> that makes sense
[13:24:17 CDT(-0500)] <Bosmon> android-1 is definitely exciting!
[13:24:27 CDT(-0500)] <Bosmon> I guess my first question about is is why the "anode" stuff is not included as a JAR
[15:30:11 CDT(-0500)] <kasparnet> Bosmon:
[15:30:17 CDT(-0500)] <kasparnet> hello Dr.!
[15:30:35 CDT(-0500)] <Bosmon> KASSPARNETT!!
[15:30:39 CDT(-0500)] <Bosmon> Did you get your FUNCTION to execute now?
[15:30:47 CDT(-0500)] <kasparnet> WHAT?!?!?!?! No daaaamn you KASPAAAARRRRNETTT?
[15:30:56 CDT(-0500)] <Bosmon> yzen - did you discover why you had a component with empty defaults?
[15:30:56 CDT(-0500)] <kasparnet> this is the happiest day of my life
[15:31:03 CDT(-0500)] <Bosmon> You can only be DAMMNED so often
[15:31:10 CDT(-0500)] <Bosmon> We can take it as read for a few more encounters
[15:31:10 CDT(-0500)] <kasparnet> I did ... still no idea what was wrong before
[15:31:18 CDT(-0500)] <kasparnet> hehe
[15:31:30 CDT(-0500)] <kasparnet> Bosmon: now to the real questions
[15:31:37 CDT(-0500)] <kasparnet> which hopefully have simple answers
[15:31:51 CDT(-0500)] <Bosmon> Yes
[15:31:55 CDT(-0500)] <kasparnet> so, I imagine that we'll have a big JSON blob specifying the settings
[15:32:01 CDT(-0500)] <Bosmon> And hopefully answers which do not involve damning things
[15:32:20 CDT(-0500)] <kasparnet> basically, and array of objects, each object specifying the details of a test (expected settings, token, etc)
[15:33:26 CDT(-0500)] <kasparnet> so for each runthrough of a "sequence" in the testCaseHolder I want to pass a different object
[15:33:50 CDT(-0500)] <kasparnet> ... or at least loop through the sequence multiple times (I can keep track of a counter myself if needed)
[15:34:28 CDT(-0500)] <kasparnet> bosmon: am i making any sense
[15:34:31 CDT(-0500)] <Bosmon> kasparnet - you shouldn't do any running yourself
[15:34:33 CDT(-0500)] <Bosmon> Not entirely
[15:34:53 CDT(-0500)] <Bosmon> If you want multiple variants of test cases, you should use something like Model Transformations to generate fresh fixtures from the old oens
[15:35:49 CDT(-0500)] <kasparnet> but all the details will be specific to/depend on the token used to log in
[15:36:08 CDT(-0500)] <kasparnet> so the settings set, settingshandlers used, processes started, etc., will vary from testcase to testcase
[15:36:40 CDT(-0500)] <kasparnet> what I got right now is: https://github.com/kaspermarkus/linux/blob/9040434c1cc634f8f91b9e86dc12f9b340de2044/tests/integrationTesting.js#L16-L47
[15:37:01 CDT(-0500)] <kasparnet> which is everything that is to be expected under linux when logging in with the MikelVargas token
[15:37:04 CDT(-0500)] <Bosmon> kasparnet - yes
[15:37:09 CDT(-0500)] <Bosmon> This is the "scaling risk" that I highlighted
[15:37:22 CDT(-0500)] <Bosmon> Clearly you don't want to have to write a fresh block like this for every persona in the system
[15:37:23 CDT(-0500)] <kasparnet> .. but logging in with eg: carla, would give you a whole different set of settings and handlers
[15:37:41 CDT(-0500)] <Bosmon> It would take you FOREVER
[15:37:47 CDT(-0500)] <Bosmon> And not even KASPARNETT has FOREVER : P
[15:37:50 CDT(-0500)] <yzen> Bosmon: so we ended up finding that we were using a grade that's no longer appropriate for the uienhancer in the iframe
[15:38:01 CDT(-0500)] <Bosmon> Well of course, you will once you have wiped out all the rest of humanity
[15:38:07 CDT(-0500)] <Bosmon> yzen - so the problem went away once you removed it?
[15:38:07 CDT(-0500)] <kasparnet> Bosmon: I'm not planning on writing them... I'm planning on writing the framework and then lure some poor bastard into writing them
[15:38:15 CDT(-0500)] <yzen> yes
[15:38:25 CDT(-0500)] <yzen> but it's back if we try to pass the constructed grades
[15:38:25 CDT(-0500)] <Bosmon> kasparnet - it would be better should you write the framework to derive them automatically
[15:38:34 CDT(-0500)] <yzen> which is something we need to take a look at
[15:38:37 CDT(-0500)] <Bosmon> Thus depriving the poor bastard of his employment
[15:39:02 CDT(-0500)] <kasparnet> Bosmon: well – I can use the testwriting as an instrument of torture, when combatting the enemies (colinclark!!!) of KASPARNETT
[15:39:29 CDT(-0500)] <Bosmon> I think we will have more than enough implements of torture to go round
[15:39:45 CDT(-0500)] <Bosmon> Not to mention the INTERNAL INTEGRATION TESTS
[15:39:47 CDT(-0500)] <kasparnet> Bosmon: but now you're talking loco
[15:40:01 CDT(-0500)] <Bosmon> Which you will have to turn to after these EXTERNAL INTEGRATION TESTS
[15:40:24 CDT(-0500)] <Bosmon> But if you do these ones properly, you should be able to reuse a lot of the infrastructure
[15:40:27 CDT(-0500)] <kasparnet> what? internal integration tests? what is this madness now?
[15:40:52 CDT(-0500)] <Bosmon> The tests which actually verify at the level of the framework that it is doing what it is meant to be doing
[15:41:01 CDT(-0500)] <Bosmon> That is, on the level of the components of the architecture
[15:41:10 CDT(-0500)] <kasparnet> Bosmon: anyway - are you suggesting that I write some monster, that'll take a token, then look up solution registry, matchmaking process, transformations, etc., and then deduct all this stuff?
[15:41:31 CDT(-0500)] <colinclark> oh cool
[15:41:42 CDT(-0500)] <colinclark> I'm going to get tortured with nice declarative testing frameworks!
[15:41:50 CDT(-0500)] <kasparnet> haha
[15:41:51 CDT(-0500)] <colinclark> are you sure it's torture?
[15:41:56 CDT(-0500)] <colinclark> it sounds kind of hot
[15:42:04 CDT(-0500)] <colinclark>
[15:42:05 CDT(-0500)] <Bosmon> kasparnet - yet - at the very least, starting at the level of the records in the preferencesServer
[15:42:26 CDT(-0500)] <Bosmon> For example, given the correct record, you could easily deduce 90% of the stuff that is hilighted in yellow that you just pasted me
[15:42:36 CDT(-0500)] <kasparnet> colinclark: well, not if you're gonna enjoy it!!! So skip that – I'll charge you with reimplementing the core architecture in different technologies
[15:42:53 CDT(-0500)] <Bosmon> Yes, I vote that it is all reimplemented in "Ruby on Rails"
[15:42:58 CDT(-0500)] <colinclark> lol
[15:43:08 CDT(-0500)] <Bosmon> I hear that that is very common in Southern Europe these days
[15:44:06 CDT(-0500)] <Bosmon> kasparnet - clearly some of the other results of the system will be harder to deduce - but you can centralise those in some other JSON blobs that someone will have to write
[15:44:16 CDT(-0500)] <Bosmon> But things which are clearly deducible from the preferences record, should be done so
[15:45:01 CDT(-0500)] <Bosmon> But in fact, if we had good test cases for the other elements of the architecture, we could use those to help in the deduction
[15:45:13 CDT(-0500)] <Bosmon> For example, every settings handler should have such a "test case deriver" associated with it
[15:45:20 CDT(-0500)] <Bosmon> If THEY HAD ANY UNIT TESTS AT ALL
[15:45:26 CDT(-0500)] <Bosmon> IF THEY DID!!!!
[15:45:36 CDT(-0500)] <kasparnet> HEY! I wrote unit tests to all mine
[15:45:47 CDT(-0500)] <Bosmon> Ok then, doubtless you will have such things then
[15:45:53 CDT(-0500)] <kasparnet> haha
[15:46:30 CDT(-0500)] <kasparnet> Bosmon: but the only way I know which solutions will fire is based on the matchmaker, and the only way I know what settings are set is based on the transformer
[15:46:42 CDT(-0500)] <kasparnet> so I'd have to run those to figure out what will fire
[15:46:54 CDT(-0500)] <kasparnet> which to some extend seem to defeat the purpose
[15:47:03 CDT(-0500)] <Bosmon> kasparnet - yes, you will have to have separate records which do indeed encode the expected results of the transformer
[15:47:08 CDT(-0500)] <Bosmon> It would be too much to expect to deduce those
[15:47:22 CDT(-0500)] <Bosmon> But I think that Claudia had actually been working on drawing up a set of these
[15:47:36 CDT(-0500)] <Bosmon> It would be good to start pressing these into use in the form of genuine test cases
[15:48:50 CDT(-0500)] <kasparnet> ok, I didn't understand this latter part
[15:49:00 CDT(-0500)] <kasparnet> actually from the "separate records" line
[15:49:05 CDT(-0500)] <kasparnet> ... do you have time for a quick call?
[15:49:09 CDT(-0500)] <Bosmon> ok