fluid-work IRC Logs-2013-01-14

Owned by Fluid IRC Log Bot
Last updated: Jan 14, 2013Version comment
8 min read

[05:18:38 CST(-0600)] <jhernandez> kasper: ping

[05:18:53 CST(-0600)] <kasper> hey jhernandez

[05:19:16 CST(-0600)] <kasper> how are you doing?

[05:19:27 CST(-0600)] <jhernandez> fine!

[05:19:34 CST(-0600)] <jhernandez> mondays are evil ...

[05:19:35 CST(-0600)] <jhernandez> xDD

[05:19:43 CST(-0600)] <jhernandez> but well

[05:19:53 CST(-0600)] <kasper> hehe yes indeed

[05:20:49 CST(-0600)] <jhernandez> I was wondering if the 0.1 release (and users' NP sets) are focused on fedora 16

[05:21:17 CST(-0600)] <jhernandez> I'd like to do make the QA testing today

[10:05:49 CST(-0600)] <kasper> ping yzen1

[10:06:10 CST(-0600)] <yzen1> kasper: pong

[10:06:35 CST(-0600)] <kasper> what's that setting that you have to change in about:config in firefox to be able to run the browser tests

[10:06:36 CST(-0600)] <kasper> ?

[10:07:28 CST(-0600)] <kasper> yzen1: do you know which I mean?

[10:08:02 CST(-0600)] <yzen1> kasper: security.fileuri.strict_origin_policy;false

[10:09:15 CST(-0600)] <kasper> yzen1: arh ok.. was going for "security.checkloaduri", which was didn't work quite as well (smile)

[10:09:16 CST(-0600)] <kasper> thanks

[10:11:14 CST(-0600)] <jhernandez> ls

[10:11:18 CST(-0600)] <jhernandez> oops

[10:11:22 CST(-0600)] <jhernandez> bad window

[10:11:27 CST(-0600)] <kasper> hehe

[10:11:29 CST(-0600)] <jhernandez> xDDD

[13:07:40 CST(-0600)] <Bosmon2> michelled - I've had an offer from yzen1 to review the massive framework testing pull along with you (smile)

[13:07:55 CST(-0600)] <michelled> sounds good

[13:08:03 CST(-0600)] <michelled> when would you like to do that yzen?

[13:08:09 CST(-0600)] <yzen> now (smile) ?

[13:08:18 CST(-0600)] <michelled> ok, shall I come over there?

[13:08:25 CST(-0600)] <Bosmon2> great!

[13:08:35 CST(-0600)] <yzen> sure or i can come over , up to you

[13:08:49 CST(-0600)] <Bosmon2> I'm just working on porting this over to the node environment

[13:09:07 CST(-0600)] <yzen> Bosmon2: will it be part of the repo or something else ?

[13:09:17 CST(-0600)] <yzen> i mean pull request

[13:09:23 CST(-0600)] <Bosmon2> I don't expect that to result in any further changes, but there might need to be a tiny tweak to jqUnit.js

[13:09:25 CST(-0600)] <Bosmon2> Well, good question

[13:09:33 CST(-0600)] <Bosmon2> There will be a new file jqUnit-node.js

[13:09:41 CST(-0600)] <Bosmon2> I think I'll just keep that on the GPII side for now

[13:10:09 CST(-0600)] <yzen> Bosmon2: do you know if the sync test issue will be addressed too ?

[13:10:10 CST(-0600)] <Bosmon2> You will see in my Infusion pull that jqUnit has split into jqUnit-browser.js

[13:10:14 CST(-0600)] <Bosmon2> yzen - yes, it will

[13:10:21 CST(-0600)] <yzen> Bosmon2: that's good news

[13:11:46 CST(-0600)] <michelled> so, should we wait for you to finish what you're doing then, Bosmon2?

[13:11:55 CST(-0600)] <Bosmon2> I think you can start reviewing now

[13:12:02 CST(-0600)] <michelled> ok

[13:12:04 CST(-0600)] <Bosmon2> Any further changes can be reviewed separately, if there even are any at all

[13:14:57 CST(-0600)] <yzen> So Bosmon2, which pull request should we look at first ?

[13:15:07 CST(-0600)] <yzen> ioc test framework or the jqunit ?

[13:28:28 CST(-0600)] <Bosmon2> ioc test framework first

[13:28:37 CST(-0600)] <Bosmon2> Although there is are changes to the former due to the latter

[13:28:43 CST(-0600)] <Bosmon2> Given that jqUnit itself which is based on has changed

[13:28:54 CST(-0600)] <Bosmon2> yzen

[13:29:00 CST(-0600)] <yzen> Bosmon2: thanks

[13:40:06 CST(-0600)] <yzen> Bosmon2: so we are looking at the testingtests

[13:40:14 CST(-0600)] <yzen> Bosmon2: in test.sequence

[13:40:30 CST(-0600)] <yzen> there are cases where listener is added before jquery event, and also after

[13:41:01 CST(-0600)] <yzen> Bosmon2: in case of change applier it seems like you are attaching model changed listener after the corresponding dom is modified

[13:41:07 CST(-0600)] <yzen> is that correct ?

[13:41:31 CST(-0600)] <yzen> Bosmon2: we are talking about lines 146-186

[13:55:26 CST(-0600)] <jessm> fluid-everyone: look at this cool HTML5 site: http://fff.cmiscm.com/#!/main

[13:57:13 CST(-0600)] <anastasiac> jessm: wow! That is fabulous!

[13:57:14 CST(-0600)] <Bosmon2> jessm - I see lots of inaccessible stuff whizzing about (smile)

[13:57:23 CST(-0600)] <jessm> Bosmon2: i'm sure

[13:58:44 CST(-0600)] <Bosmon2> I can't get this one to do anything

[13:58:45 CST(-0600)] <Bosmon2> http://fff.cmiscm.com/#!/section/surfacewaves

[13:59:19 CST(-0600)] <jessm> mouse movements control the wavelengths

[13:59:28 CST(-0600)] <Bosmon2> I just see a circle...

[13:59:48 CST(-0600)] <Bosmon2> yzen - do you mean 146-186 in TestingTests.js?

[14:00:00 CST(-0600)] <Bosmon2> That's quite a long range

[14:00:15 CST(-0600)] <Bosmon2> Perhaps 146-156?

[14:00:32 CST(-0600)] <yzen> yes

[14:00:37 CST(-0600)] <yzen> well i mean all of it

[14:00:40 CST(-0600)] <Bosmon2> ok

[14:00:47 CST(-0600)] <Bosmon2> What is the question?

[14:01:03 CST(-0600)] <yzen> Bosmon2: i mean there listener->event and event->lsitener sequence

[14:01:09 CST(-0600)] <Bosmon2> Yes

[14:01:21 CST(-0600)] <Bosmon2> The idea behind the sequence is that "the sequence you write is the sequence you expect to happen"

[14:01:28 CST(-0600)] <yzen> well ok

[14:01:38 CST(-0600)] <yzen> so i can attach a listener after an event ?

[14:01:43 CST(-0600)] <Bosmon2> And you are not meant to have to think closely about exactly WHEN a listener is added

[14:01:43 CST(-0600)] <Bosmon2> Yes

[14:01:50 CST(-0600)] <Bosmon2> Because you expect the listener to be notified AFTER the event

[14:02:03 CST(-0600)] <Bosmon2> It is the framework's job to interpret when it should actually add the listener

[14:02:15 CST(-0600)] <yzen> crazy talk (smile)

[14:02:18 CST(-0600)] <Bosmon2> hahaha

[14:05:31 CST(-0600)] <Bosmon2> jessm - this site was clearly made by a "designer"

[14:05:45 CST(-0600)] <Bosmon2> Of the kind that jameswy seemed to be constantly striving to be.... : P

[14:07:44 CST(-0600)] <jessm> Bosmon2: eye candy

[14:36:19 CST(-0600)] <yzen> Bosmon2: ayt?

[14:44:37 CST(-0600)] <Bosmon2> yzen - what is this about SPOK? : P

[14:44:51 CST(-0600)] <yzen> Bosmon2: it just makes sense (smile)

[14:45:02 CST(-0600)] <yzen> Bosmon2: quick question

[14:45:09 CST(-0600)] <yzen> since we got your attention

[14:45:45 CST(-0600)] <yzen> how do we go about the case where we want a listener to fire only once for a specific event, even though it might get triggered multiple times ?

[14:46:05 CST(-0600)] <Bosmon2> yzen - that is what always happens

[14:46:24 CST(-0600)] <yzen> Bosmon2: so it only happens ones ?

[14:46:29 CST(-0600)] <Bosmon2> yes

[14:46:44 CST(-0600)] <yzen> what if the event is not controlled by the sequence, do we just blindly attach it twice ?

[14:46:54 CST(-0600)] <yzen> once

[14:47:08 CST(-0600)] <Bosmon2> What do you mean by the event not being controlled by the sequence?

[14:47:16 CST(-0600)] <Bosmon2> If it's not controlled by the sequence, how do you know when it will occur.....

[14:47:36 CST(-0600)] <yzen> Bosmon2: controlled by the component

[14:47:37 CST(-0600)] <yzen> so for example

[14:47:47 CST(-0600)] <yzen> i am testing a renderer component

[14:47:52 CST(-0600)] <yzen> and what i test is refreshview

[14:48:02 CST(-0600)] <yzen> i call it twice lets say

[14:48:18 CST(-0600)] <yzen> i would need to attach afterRender listener twice as well ?

[14:48:32 CST(-0600)] <Bosmon2> Yes

[14:48:50 CST(-0600)] <yzen> ok

[14:53:45 CST(-0600)] <yzen> Bosmon2: what was the intention behind impersonate listener ?

[14:53:49 CST(-0600)] <yzen> what is it for ?

[14:54:15 CST(-0600)] <Bosmon2> yzen - it is needed to fix FLUID-4869

[14:54:28 CST(-0600)] <Bosmon2> Previously it was not possible to remove changeApplier listeners by function reference

[14:54:43 CST(-0600)] <yzen> huh really ?

[14:54:45 CST(-0600)] <Bosmon2> Since the literal function reference held in the listener didn't agree with the one supplied by the user

[14:54:52 CST(-0600)] <Bosmon2> Really (smile)

[14:54:54 CST(-0600)] <Bosmon2> It was impossible

[14:54:57 CST(-0600)] <Bosmon2> Noone noticed....

[14:58:31 CST(-0600)] <yzen> Bosmon2: do you know if we still cant remove an eventFirer listener by functional reference?

[14:58:44 CST(-0600)] <Bosmon2> yzen - what do you mean by "still"?

[14:59:15 CST(-0600)] <yzen> well Bosmon2 we never could, but i wonder if it was in mind at some point ?

[15:00:41 CST(-0600)] <Bosmon2> yzen - we have been able to do that for a while

[15:00:52 CST(-0600)] <Bosmon2> I can't remember exactly when that bug was fixed, but it was

[15:02:09 CST(-0600)] <Bosmon2> Perhaps it was fixed along with FLUID-4722

[15:16:10 CST(-0600)] <yzen> Bosmon2: so in regards to jqUnit assertion steps, unless i have access to a value that will be compared to expected (it sits in some component/object in the tree), I can't dynamically assert and evaluate a framework function for example ? Unless of course i wrap the whole assertion into a separate function that will be run as a step..

[15:22:12 CST(-0600)] <Bosmon2> If you want to process the value to be compared, you will need a separate function, yes

[15:26:17 CST(-0600)] <yzen> Bosmon2: is the return value of a sequence step that has func and args is accessible somehow ?

[15:27:05 CST(-0600)] <Bosmon2> Not currently, but that's an interesting idea

[15:27:09 CST(-0600)] <Bosmon2> Similar to GPII "Actions"....

[15:27:27 CST(-0600)] <yzen> or if you saw my recent tests there

[15:27:48 CST(-0600)] <yzen> this way i can encode what i would otherwise have to write a function for

[15:28:58 CST(-0600)] <Bosmon2> Yes, ok

[15:29:01 CST(-0600)] <Bosmon2> We can do that

[15:29:26 CST(-0600)] <yzen> Bosmon2: since we already track sequence and the position in it

[15:29:58 CST(-0600)] <Bosmon2> Although identifying sequence points by number is a bit unstable

[15:30:05 CST(-0600)] <yzen> yes

[15:30:09 CST(-0600)] <Bosmon2> We might really want the facility to identify these values by a stable key

[15:30:13 CST(-0600)] <yzen> i was wondering about that

[15:30:19 CST(-0600)] <yzen> yes

[15:30:23 CST(-0600)] <Bosmon2> Perhaps an optional extra entry in a sequence record holding the key name

[15:30:45 CST(-0600)] <yzen> just like that name field for the test itself

[15:30:46 CST(-0600)] <yzen> ues

[15:30:48 CST(-0600)] <yzen> yes

[15:31:24 CST(-0600)] <Bosmon2> Your declarative tests still seem to have the weird document mockup in them btw

[15:31:31 CST(-0600)] <yzen> we wont have to write any functions (smile)

[15:31:38 CST(-0600)] <Bosmon2> I assumed that could just go into the framework

[15:32:12 CST(-0600)] <yzen> you mean expected stuff ?

[15:32:20 CST(-0600)] <yzen> oh that

[15:32:39 CST(-0600)] <yzen> yes that is but not for that function

[15:32:42 CST(-0600)] <yzen> ill see what i can do there

[15:32:45 CST(-0600)] <Bosmon2> The getElementById mockup

[15:32:51 CST(-0600)] <Bosmon2> Which presumably won't be necessary for clients

[15:33:39 CST(-0600)] <yzen> yep

[15:41:34 CST(-0600)] <yzen> Bosmon2: where does the name ducks come from ?

[15:44:45 CST(-0600)] <Bosmon2> "Ducks" relates to the concept of "duck typing"

[15:44:59 CST(-0600)] <Bosmon2> http://en.wikipedia.org/wiki/Duck_typing

[15:46:36 CST(-0600)] <yzen> Bosmon2: so runTests runs the test trees asynchronously ?

[15:46:53 CST(-0600)] <Bosmon2> Yes, you could call it "asynchronously"

[15:47:04 CST(-0600)] <Bosmon2> I mean, in practice, it runs them synchronously

[15:47:12 CST(-0600)] <Bosmon2> Even though they contain numerous asynchronous elements

[15:47:32 CST(-0600)] <Bosmon2> It is different to the default QUnit model which really does try to run all your tests simultaneously and asynchronously

[15:48:14 CST(-0600)] <yzen> Bosmon2: so how come you need a setTimeout in runtets ?

[15:49:20 CST(-0600)] <Bosmon2> yzen - in order to ensure that destruction of the tree is fully concluded before the next test

[15:49:30 CST(-0600)] <Bosmon2> Merely having a listener in an "onDestroy" method ensures that destruction is STARTED

[15:49:41 CST(-0600)] <Bosmon2> But of course there may be any number of further listeners

[15:50:24 CST(-0600)] <Bosmon2> So yes, you could say that it runs the tests "asynchronously but serially"

[15:59:17 CST(-0600)] <yzen> Bosmon2: so should we wait for the accessible sequence return value before merging ? michelled and I looked over the pull request. other than spok it all looks good (smile)

[16:00:44 CST(-0600)] <Bosmon2> I think we can make a separate JIRA for the accessible return value

[16:01:10 CST(-0600)] <Bosmon2> We need to get this stuff in relatively soon so we can start processing the other outstanding pull requests

[16:01:12 CST(-0600)] <Bosmon2> Including yours : P

[16:01:29 CST(-0600)] <Bosmon2> We will need to do VideoPlayer as well

[16:01:39 CST(-0600)] <Bosmon2> As soon as it updates Infusion, all its tests will stop working

[16:02:05 CST(-0600)] <yzen> Bosmon2: it would be nice to avoid writing functions once and for all though

[16:02:14 CST(-0600)] <yzen> oh wow

[16:03:51 CST(-0600)] <Bosmon2> This would block your renderer fix too, so we may as well do this now and make a separate work package