fluid-tech IRC Logs-2013-07-22

[11:41:12 CDT(-0500)] <colinclark> Hey nanook_, how was your weekend?

[13:00:05 CDT(-0500)] <kasparnet> Bosmon: heya dr. Bassman!

[13:02:36 CDT(-0500)] <kasparnet> or.. not sure who would be good to ask questions about the testing framework/events/listeners... perhaps Justin_o or michelled

[13:03:34 CDT(-0500)] <kasparnet> I'm stuck on an issue with the system complaining about attempting to add a listener to the an undefined object

[13:03:59 CDT(-0500)] <kasparnet> I looked at some examples that Bosmon/yzen sent me and cant figure out what I'm missing

[13:05:07 CDT(-0500)] <kasparnet> the error seem to be from these two lines: https://github.com/kaspermarkus/linux/blob/GPII-20/tests/integrationTesting2.js#L142-L143

[13:05:54 CDT(-0500)] <kasparnet> and I guess I do initialize that event to null, but I thought the framework would set it up to something useful (https://github.com/kaspermarkus/linux/blob/GPII-20/tests/integrationTesting2.js#L71-L74)

[13:14:59 CDT(-0500)] <Bosmon> kasparnet - you forgot to make your httpReq component into an "eventedComponent"

[13:15:07 CDT(-0500)] <Bosmon> This is such a frequent error we will have to do something about it

[13:15:13 CDT(-0500)] <kasparnet> Bosmon: ahhh - cool

[13:15:43 CDT(-0500)] <kasparnet> thanks

[13:15:45 CDT(-0500)] <kasparnet> Bosmon: couldn't you imply it from the existence of an "event" option in the defaults block?

[13:16:04 CDT(-0500)] <Bosmon> kasparnet - you could, but that's not how it works currently

[13:16:10 CDT(-0500)] <Bosmon> The user has to actually say what kind of component they want

[13:16:27 CDT(-0500)] <Bosmon> But we may just abolish the framework grades "modelComponent" and "eventedComponent"

[13:16:37 CDT(-0500)] <Bosmon> Since as you say both of those could be determined automatically

[13:20:38 CDT(-0500)] <kasparnet> Bosmon: yay - it worked

[13:22:47 CDT(-0500)] <Bosmon> Well done, *KKASPPARNETT*!!

[13:55:50 CDT(-0500)] <yzen> Bosmon: hi

[13:59:24 CDT(-0500)] <Bosmon> yzen

[14:20:08 CDT(-0500)] <yzen> Bosmon: I was wondering what the good prefix would be for the source of data binding change requetss

[14:27:28 CDT(-0500)] <Bosmon> yzen - perhaps model: ?

[14:27:41 CDT(-0500)] <yzen> Bosmon: i was also thinking auto:

[14:43:07 CDT(-0500)] <Bosmon> yzen - what is "auto" about it?

[15:01:27 CDT(-0500)] <yzen> oh i did not see your ...

[15:01:47 CDT(-0500)] <yzen> Bosmon: well it's a change triggered by the framework itself, not user or user code

[15:03:46 CDT(-0500)] <Bosmon> yzen - what actually triggers it in this case?

[15:05:57 CDT(-0500)] <yzen> Bosmon: fluid.applyBoundChange

[15:06:25 CDT(-0500)] <yzen> Bosmon: that's where i saw the comment "Automatically" apply to whatever part of the data model is relevant

[15:08:10 CDT(-0500)] <Bosmon> applyBoundChange!

[15:08:18 CDT(-0500)] <Bosmon> That should really be treated as a DOM: chang

[15:08:19 CDT(-0500)] <Bosmon> e

[15:08:44 CDT(-0500)] <Bosmon> Wait, it is

[15:08:54 CDT(-0500)] <Bosmon> So I think DOM: would be fine as a prefix for that

[15:09:12 CDT(-0500)] <Bosmon> As I was mentioning to Justin_o in the other channel

[15:09:24 CDT(-0500)] <Bosmon> So what is the OTHER kind of change?

[15:10:21 CDT(-0500)] <yzen> Bosmon: no that was the one

[15:10:30 CDT(-0500)] <yzen> ok I'm adding DOM: prefix, just wanted to make sure

[15:13:58 CDT(-0500)] <Bosmon> yzen - but what was the other kind of change that this got confused with

[15:14:39 CDT(-0500)] <yzen> Bosmon: well it was not really a confusion i just wanted to double check if DOM was a final prefix that everyone agreed on

[15:14:48 CDT(-0500)] <yzen> Bosmon: https://github.com/fluid-project/infusion/pull/369

[15:14:55 CDT(-0500)] <Bosmon> yzen - the original bug was caused by a "source" confusion

[15:14:58 CDT(-0500)] <Bosmon> Between two different kinds of sources

[15:15:02 CDT(-0500)] <Bosmon> So what was the other one?

[15:16:52 CDT(-0500)] <yzen> Bosmon: or right the other one was within the model relay, where we add a source aware listener. so for a panel the source was the name of the field in the model "textFont" for example that would be identical to the final node.id that the applier would use "textFont" when applying a change

[15:18:07 CDT(-0500)] <Bosmon> yzen, cindyli1 - what was the source-aware listener trying to achieve?

[15:18:38 CDT(-0500)] <yzen> Bosmon: to prevent a circular change requests between 2 appliers that we relay between

[15:18:46 CDT(-0500)] <Bosmon> aha

[15:19:09 CDT(-0500)] <Bosmon> So this implies we need a prefix for relayed changes too then

[15:19:17 CDT(-0500)] <Bosmon> Either "relay:" or "model:" or so

[15:19:43 CDT(-0500)] <yzen> Bosmon: yes it makes sense ill do along with the changes to the framework

[15:20:01 CDT(-0500)] <Bosmon> yzenn - thanks

[15:20:02 CDT(-0500)] <yzen> the only reason we got away until now was because we had sections segment before the actual field name

[15:24:01 CDT(-0500)] <yzen> cindyli1: ayt?

[15:24:09 CDT(-0500)] <cindyli1> yes, yzen

[15:24:11 CDT(-0500)] <yzen> cindyli1: what's the latest branch now?

[15:24:16 CDT(-0500)] <yzen> yours or justin's?

[15:24:35 CDT(-0500)] <cindyli1> not sure what's in jus tin's branch. comparing

[15:26:17 CDT(-0500)] <cindyli1> yzen: seems justin's. he's merged in master. we had an error of "too much recursive" at merging master. not sure if that's fixed. or is it the same issue as the model relay?

[15:26:42 CDT(-0500)] <yzen> cindyli1: ya i fixed that on his machine but i guess it wasn't pushed

[15:26:51 CDT(-0500)] <yzen> so i should merge your 4907-merging ?

[15:27:18 CDT(-0500)] <cindyli1> yes, you can, but mine would throw "too much recursive"

[15:27:23 CDT(-0500)] <yzen> ok good

[15:47:00 CDT(-0500)] <Bosmon> yzen - did you get a framework error, or a hard recursion overflow from the browser?

[15:47:31 CDT(-0500)] <yzen> Bosmon: at what point?

[15:47:47 CDT(-0500)] <Bosmon> The error cindyli1 was just talking about

[15:48:01 CDT(-0500)] <yzen> yes that was fixed

[15:48:33 CDT(-0500)] <Bosmon> yzen - what kind of error was it

[15:48:41 CDT(-0500)] <yzen> Bosmon: too much recursion

[15:48:59 CDT(-0500)] <Bosmon> yzen - yes, thanks

[15:49:05 CDT(-0500)] <yzen> Bosmon: it was something you fixed in your pull for UI with refreshView, it's just that it moved in our version into a different file

[15:49:12 CDT(-0500)] <yzen> Bosmon: so i had to apply the change myself

[15:49:16 CDT(-0500)] <Bosmon> Now back to my original question, was it a framework error, or did it reach the browser?

[15:49:19 CDT(-0500)] <Bosmon> Ah ok

[15:49:27 CDT(-0500)] <Bosmon> It was the "refreshView" is not timely issue

[15:49:48 CDT(-0500)] <Bosmon> In general the framework should catch all reasonable recursion overflows now

[15:49:53 CDT(-0500)] <Bosmon> So if you find any, please let me know

[15:50:13 CDT(-0500)] <Bosmon> That is, it should be impossible to get browser-level recursion during expansion or merging

[16:34:44 CDT(-0500)] <kasparnet> hola Bosmon

[16:35:01 CDT(-0500)] <kasparnet> do you have a moment to look at my current integration test to see if I'm on the right track

[16:35:40 CDT(-0500)] <Bosmon> Sure, kasparnet

[16:35:49 CDT(-0500)] <Bosmon> You need an alert for **KASSPPPARNETT** too

[16:36:19 CDT(-0500)] <kasparnet> awesome - thanks

[16:36:20 CDT(-0500)] <kasparnet> https://github.com/kaspermarkus/linux/blob/GPII-20/tests/integrationTesting2.js

[16:37:27 CDT(-0500)] <kasparnet> Bosmon: think I set up an alert for that now

[16:37:40 CDT(-0500)] <kasparnet> ... wont know till someone pings me with it

[16:38:26 CDT(-0500)] <kasparnet> so in terms of the code

[16:38:40 CDT(-0500)] <kasparnet> I still have left to check all the running processes

[16:39:07 CDT(-0500)] <kasparnet> .. but afaik I'll have to do these as event / listener pairs for each process check

[16:39:15 CDT(-0500)] <kasparnet> which brings me to the next todo point

[16:39:39 CDT(-0500)] <kasparnet> which would be to generate https://github.com/kaspermarkus/linux/blob/GPII-20/tests/integrationTesting2.js#L133-L154 via model transformation or something

[16:39:50 CDT(-0500)] <kasparnet> which is what I think you suggested

[16:40:33 CDT(-0500)] <kasparnet> ... also, I guess there I guess I should start/kill server in setup/teardown functions

[16:41:38 CDT(-0500)] * kasparnet is experiencing the silence before the storm...

[16:47:14 CDT(-0500)] <Bosmon> Sorry, let me take a look

[16:47:29 CDT(-0500)] <kasparnet> coolio, thanks Bosmon

[16:48:21 CDT(-0500)] <Bosmon> re setup/teardown, we don't have those any more

[16:48:33 CDT(-0500)] <Bosmon> You can just register the server as a subcomponent of the system and it will be automatically bound to the correct lifecycle

[16:48:52 CDT(-0500)] <Bosmon> I think that is looking pretty good

[16:49:27 CDT(-0500)] <Bosmon> Although your httpreq "call" is still a bit ropy

[16:49:49 CDT(-0500)] <Bosmon> That should use proper FLuid events to operate the on ( on ( on ( on cycle

[16:52:25 CDT(-0500)] <colinclark> such wonderful modernist poetry

[16:52:33 CDT(-0500)] <colinclark> "the on ( on ( on ( on ( cycle"

[16:52:51 CDT(-0500)] <Bosmon> Yes, perhaps ee cummings could have worked on that

[16:53:38 CDT(-0500)] <colinclark> yes

[16:59:05 CDT(-0500)] <kasparnet> ok thanks Bosmon

[17:14:47 CDT(-0500)] <colinclark> Bosmon: Did we ever implement any kind of DataSource abstraction for the GPII Preference Server?

[17:15:02 CDT(-0500)] <colinclark> I know we whipped up some kind of thing for the Mammals demo, but did we ever do anything more than this?

[18:57:37 CDT(-0500)] <kasparnet> Bosmon: I got a question re: modeltransformation

[18:58:05 CDT(-0500)] <kasparnet> might be missing something very basic

[18:58:28 CDT(-0500)] <kasparnet> anyway I got these two payloads (model above, desired result below) http://piratepad.net/9zveDxH7zk

[18:59:07 CDT(-0500)] <kasparnet> and basically what I need to do in several places is to iterate through an array and be able to refer to the content of the current index (and index #)

[19:00:23 CDT(-0500)] <kasparnet> but not sure how to go about this

[19:01:30 CDT(-0500)] <kasparnet> seems I have to do something fancy like having the expander expose the index / value of current index to all below rules - so they can refer to the/use them

[19:01:48 CDT(-0500)] <kasparnet> ... or perhaps (and very likely) I'm just missing something basic

[19:22:59 CDT(-0500)] <kasparnet> bosmon: heading to bed now will check log tomorrow

[19:50:43 CDT(-0500)] <Bosmon> kasparnet - you're right, this is a missing faculty

[19:50:51 CDT(-0500)] <Bosmon> Please JIRA it, and use some manual code for now : P