fluid-work IRC Logs-2013-09-20

[09:05:35 CDT(-0500)] <Justin_o> michelled: can you take a look at this wiki page http://wiki.fluidproject.org/display/fluid/Infusion+1.5+Iteration+Plan

[09:06:05 CDT(-0500)] <michelled> Justin_o: you figured it out!

[09:06:10 CDT(-0500)] <michelled> what were we doing wrong?

[09:07:20 CDT(-0500)] <Justin_o> michelled: not much.. i think it just doesn't work in the edit mode

[09:07:52 CDT(-0500)] <michelled> sigh

[09:08:03 CDT(-0500)] <Justin_o> michelled: basically i just did something like

[09:40:06 CDT(-0500)] <Justin_o> michelled: looks like the gpii build is up http://build.gpii.net/prefsEditors/demos/discoveryTool/

[09:40:35 CDT(-0500)] <Justin_o> should we put a link to that on our build site? not sure it's worth it because it is basically the same as the one we have up there.. well older really

[09:42:12 CDT(-0500)] <michelled> good question Justin_o - I think it should be publicized on the GPII list. it will encourage some pull requests so the whole community can see the work that is being done.

[09:42:27 CDT(-0500)] <michelled> feel like sending a message?

[09:43:02 CDT(-0500)] <Justin_o> michelled: maybe we should wait till avtar is online to verify everything is good to go.. he had mentioned something about an IP address changing..

[09:46:26 CDT(-0500)] <michelled> makes sense

[10:08:12 CDT(-0500)] <avtar> Justin_o, michelled: i tried to retain the same ip so that kasper wouldn't have to make dns changes but anastasiac is having issues accessing that vm from the office

[10:11:20 CDT(-0500)] <avtar> i brought up the issue with yong because the logs on the vm don't show anything out of the ordinary and it's reachable via its public ip from outside of the idrc network

[10:17:09 CDT(-0500)] <avtar> yong would like for me to test it with a new public ip

[10:17:52 CDT(-0500)] <avtar> the dns change might be unavoidable

[11:03:19 CDT(-0500)] <cindyli> yzen, avtar, in order to POST json data to a CORS enabled gpii server, an OPTIONS request needs to be sent first to ask whether the POST request from the client domain is allowed. The server responded status code for this OPTIONS request is expected to be 200. right now I'm getting 404 "not found" for OPTIONS requests. I'm wondering:

[11:03:36 CDT(-0500)] <cindyli> 1. can we config the GPII web server to handle OPTOINS?

[11:04:40 CDT(-0500)] <cindyli> 2. if 1 is not doable, we may need to adjust server code to handle OPTIONS

[11:10:55 CDT(-0500)] <avtar> cindyli: are you able to test it locally using your preferences server vm?

[11:11:54 CDT(-0500)] <avtar> solution #2 listed here http://blog.rogeriopvl.com/archives/nginx-and-the-http-options-method/

[11:12:13 CDT(-0500)] <avtar> and/or this https://gist.github.com/michiel/1064640

[11:15:33 CDT(-0500)] <cindyli> cool, trying

[11:22:23 CDT(-0500)] <cindyli> success, thanks, avtar.

[11:24:16 CDT(-0500)] <avtar> awesome

[11:24:32 CDT(-0500)] <avtar> maybe email yzen since he was looking into this as well

[12:02:17 CDT(-0500)] <kasparnet> avtar

[12:02:20 CDT(-0500)] <kasparnet> ping

[12:02:23 CDT(-0500)] <avtar> hi

[12:04:36 CDT(-0500)] <avtar> kasparnet: hi

[12:11:18 CDT(-0500)] <kasparnet> hi avtar, saw your email

[12:11:29 CDT(-0500)] <kasparnet> what changes do you need me to do

[12:12:43 CDT(-0500)] <Bosmon> Hi Justin_o - I am looking at your report for FLUID-5145

[12:13:07 CDT(-0500)] <Bosmon> I am wondering whether this issue has anything to do with boiled events, or whether it is an issue at all : P

[12:13:17 CDT(-0500)] <Bosmon> As far as I can see, you are firing an event once, and expecting to listen to it twice

[12:13:24 CDT(-0500)] <Bosmon> Is this not the case?

[12:13:47 CDT(-0500)] <Justin_o> Bosmon: yes.. that's the case.. off of the parent and off of the child..

[12:14:20 CDT(-0500)] <Bosmon> So naturally the framework "halts" since it is waiting for you to do something which causes the 2nd listener to fire

[12:15:18 CDT(-0500)] <Justin_o> Bosmon: it works fine for the boiled event in the child.. the child's listener will fire

[12:15:38 CDT(-0500)] <Bosmon> Justin_o - quite

[12:15:45 CDT(-0500)] <Bosmon> But somehow you are expecting it to fire TWICE

[12:15:48 CDT(-0500)] <Bosmon> Can you explain why?

[12:15:48 CDT(-0500)] <Justin_o> Bosmon: so if you were to reverse the order of the sequence.. the child event would fire but it will still halt at the parent

[12:15:58 CDT(-0500)] <Justin_o> Bosmon: i'm expecting it to fire once

[12:15:59 CDT(-0500)] <Bosmon> What do you mean by "halt at the parent"

[12:16:03 CDT(-0500)] <Justin_o> but to be listened to by both

[12:16:12 CDT(-0500)] <Bosmon> Justin_o - you have two listener records in a row in your test sequence

[12:16:15 CDT(-0500)] <Bosmon> Which implies you expect two firings

[12:16:32 CDT(-0500)] <Bosmon> Your test fixture contains this:

[12:16:33 CDT(-0500)] <Bosmon> listener: "fluid.tests.checkEvent",

[12:16:33 CDT(-0500)]

[12:16:33 CDT(-0500)] <Bosmon> }, {

[12:16:33 CDT(-0500)] <Bosmon> listener: "fluid.tests.checkEvent",

[12:16:33 CDT(-0500)]

[12:16:34 CDT(-0500)] <Bosmon> }]

[12:16:37 CDT(-0500)] <Justin_o> Bosmon: yes.. i want to trigger the event to fire once.. but to listen to it from both the parent and from the child

[12:16:46 CDT(-0500)] <Bosmon> This represents two event firings in sequence

[12:16:54 CDT(-0500)] <Bosmon> but there is nothing to cause the 2nd firing

[12:17:24 CDT(-0500)] <Justin_o> Bosmon: is there no way to test what i'm trying to do without having to trigger it twice

[12:17:38 CDT(-0500)] <Bosmon> Justin_o - two listeners, two firings : P

[12:17:53 CDT(-0500)] <Justin_o> Bosmon: by the way.. if i had two child components that boiled the same event from the parent, they would both be listened to

[12:18:11 CDT(-0500)] <Justin_o> Bosmon: i have this working in some code I'm presently writing for FLUID-5131

[12:18:40 CDT(-0500)] <Justin_o> Bosmon: it only has a problem listening to the event directly from the parent

[12:18:53 CDT(-0500)] <Justin_o> Bosmon: does that make sense?

[12:20:01 CDT(-0500)] <Justin_o> Bosmon: here's an example from what i'm working on http://pastie.org/private/isk5lz6ikzdmp6lsnxfv7g

[12:20:03 CDT(-0500)] <Bosmon> Justin_o - I'm not sure it does - can you write a test case demonstrating it? : P

[12:21:12 CDT(-0500)]

[12:21:49 CDT(-0500)] <Justin_o> Bosmon: yes

[12:23:05 CDT(-0500)] <Bosmon> CouldCould you produce a test case for that?

[12:30:51 CDT(-0500)] <Justin_o> Bosmon: i see why you were confused. I had accidentally committed both listeners bound to the same event. I had done this to test something quickly and guess forgot to change it back. I've fixed it up and expanded the tests now.

[12:31:17 CDT(-0500)] <Justin_o> Bosmon: hopefully it will make more sense this time

[12:39:10 CDT(-0500)] <Justin_o> Bosmon: is it not possible to use an expander for distribute options?

[12:40:04 CDT(-0500)] <Bosmon> Justin_o - in general, since it would be ambiguous whether you wanted to distribute the expander itself or its results

[12:40:30 CDT(-0500)] <Bosmon> Justin_o, cindyli - I wanted to warn against what seems to be a general tendency towards "overuse" of the IoC testing system

[12:40:55 CDT(-0500)] <Justin_o> Bosmon: what would classify as an overuse

[12:41:05 CDT(-0500)] <Bosmon> In general it is only appropriate for use where there are events which are ASYNCHRONOUS whereas I am tending to find it used in "any cases which have something to do with events"

[12:41:27 CDT(-0500)] <Bosmon> So for example, in cindyli's recent test cases for the ModelRelay system, the use was not necessary, since all of these events are clearly synchronous

[12:42:08 CDT(-0500)] <Bosmon> And for example, Justin_o's recent FLUID-5145 test was overcomplicated by the use of the IoC testing framework, which obscured the real issue

[12:42:58 CDT(-0500)] <Justin_o> Bosmon: i thought it was also needed for testing event sequences.. mind you i could have done mine more basically

[12:43:04 CDT(-0500)] <cindyli> Bosmon: i thought we intend to deprecate the old way of writing unit tests and replace it with IoC testing system

[12:43:13 CDT(-0500)] <Bosmon> In general an IoC testing framework fixture corresponds to a SEPARATE AND ASYNCHRONOUSLY OCCURING instant in time - and so naturally it is not possible to write fixtures which are trying to test two different results from the same event firing

[12:43:19 CDT(-0500)] <Bosmon> cindyli - that is not correct!

[12:43:27 CDT(-0500)] <Bosmon> The IoC testing framework is only useful for specialised situations

[12:43:34 CDT(-0500)] <Justin_o> Bosmon: although it might have been hard for me to know when to terminate my test

[12:43:42 CDT(-0500)] <Justin_o> since it loops through the same events 3 times

[12:44:00 CDT(-0500)] <Bosmon> Before you use it, ask yourself - is there genuine asynchrony in the situation - that is - does it involve either i) user interaction via the DOM, or ii) AJAX requests

[12:44:28 CDT(-0500)] <Bosmon> If it does not, it is much better to use more simple techniques, for example, those similar to the "fireRecord" approach that you can see in the IoC tests themselves

[12:44:57 CDT(-0500)] <Bosmon> If you search through FluidIoCTests.js, you will find various references to a member called "fireRecord" - the idea is that each listener pushes a record onto the end of this list, and at the end of the test, its contents are checked with a call to "jqUnit.assertDeepEq"

[12:45:32 CDT(-0500)] <Bosmon> For situations without genuine asynchrony this is a much more straightforward approach that is capable of testing more things - for example Justin_o's "one event two listeners" issue

[12:45:43 CDT(-0500)] <Justin_o> Bosmon: okay.. i don't think it was entirely clear about only using the IoC testing framework for these special cases

[12:45:45 CDT(-0500)] <Bosmon> You could express your "don't care indeterminism" by having both listeners push the same record

[12:46:06 CDT(-0500)] <Bosmon> Justin_o - sorry it wasn't clear - we should write it up better in that case!

[12:46:22 CDT(-0500)] <Justin_o> anastasiac: ^

[12:46:40 CDT(-0500)] <Justin_o> Bosmon, anastasiac, maybe we can add it to the list of doc tasks

[12:46:55 CDT(-0500)] <Bosmon> The IoC testing framework is primarily aimed at a certain class of "integration testing tasks"

[12:47:09 CDT(-0500)] <anastasiac> I will review the logs and figure out what you want to add to the list

[12:47:11 CDT(-0500)] <Bosmon> Usually where some substantial kind of application is taken through various interaction cycles, which involve some asynchronous activity

[12:47:30 CDT(-0500)] <Bosmon> For example, yzen would have found it useful in testing CSpace interactions, and kasparnet finds it useful for his GPII integration tests

[12:47:52 CDT(-0500)] <Bosmon> But it isn't to be used in more low-level unit testing scenarios, unless for some reason these involve a lot of asynchrony and sequence

[12:48:15 CDT(-0500)] <Justin_o> Bosmon: okay.. i'll re-write my tests to use the "fireRecord" strategy

[12:49:06 CDT(-0500)] <anastasiac> Justin_o, are you able to give me a one or two sentence summary of what you want documented?

[12:50:24 CDT(-0500)] <Justin_o> anastasiac: Basically that the IoC Testing framework is only for integration testing requiring asynchrony.

[12:50:52 CDT(-0500)] <anastasiac> okley, thanks Justin_o, that helps

[12:51:32 CDT(-0500)] <Justin_o> anastasiac: and that for other cases the old style should be used, can also look at the fireRecord approach used in FluidIoCTests.js for testing events that don't require asynchony

[12:51:37 CDT(-0500)] <Justin_o> anastasiac: thanks

[12:51:51 CDT(-0500)] <Justin_o> Bosmon: So I have some more questions for you related to the distribute options

[12:51:51 CDT(-0500)] <Bosmon> Justin_o - I had a brief look over your invoker docs - they are looking good!

[12:52:00 CDT(-0500)] <Justin_o> Bosmon: thanks

[12:52:07 CDT(-0500)] <Bosmon> I think it would be better to combine the entries on "func/funcName" since these are essentially the same record

[12:52:51 CDT(-0500)] <Bosmon> I need to dash off to the dentist unfortunately, but I'll be back in about an hour

[12:53:11 CDT(-0500)] <Justin_o> Bosmon: okay.. i'll make that change and check in with you again when you are back about the distribute options things

[13:00:27 CDT(-0500)] <Justin_o> Bosmon, anastasiac: updated the invoker page

[13:00:32 CDT(-0500)] <Justin_o> http://wiki.fluidproject.org/display/docs/Invokers

[13:22:59 CDT(-0500)] <cindyli> michelled: Justin_o and I were talking about how to send the pull request for http://issues.gpii.net/browse/GPII-185, which is to set/get discovery tool preferences from the gpii server

[13:24:20 CDT(-0500)] <michelled> cindyli: can you not send the pull request in the same way we generally do?

[13:24:22 CDT(-0500)] <cindyli> we can point ajax calls to gpii server daily build site (once it's CORS enables), but since DT has to use one user id, everyone who plays discovery tool site will apply the pref changes to the same data

[13:24:36 CDT(-0500)] <cindyli> what would u suggest, michelled

[13:26:27 CDT(-0500)] <michelled> hmmm… I don't like that idea - it will make DT look broken when we have multiple people using it

[13:27:15 CDT(-0500)] <michelled> cindyli: perhaps there is something we could do to give the feeling of having multiple users.

[13:28:42 CDT(-0500)] <Justin_o> michelled, cindyli: do you know if there are designs for a login?

[13:29:35 CDT(-0500)] <cindyli> i don't know

[13:32:02 CDT(-0500)] <cindyli> even with login, tryout sites usually provide test id for users to play with. we still cannot guarantee different users are using different ids when they login at the same time

[13:34:03 CDT(-0500)] <cindyli> michelled, Justin_o, can we keep DT using cookie store by default and provide instructions on how to turn on and use gpii store?

[14:32:08 CDT(-0500)] <Justin_o> Bosmon: if you see this when you get back. I've left a comment on the FLUID-5131 jira about the distribute options issue i'm having http://issues.fluidproject.org/browse/FLUID-5131 . If you have any thoughts about how to address this issue, can you let me know. Thanks

[14:37:59 CDT(-0500)] <anastasiac> cindyli, the UIO contrast icons on the build site are not being styled. Is that a known issue?

[14:38:09 CDT(-0500)] <anastasiac> http://build.fluidproject.org/infusion/demos/uiOptions/gradesDemo/html/uiOptions.html

[14:42:04 CDT(-0500)] <cindyli> anastasiac: doesn't seem like a known issue, at least not in the bug tracker

[14:42:26 CDT(-0500)] <anastasiac> I wonder when that creeped in, cindyli

[14:42:39 CDT(-0500)] <cindyli> not sure. trying with my local UIO

[14:42:55 CDT(-0500)] <anastasiac> it's ok in full-page...

[14:42:58 CDT(-0500)] <anastasiac> odd

[14:43:40 CDT(-0500)] <anastasiac> cindyli, it's broken for me locally, too

[14:43:58 CDT(-0500)] <cindyli> same here

[14:44:43 CDT(-0500)] <Bosmon> It is a known issue

[14:44:53 CDT(-0500)] <Bosmon> michelled was investigating it yesterday

[14:45:55 CDT(-0500)] <Bosmon> It is covered by this pull request - https://github.com/fluid-project/infusion/pull/406

[14:46:05 CDT(-0500)] <Bosmon> Although it would still be nice to know the reason this change is required

[14:46:39 CDT(-0500)] <michelled> Bosmon: I didn't manage to spend time investigating it. I can look at it on Monday or someone else could look at it.

[14:47:00 CDT(-0500)] <anastasiac> ah, right, the mystery fix

[14:47:15 CDT(-0500)] <anastasiac> ok, so I won't file a JIRA