fluid-work IRC Logs-2013-03-15

Owned by Fluid IRC Log Bot
Last updated: Mar 15, 2013Version comment
20 min read

[08:59:07 CDT(-0500)] <Justin_o> colinclark: when Bosmon was talking about an empty UIO, I'm assuming he just means one without the settings panel subcomponents.. i just want to double check that this matches your understanding

[08:59:30 CDT(-0500)] <colinclark> yes, that's my understanding too

[09:00:43 CDT(-0500)] <Justin_o> colinclark: okay cool.. so it seems i can just remove the subcomponents and things appear blank without errors (smile) so i guess i'll just drop them from the fluid.uiOptions defaults and move those into the configuration of the various UIO flavours instead or maybe make a grade or something

[09:01:16 CDT(-0500)] <Justin_o> colinclark: also, do you think i should be cleaning up UIO, for example moving things to invokers and etc.

[09:02:02 CDT(-0500)] <colinclark> yes

[09:02:13 CDT(-0500)] <Justin_o> colinclark: when i say blank, the template does still have the headings for the panels currently, so it looks a bit odd in that sense.. but that's about it

[09:02:14 CDT(-0500)] <colinclark> if you can opportunistically improve, do it

[09:02:20 CDT(-0500)] <Justin_o> colinclark: okay, thanks

[10:48:29 CDT(-0500)] <Saumya> Hey

[10:49:19 CDT(-0500)] <anastasiac> jessm, the testing stuff I was talking about was APIP: http://www.imsglobal.org/apip/index.html

[10:49:27 CDT(-0500)] <Saumya> I am saumya, a newbie here, interested in working with fluid project ideas for Gsoc 2013, please provide some guidance about where should i start

[10:49:33 CDT(-0500)] <anastasiac> this is another IMS working group dealing with accessibility of assessment things

[10:50:05 CDT(-0500)] <anastasiac> we are now working out how the APIP work will work with the A4A work: compatible? combine? etc.

[10:50:30 CDT(-0500)] <Justin_o> Saumya: welcome.. have you taken a look at this page yet http://wiki.fluidproject.org/display/fluid/Google+Summer+of+Code+2013+with+the+Fluid+Project

[10:51:35 CDT(-0500)] <colinclark> Saumya: Here's a link to an email Justin_o recently posted on our fluid-work mailing lists about how to get acquainted with Fluid: http://old.nabble.com/Re%3A-GSoC-2013-p35041280.html

[10:52:48 CDT(-0500)] <Saumya> Hey thanks, I'll just checkout these and get back if have any problems

[10:56:46 CDT(-0500)] <colinclark> great

[11:38:09 CDT(-0500)] <colinclark> greggy: I'm just on the phone with Steve Jacobs right now, and he told me to say hello to you

[11:38:58 CDT(-0500)] <greggy> colinclark: say hi back

[11:39:19 CDT(-0500)] <colinclark> will do

[11:46:09 CDT(-0500)] <Saumya> hey is there any freenode channel for atutor too?

[11:46:43 CDT(-0500)] <Justin_o> greggy, cindyli: ^

[11:46:57 CDT(-0500)] <greggy> Saumya: no, atutor is on oftc.net

[11:47:25 CDT(-0500)] <Saumya> okay...i asked because i wasnt able to connect...thanks anyways

[11:47:27 CDT(-0500)] <Saumya> (smile)

[11:48:10 CDT(-0500)] <greggy> Saumya: check you typing. Others are logged in okay

[11:50:35 CDT(-0500)] <colinclark> hey Nick_Kaklanis!

[11:50:39 CDT(-0500)] <colinclark> welcome to the channel

[11:50:48 CDT(-0500)] <Nick_Kaklanis> hey Colin!

[11:50:54 CDT(-0500)] <Nick_Kaklanis> Thank u!

[11:51:23 CDT(-0500)] <Nick_Kaklanis> I guess this is the place where I can find some help (smile)

[11:52:04 CDT(-0500)] <colinclark> yup

[11:54:24 CDT(-0500)] <Nick_Kaklanis> I got the template that Yura prepared and now I have it set up but I have one basic question: Currently, another match function has been defined (this of the RB-MM). Who decides when it is called? Should I change something in the MatchMaker.js to see it being executed?

[11:56:17 CDT(-0500)] <colinclark> I'm not sure I quite understand your question, Nick_Kaklanis

[11:56:23 CDT(-0500)] <colinclark> can you elaborate a little bit?

[11:57:24 CDT(-0500)] <yzen1> hi Nick_Kaklanis, sorry i was at someone else's desk

[11:57:50 CDT(-0500)] <Nick_Kaklanis> hi Yura

[11:58:42 CDT(-0500)] <yzen> Nick_Kaklanis: so when you say currently, you mean in the master branch or the branch that I emailed the link to last night ?

[12:00:42 CDT(-0500)] <yzen> Nick_Kaklanis: if you mean from my branch, all of the configuration is done in the config file for your custom match maker and here are the lines: https://github.com/yzen/universal/blob/e678dba1bbf5f29a478971e584073a83f24a20d4/gpii/node_modules/matchMaker/configs/ruleBased.json#L36-L41

[12:00:57 CDT(-0500)] <Nick_Kaklanis> I forked the master branch (from the first link you sent me) and I also got with copy-paste the 3 additional files you've added (found here:https://github.com/yzen/universal/commit/e678dba1bbf5f29a478971e584073a83f24a20d4)

[12:01:49 CDT(-0500)] <colinclark> So this is the line of configuration that determines the binding of the Matchmaker's match() function: https://github.com/yzen/universal/blob/e678dba1bbf5f29a478971e584073a83f24a20d4/gpii/node_modules/matchMaker/configs/ruleBased.json#L39

[12:01:50 CDT(-0500)] <yzen> so what this configuration says is whenever gpii framework will call gpii.matchMaker.match , if it is a rule based match maker it is using, actually call gpii.ruleBasedMatchMaker.match

[12:03:07 CDT(-0500)] <Nick_Kaklanis> Give me 1 min to take a look at these...

[12:06:48 CDT(-0500)] <yzen> Nick_Kaklanis: sure

[12:08:40 CDT(-0500)] <Nick_Kaklanis> so, who decides this: "if it is a rule based match maker it is using"? I mean there would be 3 matchmaking functions: 1)flat 2)statistical 3)rule-based. Who will decide which one from the 3 will be called?

[12:09:30 CDT(-0500)] <colinclark> Currently, it's decided by a configuration file

[12:09:38 CDT(-0500)] <Nick_Kaklanis> which one?

[12:09:51 CDT(-0500)] <colinclark> so that users can start up the system in "rule-based mode" or "statistical mode" and so on

[12:09:55 CDT(-0500)] <colinclark> The file you're looking at (wink)

[12:10:27 CDT(-0500)] <Nick_Kaklanis> so, I guess I had a totally wrong approach in my mind....

[12:10:33 CDT(-0500)] <Nick_Kaklanis> I thought the following:

[12:10:54 CDT(-0500)] <colinclark> In the future, this will potentially be determined by users at runtime, etc. But for now, it's via configuration at startup.

[12:13:38 CDT(-0500)] <Nick_Kaklanis> The rule-based MM will be used, in order to resolve ONLY the conflict situations...I mean...user prefs may say that user wants THIS and THAT...while the context doesn't not support this and that....Then the solution is coming from the RB-MM that proposes..."hmmmm you can't use THIS and THAT but you may use THHHIS and THHHAT instead" -> So, the RB-MM returns a new user prefs set that could

[12:13:38 CDT(-0500)] <Nick_Kaklanis> be handled directly from the flat matchmaker (while the initial user prefs set could not be handled due to the context limitations).

[12:16:05 CDT(-0500)] <colinclark> all of that can be set up if you'd like

[12:16:35 CDT(-0500)] <Justin_o> yzen: question about grades and demands.. if i have a grade and setup demands blocks against it, then use that grade in some component, will the demands resolve against this new component as well or not?

[12:16:36 CDT(-0500)] <colinclark> For now, I think the process would be to just go ahead and use the flat matchmaker directly.

[12:17:23 CDT(-0500)] <yzen> Justin_o: i think 1 demands block wins

[12:17:35 CDT(-0500)] <yzen> so you will get the demands for the actual component

[12:17:37 CDT(-0500)] <yzen> if you have them

[12:17:40 CDT(-0500)] <yzen> as far as i know

[12:17:46 CDT(-0500)] <yzen> Bosmon: would probably comment

[12:17:47 CDT(-0500)] <Justin_o> yzen: what if there aren't any?

[12:17:59 CDT(-0500)] <yzen> then i suspect yes

[12:18:01 CDT(-0500)] <colinclark> Nick_Kaklanis: So what you're describing, as far as I know, is perfectly possible.

[12:18:04 CDT(-0500)] <colinclark> yzen: Do you concur?

[12:18:04 CDT(-0500)] <Justin_o> yzen: okay.. thanks

[12:19:43 CDT(-0500)] <colinclark> If I understand it correctly, you'd have to do two things: 1. once your rule based matchmaker has run, use the ontology server to transform your synthesized preferences document into the necessary hierarchical format and then 2. invoke the flat matchmaker's match function

[12:19:46 CDT(-0500)] <yzen> colinclark: Nick_Kaklanis: i think so , so when you call match you get access to solutions and preferences. then original match runs a default strategy on it. You can then by comparing see what solutions where excluded and why

[12:20:04 CDT(-0500)] <colinclark> In a future release we can create a "matchmaking pipeline"

[12:23:30 CDT(-0500)] <Nick_Kaklanis> Perfect! (smile) Now, let's continue with some "programming things" to make it work. Sorry for wasting your time with many questions but the GPII is a chaos for me! Moreover, I'm not a Javascript developer....So, I agree with the 2 steps that Colin suggests. As a first step I put just a simple log at the beginning of the "ruleBasedMatchMaker.match" but I cann't see it in the console when I log

[12:23:30 CDT(-0500)] <Nick_Kaklanis> in with Sammy.

[12:23:49 CDT(-0500)] <colinclark> You're not wasting our time

[12:24:13 CDT(-0500)] <colinclark> I'm sorry you find it chaotic. We've built it in a way that it is very scalable and flexible, so there is some abstraction there that you'll have to learn

[12:24:21 CDT(-0500)] <colinclark> and sadly not a lot of documentation (sad)

[12:24:53 CDT(-0500)] <Nick_Kaklanis> If it was in C++/Java it would be much simpler for me (smile)

[12:25:15 CDT(-0500)] <colinclark> I think you'll find that JavaScript is really quite a nice language once you've learned it

[12:25:28 CDT(-0500)] <Nick_Kaklanis> I hope so... (smile)

[12:25:53 CDT(-0500)] <Nick_Kaklanis> So, can you imagine why I cannot see the log I've put in the beginning of the match function?

[12:26:15 CDT(-0500)] <colinclark> yzen: Any guesses?

[12:27:38 CDT(-0500)] <Nick_Kaklanis> Actually, the magnifier appears just like before the integration stuff...

[12:27:51 CDT(-0500)] <yzen> Nick_Kaklanis: if you saw that commit in my branch, i had a log in there working

[12:28:07 CDT(-0500)] <yzen> Nick_Kaklanis: are you doing something similar, perhaps you can paste it somewhere?

[12:28:45 CDT(-0500)] <Nick_Kaklanis> I just took the 3 files you had in the commit. Let me check again...

[12:33:28 CDT(-0500)] <yzen> Nick_Kaklanis: it might be slightly hard to see as I forgot to add the new line at the end, you should be able to see "RULE BASED MATCH MAKER MATCH IS USED"

[12:33:44 CDT(-0500)] <yzen> Nick_Kaklanis: one thing I should mentioned that I forgot though

[12:34:30 CDT(-0500)] <yzen> in order to run just your matchmaker configuration you need to run it this way : NODE_ENV=ruleBased node gpii/node_modules/gpiiFramework/init.js gpii/node_modules/matchMaker/configs/

[12:34:46 CDT(-0500)] <colinclark> aha!

[12:34:50 CDT(-0500)] <colinclark> that's probably important (smile)

[12:35:04 CDT(-0500)] <yzen> colinclark: Nick_Kaklanis I ll follow up on on mail list about it

[12:35:20 CDT(-0500)] <Nick_Kaklanis> that would be my next question: "who uses this config...?" (smile)

[12:36:04 CDT(-0500)] <Nick_Kaklanis> ok Colin

[12:37:49 CDT(-0500)] <yzen> Nick_Kaklanis: here's a readme of how to start up the match maker instance https://github.com/yzen/universal/blob/RuleBasedMatchMaker/gpii/node_modules/matchMaker/README.md

[12:39:13 CDT(-0500)] <colinclark> In your example, yzen, did it include how to turn off the ontology transform?

[12:39:58 CDT(-0500)] <Nick_Kaklanis> thanks Yura! I'm trying to make a "stard_ruleBased.cmd" using the above (I'm running on windows)

[12:40:45 CDT(-0500)] <jessm> anastasiac: slight modification to my "ship it" email about the booking PDF

[12:40:50 CDT(-0500)] <yzen> Nick_Kaklanis: np

[12:40:50 CDT(-0500)] <jessm> apparently we don't take amex

[12:40:53 CDT(-0500)] <jessm> who knew?

[12:41:37 CDT(-0500)] <yzen> colinclark: no , i talked to kasper_ about it he said it is not necessary anymore as the custom matchmaker can parse those settings now

[12:41:40 CDT(-0500)] <anastasiac> jessm, we'll have to get joanna to update the PDF

[12:42:17 CDT(-0500)] <jessm> anastasiac: roger that

[12:42:27 CDT(-0500)] <jessm> anastasiac: can you relay that to her?

[12:42:36 CDT(-0500)] <anastasiac> in process, jessm (smile)

[12:42:42 CDT(-0500)] <jessm> yay

[12:46:50 CDT(-0500)] <Nick_Kaklanis> NODE_ENV is not recognized. I've also added a "NODE_ENV" environmental variable in my system but...no luck. What am I missing?

[12:49:40 CDT(-0500)] <kasper_> Nick_Kaklanis: have you restarted the console?

[12:49:46 CDT(-0500)] <kasper_> if you're on windows try doing an:

[12:49:48 CDT(-0500)] <Nick_Kaklanis> yeap

[12:49:53 CDT(-0500)] <kasper_> echo %NODE_ENV%

[12:49:59 CDT(-0500)] <kasper_> just to make sure it's proper set

[12:50:32 CDT(-0500)] <Nick_Kaklanis> it types ruleBased

[12:50:40 CDT(-0500)] <Nick_Kaklanis> so it is set correct

[12:50:44 CDT(-0500)] <kasper_> ok

[12:52:25 CDT(-0500)] <Nick_Kaklanis> F:\IPTHL\CLOUD4ALL\Setting_up_GPII\gpii\node_modules\universal>NODE_ENV=ruleBased node gpii/node_modules/gpiiFramework/init.js gpii/node_modules/matchMaker/configs/

[12:52:25 CDT(-0500)] <Nick_Kaklanis> 'NODE_ENV' is not recognized as an internal or external command,

[12:52:26 CDT(-0500)] <Nick_Kaklanis> operable program or batch file.

[12:55:48 CDT(-0500)] <Nick_Kaklanis> I've removed the "NODE_ENV=ruleBased" from the beginning and now it runs.

[12:56:27 CDT(-0500)] <kasper_> hmm... try: SET NODE_ENV=ruleBased node gpii/node_modules/gpiiFramework/init.js gpii/node_modules/matchMaker/configs/

[12:56:43 CDT(-0500)] <kasper_> well.. that might not work.. gimme a sec

[12:57:57 CDT(-0500)] <Nick_Kaklanis> It doesn't

[12:58:44 CDT(-0500)] <kasper_> btw.. usually one would start it with: node gpii.js

[12:58:53 CDT(-0500)] <kasper_> and not node gpii/node_modules/gpiiFramework/init.js

[12:58:56 CDT(-0500)] <Nick_Kaklanis> actually why do I need the NODE_ENV in the beginning? I've set it in my environment variable as "ruleBased". However, it runs without using the ruleBased matching!

[13:01:10 CDT(-0500)] <Nick_Kaklanis> yes....as it is in "start.cmd". But when I use this, the rulebased matching is not used. Actually, it enables the magnifier.

[13:04:15 CDT(-0500)] <kasper_> I think you should stick to using that, to make sure that the framework is proper started ect

[13:04:31 CDT(-0500)] <kasper_> the magnifier enabling is prob. due to the flat matchmaker being used

[13:04:37 CDT(-0500)] <kasper_> Nick_Kaklanis ^

[13:04:42 CDT(-0500)] <Nick_Kaklanis> yes, but why?

[13:04:48 CDT(-0500)] <kasper_> why what?

[13:04:49 CDT(-0500)] <kasper_> (smile)

[13:05:13 CDT(-0500)] <kasper_> why it's not run?

[13:05:26 CDT(-0500)] <kasper_> can you try setting the NODE_ENV to "fm.ps.sr.dr.mm.os.production"

[13:05:45 CDT(-0500)] <Nick_Kaklanis> why the rule based matching function is not called even when I have "NODE_ENV=ruleBased" in the environment variables? how can I test my integration?

[13:05:55 CDT(-0500)] <kasper_> checking that it's properly set in your console by tying: echo %NODE_ENV%

[13:06:01 CDT(-0500)] <kasper_> then start gpii normally

[13:06:07 CDT(-0500)] <kasper_> like: node gpii.js

[13:06:38 CDT(-0500)] <kasper_> if that starts up the server, the NODE_ENV is being read properly by the node/gpii env

[13:06:55 CDT(-0500)] <kasper_> ooops, should have said: if that starts up the server with logging disabled

[13:06:57 CDT(-0500)] <kasper_> Nick_Kaklanis: ^

[13:10:25 CDT(-0500)] <Nick_Kaklanis> maybe something is wrong with the paths... -> F:\IPTHL\CLOUD4ALL\Setting_up_GPII\gpii\windows>node gpii.js

[13:10:25 CDT(-0500)] <Nick_Kaklanis> fs.js:338

[13:10:25 CDT(-0500)] <Nick_Kaklanis> return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);

[13:10:25 CDT(-0500)] <Nick_Kaklanis> ^

[13:10:25 CDT(-0500)] <Nick_Kaklanis> Error: ENOENT, no such file or directory 'F:\IPTHL\CLOUD4ALL\Setting_up_GPII\gpii\node_modules\universal\gpii\configs\ruleBased node gpii\node_modules\gpiiFramework\init.js gpii\node_modules\matchMaker\configs\.json'

[13:11:47 CDT(-0500)] <kasper_> yeah something defintely looks wrong there

[13:12:09 CDT(-0500)] <kasper_> can you tell me what you NODE_ENV is when you get the above?

[13:12:25 CDT(-0500)] <Nick_Kaklanis> I call it from the dir that inlcudes "start.cmd" for windows

[13:12:53 CDT(-0500)] <kasper_> Nick_Kaklanis: btw, if you write the name of a person (eg. kasper_) that person will get a notification .. that way I'll see it when you write me

[13:13:04 CDT(-0500)] <kasper_> Nick_Kaklanis: that's the correct place to call it from

[13:13:18 CDT(-0500)] <kasper_> and what does: echo %NODE_ENV% give you

[13:13:31 CDT(-0500)] <kasper_> ?

[13:14:09 CDT(-0500)] <Nick_Kaklanis> kasper_ F:\IPTHL\CLOUD4ALL\Setting_up_GPII\gpii\windows>echo %NODE_ENV%

[13:14:09 CDT(-0500)] <Nick_Kaklanis> ruleBased node gpii/node_modules/gpiiFramework/init.js gpii/node_modules/matchMaker/configs/

[13:14:36 CDT(-0500)] <kasper_> ok, so that's definitely wrong .. question is what it's supposed to be

[13:14:37 CDT(-0500)] <kasper_> sec...

[13:14:52 CDT(-0500)] <Nick_Kaklanis> ohhhhhhhhhhhh

[13:15:13 CDT(-0500)] <Nick_Kaklanis> remember what you told me to try before???? SET....blah blah

[13:15:17 CDT(-0500)] <Nick_Kaklanis> this done it!

[13:16:04 CDT(-0500)] <kasper_> yeah (smile)

[13:16:26 CDT(-0500)] <Nick_Kaklanis> kasper_: let me try another time with a new console (smile)

[13:16:47 CDT(-0500)] <kasper_> else you can just set it again: SET NODE_ENV="blabla"

[13:19:09 CDT(-0500)] <kasper_> ok, if first you make sure that NODE ENV is just: "ruleBased"

[13:19:28 CDT(-0500)] <kasper_> and then go back to running: node gpii/node_modules/gpiiFramework/init.js gpii/node_modules/matchMaker/configs/

[13:21:21 CDT(-0500)] <Nick_Kaklanis> kasper_: now NODE_ENV is ruleBased but..... -> F:\IPTHL\CLOUD4ALL\Setting_up_GPII\gpii\windows>node gpii

[13:21:21 CDT(-0500)] <Nick_Kaklanis> fs.js:338

[13:21:21 CDT(-0500)] <Nick_Kaklanis> return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode); ^

[13:21:21 CDT(-0500)] <Nick_Kaklanis> Error: ENOENT, no such file or directory 'F:\IPTHL\CLOUD4ALL\Setting_up_GPII\gpii\node_modules\universal\gpii\configs\ruleBased.json'

[13:21:47 CDT(-0500)] <kasper_> well.. that's getting closer

[13:21:51 CDT(-0500)] <Nick_Kaklanis> (smile)

[13:21:57 CDT(-0500)] <kasper_> so what happens if you do:

[13:22:07 CDT(-0500)] <kasper_> cd F:\IPTHL\CLOUD4ALL\Setting_up_GPII\gpii\node_modules\universal\gpii\configs{color}

[13:24:09 CDT(-0500)] <Nick_Kaklanis> kasper_: it has "fm.ps.sr.dr.mm.os.development.json", "fm.ps.sr.dr.mm.os.production.json", "ps.sr.development.json" and "ps.sr.production.json". The rulebased for which it complains is in another folder

[13:25:05 CDT(-0500)] <kasper_> well, so at least we're getting closer (smile)

[13:25:13 CDT(-0500)] <Nick_Kaklanis> it is here: F:\IPTHL\CLOUD4ALL\Setting_up_GPII\gpii\node_modules\universal\gpii\node_modules\matchMaker\configs

[13:26:27 CDT(-0500)] <kasper_> ok, this is all russian to me ... think we'll need yura to enlighten us (smile)

[13:26:47 CDT(-0500)] <Nick_Kaklanis> not here...

[13:27:13 CDT(-0500)] <Nick_Kaklanis> kasper_ it's all Greek to me even if I'm Greek (smile)

[13:27:23 CDT(-0500)] <kasper_> hehe

[13:28:37 CDT(-0500)] <Nick_Kaklanis> kasper_: as it is 20:30 here and I'm at the office from 09:00....will you be here tomorrow?

[13:28:56 CDT(-0500)] <kasper_> yeah - probably .. got a ton of windows implementation still pending

[13:29:16 CDT(-0500)] <Nick_Kaklanis> around what time (cet)?

[13:29:35 CDT(-0500)] <kasper_> if I see yura online later tonight I'll ask him to check the IRC log to see if what you're experiencing makes any sense

[13:30:41 CDT(-0500)] <Nick_Kaklanis> ok thanks! and another thing: is it possible to have access to the "device" object in my matching function? I need it for the rules.

[13:31:48 CDT(-0500)] <kasper_> yeah, I think that'll be taken care of by yura's code as well

[13:31:52 CDT(-0500)] <colinclark> yes, I believe so

[13:32:02 CDT(-0500)] <colinclark> he certainly mentioned that it was in the example he sent to Andy

[13:32:17 CDT(-0500)] <kasper_> anyway, not sure about when I'll be here tomorrow - probably from 11am and onwards

[13:32:25 CDT(-0500)] <Nick_Kaklanis> Yura's code includes: ruleBasedMatchMaker.match = function (preferences, solutions, strategy) {

[13:32:27 CDT(-0500)] <colinclark> tmoorrow's saturday

[13:32:32 CDT(-0500)] <Nick_Kaklanis> so, the device is not included

[13:32:41 CDT(-0500)] <colinclark> you working all weekend, kasper_?

[13:32:53 CDT(-0500)] <kasper_> colinclark: yeah, I think so

[13:32:58 CDT(-0500)] <colinclark> (sad)

[13:33:46 CDT(-0500)] <kasper_> I got some friends visiting mon-thurs next week, and am trying to avoid continuing my 14 hours day then (smile)

[13:33:59 CDT(-0500)] <colinclark> His example here includes it: https://github.com/yzen/universal/commit/51d7b5b9ad082d29ad17d700fd6911b4baa3e7d8

[13:34:13 CDT(-0500)] <colinclark> I'm on a conference call, but I'll try to point out the area where it is configured for you, Nick_Kaklanis

[13:35:12 CDT(-0500)] <colinclark> I believe the key piece of configuration is here: https://github.com/yzen/universal/commit/51d7b5b9ad082d29ad17d700fd6911b4baa3e7d8#L0R40

[13:35:26 CDT(-0500)] <Nick_Kaklanis> thank you colinclark! (smile) Andy had more luck!

[13:35:28 CDT(-0500)] <colinclark> And here: https://github.com/yzen/universal/commit/51d7b5b9ad082d29ad17d700fd6911b4baa3e7d8#L2R16

[13:35:49 CDT(-0500)] <colinclark> Whereas you'll notice that in the example Yura set up for you, there's one fewer argument configured: https://github.com/yzen/universal/commit/e678dba1bbf5f29a478971e584073a83f24a20d4#L0R40

[13:36:37 CDT(-0500)] <colinclark> So you'll notice he's taking the request's body and passing it as an argument to the match function on that line

[13:36:50 CDT(-0500)] <colinclark> and the body should be the whole solutions registry document

[13:37:13 CDT(-0500)] <colinclark> So you'll notice that the device information is accessed on this line: https://github.com/yzen/universal/commit/51d7b5b9ad082d29ad17d700fd6911b4baa3e7d8#L2R19

[13:37:28 CDT(-0500)] <colinclark> This, in the next release, will be done automatically for you

[13:37:40 CDT(-0500)] <colinclark> but in the meantime, this should be a reasonable workaround

[13:38:11 CDT(-0500)] <Nick_Kaklanis> (smile) thanks Colin!

[13:38:15 CDT(-0500)] <colinclark> This is the great power of our configuration-based approach

[13:38:29 CDT(-0500)] <colinclark> if you don't like how we have wired things up, you can change it without having to modify any code!

[13:38:46 CDT(-0500)] <colinclark> It makes it more complex, admittedly

[13:38:47 CDT(-0500)] <colinclark> right, kasper_?

[13:38:48 CDT(-0500)] <colinclark> but that will improve with time

[13:38:51 CDT(-0500)] <colinclark> and we're going to write a lot of documentation for it

[13:39:18 CDT(-0500)] <kasper_> hehe, indeed colinclark (big grin)

[13:39:22 CDT(-0500)] <Nick_Kaklanis> nice! as I'm new to it...it's a nightmare for me but I think it will get better! (smile)

[13:39:29 CDT(-0500)] <colinclark> I promise it will

[13:39:35 CDT(-0500)] <colinclark> And you can always ask on list or here

[13:39:41 CDT(-0500)] <colinclark> I'm sorry that we've sometimes been slow to respond to emails

[13:39:43 CDT(-0500)] <colinclark> we've been so busy!

[13:39:50 CDT(-0500)] <colinclark> but we're here and will respond asap

[13:40:17 CDT(-0500)] <Nick_Kaklanis> If I knew about IRC I wouldn't have missed hours and hours searching in wrong places inside GPII....

[13:40:38 CDT(-0500)] <Nick_Kaklanis> but at least now I found u! (smile)

[13:42:43 CDT(-0500)] <Nick_Kaklanis> I'm soooo tired that I cannot continue developing right now. See you tomorrow! Thank you very much for your valuable help! Bye-bye!

[14:01:22 CDT(-0500)] <michelled> hi Bosmon

[14:01:32 CDT(-0500)] <Bosmon> Hey, michelled

[14:01:34 CDT(-0500)] <michelled> I'm starting to look at your pull request for 4921

[14:01:39 CDT(-0500)] <Bosmon> Thanks

[14:01:48 CDT(-0500)] <michelled> you mentioned in one of your commits that you sorted the all tests file in order of dependency

[14:01:55 CDT(-0500)] <michelled> that seems odd to me

[14:02:00 CDT(-0500)] <Bosmon> michelled - why does it seem odd?

[14:02:02 CDT(-0500)] <michelled> are there dependencies between the tests?

[14:02:13 CDT(-0500)] <Bosmon> michelled - there are dependencies between the things they test (smile)

[14:02:31 CDT(-0500)] <Bosmon> Given a test fails FIRST for a thing which other things are dependent on, you would logically look at that test failure first

[14:02:36 CDT(-0500)] <Bosmon> Since a later test failure might be caused by the same bug

[14:02:44 CDT(-0500)] <michelled> ah, makes sense

[14:02:45 CDT(-0500)] <michelled> thanks

[14:02:49 CDT(-0500)] <Bosmon> np (smile)

[14:03:59 CDT(-0500)] <Justin_o> Bosmon: hello.. I've started to re-work on the UIO presentation stuff

[14:04:04 CDT(-0500)] <Justin_o> i've created a new branch

[14:04:15 CDT(-0500)] <Justin_o> here's the diff https://github.com/jobara/infusion/compare/master...FLUID-4927-b

[14:04:22 CDT(-0500)] <Justin_o> does that look to be more on the right track

[14:04:48 CDT(-0500)] <Bosmon> Justin_o - not entirely

[14:04:55 CDT(-0500)] <Bosmon> It seems that the ants are now duplicated in all of the integrations

[14:05:00 CDT(-0500)] <Bosmon> That seems like a backward step

[14:05:12 CDT(-0500)] <Bosmon> You should make a separate grade to contain them which can be reused

[14:05:23 CDT(-0500)] <Justin_o> Bosmon: yes.. that will be another step..

[14:05:27 CDT(-0500)] <Bosmon> ok cool

[14:06:14 CDT(-0500)] <Justin_o> Bosmon: should the grade just contain the extra configuration, that being the panels and selectors that are common?

[14:06:19 CDT(-0500)] <Justin_o> i guess that should suffice

[14:06:42 CDT(-0500)] <Bosmon> Justin_o - yes, it will just be an "extra ants" grade

[14:06:59 CDT(-0500)] <Justin_o> Bosmon: also had been talking to cindyli about different ways in which these things could be changed by an integrator

[14:07:30 CDT(-0500)] <Bosmon> Justin_o - yes - do bear in mind that before too long at all, we will construct a "UIOptionsBuilder" that will do this automatically, based on a "schema structure"

[14:08:16 CDT(-0500)] <Bosmon> I have comments to this effect on cindy's branch

[14:08:19 CDT(-0500)] <Justin_o> Bosmon: i'm assuming that we would add a grade of "extra ants" to fluid.uiOptions.fatPanel for example. how would a user change that

[14:08:23 CDT(-0500)] <Justin_o> Bosmon: okay

[14:09:26 CDT(-0500)] <Bosmon> Justin_o - the issues of "ant content" and "integration style" are orthogonal

[14:10:08 CDT(-0500)] <Bosmon> We will allow free mixins from both sides - I imagine we will construct a "fatPanelWithOldAnts" etc. just to preserve our old test cases and to show how it is done

[14:11:02 CDT(-0500)] <Justin_o> Bosmon: could we then either have "extra ants" take in "fluid.uiOptions" as a grade, or else provide "extra ants" as a gradeName to UIO when it is used

[14:11:13 CDT(-0500)] <Justin_o> and needs those ants, for example in our implementation of one of the views

[14:11:24 CDT(-0500)] <Bosmon> Justin_o - the latter, I think

[14:12:27 CDT(-0500)] <Justin_o> okay.. cool.. so i could, then, in fatPanelUIOptions.js file in the defaults for fatPanel specify the extra ants grade there, or were you thinking it would be done somewhere else and the fatPanel would also be empty

[14:12:47 CDT(-0500)] <Justin_o> in it's use of UIO that is

[14:12:47 CDT(-0500)] <Bosmon> Justin_o - yes, we need to deliver "empty" versions of everything

[14:13:10 CDT(-0500)] <Justin_o> Bosmon: okay.. so the test and demos for now would add the "extra ants" grades

[14:13:27 CDT(-0500)] <Bosmon> Although fatPanel itself of course didn't actually "contain" anything - but it did reference something which brought things in

[14:13:44 CDT(-0500)] <Bosmon> Our aim is always to absolutely minimise the configuration duplicated used by our integrators across all scenarios

[14:13:45 CDT(-0500)] <Justin_o> Bosmon: yes.. so i suppose we could do this with demands

[14:14:01 CDT(-0500)] <Bosmon> So in each case it should be as simple as supplying one extra gradeName to an integration's configuration

[14:14:09 CDT(-0500)] <Bosmon> Justin_o - what context name would you issue the demands against?

[14:14:33 CDT(-0500)] <Justin_o> Bosmon: in the case where we want this just for demos and tests. we could have contexts set for those

[14:14:48 CDT(-0500)] <Justin_o> but an integrator would have to do something to get it in for themselves

[14:15:53 CDT(-0500)] <Justin_o> Bosmon: i'm assuming when you say "So in each case it should be as simple as supplying one extra gradeName to an integration's configuration" that you mean they would drill down to the UI Options subcomponent and in the options for it, add the extra grade name

[14:16:06 CDT(-0500)] <Justin_o> or do so with demands

[14:16:10 CDT(-0500)] <Bosmon> Justin_o - Right now that would be the way us - unless we wrote some "luke Skywalker configuration" for it

[14:16:30 CDT(-0500)] <Justin_o> Bosmon: okay, and this will be manually done in the tests and demos

[14:16:36 CDT(-0500)] <Bosmon> I think we should start to consider the use of demands as more restricted only to the original use case

[14:16:42 CDT(-0500)] <Bosmon> In the "old framework" we didn't have many design options

[14:16:56 CDT(-0500)] <Bosmon> But "demands blocks" are really intended for "adaptation", not for "configuration"

[14:17:12 CDT(-0500)] <Bosmon> That is, you would use a demands block where you expect an implementation to be variable depending on its context

[14:17:28 CDT(-0500)] <Justin_o> Bosmon: i guess i'm not totally clear on the difference between adaption and configuration

[14:17:42 CDT(-0500)] <Bosmon> Now we have things like dynamic gradeNames and IoCSS, there are many more options to just express "behaviour based on configuration"

[14:17:58 CDT(-0500)] <Bosmon> And I anticipate our use of demands blocks to be less

[14:18:08 CDT(-0500)] <Bosmon> Ironically, just as they themselves got fixed and are more usable : P

[14:18:09 CDT(-0500)] <Justin_o> Bosmon: but couldn't you consider just about anything a context.. test environment, vs demo environment and etc.

[14:18:17 CDT(-0500)] <Justin_o> or maybe i'm being too liberal with the term

[14:18:27 CDT(-0500)] <Justin_o> (smile)

[14:18:29 CDT(-0500)] <Bosmon> Justin_o - the environment is a context, yes

[14:18:38 CDT(-0500)] <Bosmon> but "The user wants the following three ants" is not a context

[14:18:52 CDT(-0500)] <Justin_o> Bosmon: but the user wants them in the demo and tests

[14:19:03 CDT(-0500)] <Bosmon> Also "We are using the FatPanel integration" is not a context

[14:19:04 CDT(-0500)] <Justin_o> Bosmon: but i guess we need to show them some other ways of wiring them up

[14:19:22 CDT(-0500)] <Bosmon> Well, it MIGHT be a context - if something had to react to it

[14:19:37 CDT(-0500)] <Justin_o> Bosmon: i more meant a demand like i'm in the tests.. give uio the grade name extra ants

[14:19:38 CDT(-0500)] <Bosmon> But we should never do through demands blocks which we could perfectly easily achieve by containment structure and configuration

[14:19:54 CDT(-0500)] <Bosmon> Justin_o - what would this demands in the tests do?

[14:20:06 CDT(-0500)] <Justin_o> Bosmon: well provide integration tests for those ants (smile)

[14:20:37 CDT(-0500)] <Bosmon> Justin_o - you mean, by slotting in an IoC "TestCaseHolder"?

[14:21:06 CDT(-0500)] <Justin_o> but okay.. i just want to make sure that i don't need to write up some component fixture that has the ants and one that doesn't.. we expect that the integrator as well as ourselves will have to add that grade when we want them

[14:28:10 CDT(-0500)] <Justin_o> Bosmon: so, just to be clear. we want in our code uiOptions and all it's flavours to be empty.. When they are used by integrators, demos, tests, then we can optionally specify an "extra ants" grade to pull in all the currently default settings.. or else they could be added manually with subcomponents and etc. Is that correct?

[14:28:40 CDT(-0500)] <Bosmon> Justin_o - that's right

[14:29:41 CDT(-0500)] <Justin_o> Bosmon: okay.. cool.. i'll implement it like that

[14:29:49 CDT(-0500)] <Bosmon> Justin_o: cool (smile)

[14:31:56 CDT(-0500)] <Justin_o> cindyli: did you come up with a name for your default enactors grade.. we should probably keep them similar

[14:34:00 CDT(-0500)] <cindyli> Justin_o: i'm thinking of something like UIEDefaultCollection

[14:35:19 CDT(-0500)] <Justin_o> cindyli: I was thinking of UIODefaultPreferenceSettings but that may be too general for both of ours

[14:35:31 CDT(-0500)] <Justin_o> cindyli: so maybe UIODefaultSettingsPanels

[14:36:09 CDT(-0500)] <cindyli> ok, Justin_o, then perhaps I should call mine UIEDefaultActions (smile)

[14:36:26 CDT(-0500)] <Justin_o> cindyli: i like that

[14:36:38 CDT(-0500)] <cindyli> nice. thanks

[14:38:25 CDT(-0500)] <Justin_o> actually I'm going to rename mine a bit since i'll just use the fluid.uiOptions namespace and call it fluid.uiOptions.defaultSettingsPanels

[14:38:41 CDT(-0500)] <Justin_o> it's long i guess

[14:39:19 CDT(-0500)] <cindyli> make sense. will do same to UIE

[14:39:38 CDT(-0500)] <Justin_o> cindyli: cool

[14:39:55 CDT(-0500)] <Justin_o> Bosmon: question about the grade.. if it is only for merging options in, do i still need to specify gradeNames?

[14:48:34 CDT(-0500)] <Bosmon> Justin_o - it's a good question

[14:48:52 CDT(-0500)] <Bosmon> For example, I find myself leaving "autoInit" out of gradeName lists which I believe never will or can be instantiated

[14:49:13 CDT(-0500)] <Bosmon> Which does leave some questions about our hypothetical plan to make "autoInit" the default for all future components : P

[14:49:42 CDT(-0500)] <Bosmon> And naturally you can leave out any other things which you believe are inessential because the user can't avoid having them already

[14:50:00 CDT(-0500)] <Bosmon> But you may as well put in things which have some "documentation value" in making it clearer how your grade can be used

[14:51:17 CDT(-0500)] <Justin_o> Bosmon: you mean just add some comments?

[14:51:33 CDT(-0500)] <Bosmon> Justin_o - no, I mean add in some grade names (smile)

[14:51:39 CDT(-0500)] <Justin_o> Bosmon: ah okay

[14:51:52 CDT(-0500)] <Bosmon> If your grade can ONLY be used in conjunction with some other grades, you may as well put them in

[14:52:02 CDT(-0500)] <Justin_o> Bosmon: also do gradeNames merge or overwrite

[14:52:35 CDT(-0500)] <Justin_o> Bosmon: how would that work though in this case since this is adding to a different grade as opposed to the other way around

[14:53:26 CDT(-0500)] <Bosmon> Justin_o - gradeNames always merge

[14:53:42 CDT(-0500)] <Bosmon> A gradeName, once added to a hierarchy, can never be removed

[14:55:25 CDT(-0500)] <Justin_o> Bosmon: okay.. good to know.. my second comment there was actually in regards to your previous comment.. which is to say.. how can I add gradeNames to my "extra ants" grade when it is just supposed to be adding stuff to another grade

[14:55:40 CDT(-0500)] <Bosmon> Justin_o - could you sketch an example here?

[14:55:43 CDT(-0500)] <Justin_o> since i'll use it in UIO, i wouldn't want to add uio as a grade for it

[14:55:50 CDT(-0500)] <Justin_o> sure.. i'll put something in a pastie

[14:56:06 CDT(-0500)] <Bosmon> Justin_o - I was suggesting in response to your first comment that it might be relevant to your first comment

[14:56:19 CDT(-0500)] <Bosmon> That is, you might "add UIO as a grade to it" if it had some documentation value

[14:56:27 CDT(-0500)] <Bosmon> But it might not be helpful

[14:56:43 CDT(-0500)] <Justin_o> Bosmon: okay.. well i'll make the sketch anyways, might help to tease that out

[14:57:16 CDT(-0500)] <Bosmon> Justin_o - thanks

[14:58:25 CDT(-0500)] <Justin_o> Bosmon: http://pastie.org/6547675

[14:59:33 CDT(-0500)] <Bosmon> Justin_o - this seems reasonable

[15:00:00 CDT(-0500)] <Bosmon> But it seems SOMEONE's job to write the gradeName for uiOptions itself

[15:00:06 CDT(-0500)] <Bosmon> And it doesn't matter if it happens in two places

[15:01:30 CDT(-0500)] <Justin_o> Bosmon: so you mean it would be fine to give "fluid.uiOptions.defaultSettingsPanels" a grade of uiOptions even though uiOptions itself will use that as a grade

[15:01:51 CDT(-0500)] <Bosmon> Justin_o - it wouldn't hurt, no

[15:02:00 CDT(-0500)] <Bosmon> We could decide on a convention for when such things are useful

[15:02:04 CDT(-0500)] <Justin_o> Bosmon: that't wouldn't cause any infinite recursion?

[15:02:08 CDT(-0500)] <Bosmon> no

[15:02:20 CDT(-0500)] <Bosmon> Grades are merged together and any duplicates are discarded

[15:02:31 CDT(-0500)] <Justin_o> Bosmon: ah okay..

[15:03:49 CDT(-0500)] <Justin_o> Bosmon: gotta run, i'll pick this up again on monday.. thanks for the help

[15:04:49 CDT(-0500)] <Bosmon> By means of this new MERGEPOLICY!

[15:04:50 CDT(-0500)] <Bosmon> https://github.com/amb26/infusion/blob/FLUID-4921/src/webapp/framework/core/js/Fluid.js#L1191-L1195

[15:05:11 CDT(-0500)] <Bosmon> Justin_o - thanks for your questions - I will see you during the week

[15:35:45 CDT(-0500)] <avtar> fluid-everyone: if you're using os x this update https://support.apple.com/kb/HT5672 is probably worth installing sooner than later

[15:36:03 CDT(-0500)] <avtar> "Visiting a maliciously crafted website could allow a Java Web Start application to be launched automatically even if the Java plug-in is disabled"

[15:36:04 CDT(-0500)] <avtar> :/