Skip to end of metadata
Go to start of metadata

[07:07:43 CDT(-0500)] <gserra> hi all!

[07:08:43 CDT(-0500)] <gserra> I'd like to ask you some help

[07:08:57 CDT(-0500)] <gserra> about doubts in nodejs eventemitters

[07:15:53 CDT(-0500)] <gserra> hi

[07:24:26 CDT(-0500)] <gserra> hi

[07:50:21 CDT(-0500)] <yzen> kasper_: gserra hi

[07:50:30 CDT(-0500)] <kasper_> hey yura

[07:50:39 CDT(-0500)] <kasper_> gserra: I called for backup (smile)

[07:51:06 CDT(-0500)] <yzen> so gserra as far as your example, you are expect onNewData to fire repeatedly right ?

[07:51:18 CDT(-0500)] <gserra> yes

[07:51:34 CDT(-0500)] <gserra> every new data going through sensor api

[07:52:06 CDT(-0500)] <gserra> https://github.com/mabuse/Cloud4All---Context-Aware-Server/blob/master/routes/sensor.js

[07:52:38 CDT(-0500)] <gserra> then it emits different signals depending on configuration of the sensor or base (stored in the redis database)

[07:53:20 CDT(-0500)] <yzen> which will result in a new that.config assignment here https://github.com/mabuse/Cloud4All---Context-Aware-Server/blob/master/utils/triggers.js#L31 ?

[07:53:46 CDT(-0500)] <gserra> exactly

[07:53:49 CDT(-0500)] <yzen> so as far as i can tell this is tricky (smile)

[07:53:56 CDT(-0500)] <gserra> every new data first gets its configuration

[07:54:02 CDT(-0500)] <kasper_> yzen: lol

[07:54:08 CDT(-0500)] <kasper_> morning colinclark

[07:54:12 CDT(-0500)] <gserra> and then depending on the sensor configuration it emits some events or another events

[07:54:14 CDT(-0500)] <yzen> config is not a prototype method

[07:54:31 CDT(-0500)] <colinclark> morning, kasper_

[07:54:39 CDT(-0500)] <yzen> so when you call config i dont thing this is actually a SensorTrigger object

[07:55:01 CDT(-0500)] <gserra> where are you?

[07:55:04 CDT(-0500)] <gserra> in which line

[07:55:25 CDT(-0500)] <yzen> gserra: oh ya i see now , sorry, i m looking at callback

[07:55:28 CDT(-0500)] <yzen> there's not this

[07:55:28 CDT(-0500)] <gserra> now all is working properly (it passes ol the tests)

[07:55:48 CDT(-0500)] <gserra> and I asked even in stack overflow (smile)

[07:55:56 CDT(-0500)] <gserra> http://stackoverflow.com/questions/15384349/nodejs-events-prototyping-and-its-scope-using-that-this

[07:56:48 CDT(-0500)] <yzen> gserra: ya kasper_ gave me the link. so that.config will be overridden for every new event but that itself will be the same

[07:58:18 CDT(-0500)] <gserra> yep, the question here is if there is a request, it gets the config and the emits some signal AND just afterwards there is another request and gets its config, I am worried that the listener of the first request can have the seconf that.config instead of the first that.config

[07:58:57 CDT(-0500)] <gserra> For now it does not happen. My idea is to avoid having to pass all the parameteres in the function

[08:00:10 CDT(-0500)] <yzen> gserra: ya i think that might happen

[08:01:01 CDT(-0500)] <gserra> the question is the scope of the listener. Will it use the "old" that.config or the "new" that.config?

[08:02:06 CDT(-0500)] <gserra> another way could be create every request a new SensorTrigger object

[08:02:43 CDT(-0500)] <yzen> gserra: so for a single instance of SensorTrigger there's only 1 config at any time, so if getSensorConfig is called more than once it will refer to the last updated value at all times

[08:03:53 CDT(-0500)] <gserra> what would you propose? passing all parameters to function? or create for every request a new SensorTrigger object?

[08:06:56 CDT(-0500)] <yzen> gserra: i think what you mentioned first - having a sensor trigger for each request

[08:07:57 CDT(-0500)] <gserra> Ok. I will do that and tell you if all is working

[08:08:32 CDT(-0500)] <yzen> gserra: let me know, interesting problem though (smile)

[08:09:39 CDT(-0500)] <kasper_> thanks yzen for looking at this

[08:09:47 CDT(-0500)] <gserra> thank you all!

[08:09:55 CDT(-0500)] <gserra> I'll keep you informed

[08:10:18 CDT(-0500)] <gserra> I am a newbie in javascript and I am not so confident

[08:10:40 CDT(-0500)] <kasper_> gserra: it was tricky stuff

[08:11:06 CDT(-0500)] <gserra> I think that having an object for every call would be the best solution. Much more sanitized

[08:11:34 CDT(-0500)] <gserra> Yep, tricky because I couldn't prove that it could break

[08:12:33 CDT(-0500)] <gserra> it is only a guess. My fear was that the callback from redis database for getting the sensor data lasted too much and then the that.config was changed to the new request. But I couldn't prove it

[08:12:48 CDT(-0500)] <gserra> Anyway, I'll change it

[08:12:52 CDT(-0500)] <gserra> bye!

[08:13:14 CDT(-0500)] <kasper_> coolio! see you later gserra

[08:13:35 CDT(-0500)] <yzen> gserra: tty soon

[09:12:58 CDT(-0500)] <gserra> hi all! It's me again. I've already changed to new object every request and is working perfectly

[09:13:05 CDT(-0500)] <gserra> thanks again

[09:50:32 CDT(-0500)] <colinclark> hey yzen1

[09:50:36 CDT(-0500)] <colinclark> how's it going?

[09:51:35 CDT(-0500)] <yzen> colinclark: hi so we are discussing support for pluggable matchmakers in gpii

[09:51:42 CDT(-0500)] <colinclark> right

[09:51:59 CDT(-0500)] <yzen> one use case is statistical matchmaker that needs device info

[09:52:13 CDT(-0500)] <yzen> currently it is not passed to match or the strategy functions

[09:52:21 CDT(-0500)] <yzen> colinclark: there are 2 approaches to do that

[09:53:03 CDT(-0500)] <yzen> 1 - mangle configuration and let match (that executes the strategy) accept device data

[09:53:30 CDT(-0500)] <yzen> however that is not something configurable that easily

[09:54:11 CDT(-0500)] <yzen> 2 update implementation of how the strategy is executed and make the format of the configuration for it more user friendly

[09:54:11 CDT(-0500)] <colinclark> How mangled would the configuration be? What would it, roughly, entail?

[09:54:21 CDT(-0500)] <yzen> well the flow is something like this

[09:54:24 CDT(-0500)] <colinclark> #2 sounds preferable, but it's late in the game

[09:55:07 CDT(-0500)] <yzen> request handler has a match method that is called when we are ready to match . it currently accepts 2 args - prefs and solutions

[09:55:30 CDT(-0500)] <yzen> that match method calls matchmaker's match that will then dispose to the strategy

[09:55:45 CDT(-0500)] <yzen> so nothing below the request handler has access to device

[09:56:24 CDT(-0500)] <yzen> we would be able to completely customize handler's match and its args with configuration, but it means the implementor would be required to provide it

[09:56:46 CDT(-0500)] <yzen> it's essentially configuration 2 levels above the ideal one

[09:56:53 CDT(-0500)] <yzen> colinclark: hopefully i make sense

[09:57:28 CDT(-0500)] <colinclark> yes, at least in the general sense

[09:57:43 CDT(-0500)] <colinclark> What would the ideal design entail?

[10:03:57 CDT(-0500)] <colinclark> Another question, yzen: How much work would it be to whip up an example of the mangle-y configuration, just for reference?

[10:04:23 CDT(-0500)] <colinclark> I'm trying to weigh the cost of saying, "Here's a hack; here's how you do it." vs. actually just fixing it properly

[10:04:51 CDT(-0500)] <yzen> colinclark: not much couple of hours, it would be nice to see the actual code and how people are plugging in (smile)

[10:05:01 CDT(-0500)] <colinclark> NO KIDDING!

[10:05:15 CDT(-0500)] <yzen> but configuring it would be reasonable

[10:05:17 CDT(-0500)] <yzen> so

[10:05:22 CDT(-0500)] <yzen> use case 2

[10:05:25 CDT(-0500)] <yzen> RB-MM (smile)

[10:05:55 CDT(-0500)] <yzen> that thing is similar, but since there's the whole new ontology issue, we would need to plug and override configuration even earlier

[10:06:11 CDT(-0500)] <yzen> to bypass ontology if necessary

[10:06:23 CDT(-0500)] <colinclark> eek

[10:06:24 CDT(-0500)] <colinclark> ok

[10:06:33 CDT(-0500)] <colinclark> tell me more (smile)

[10:06:43 CDT(-0500)] <yzen> so the deficiency right now is

[10:06:50 CDT(-0500)] <yzen> we can override top level events and listeners

[10:07:00 CDT(-0500)] <yzen> but nothing after we get into actual matchmaker match

[10:07:37 CDT(-0500)] <yzen> so we can say dont even look into ontologies, or pass these args to handler's match but not matchmaker's match

[10:07:41 CDT(-0500)] <yzen> but i have a suspicion that both can be done with configuration

[10:07:48 CDT(-0500)] <colinclark> ok

[10:07:50 CDT(-0500)] <yzen> and i can whip up examples fairly easily

[10:07:56 CDT(-0500)] <colinclark> I can't tell what the RB team really needs

[10:08:04 CDT(-0500)] <colinclark> Since they have only shared bits of copy/pasted code in emails

[10:08:13 CDT(-0500)] <yzen> yes

[10:08:21 CDT(-0500)] <colinclark> So, my first guess is that they simply want to turn off the ontological transform entirely

[10:08:22 CDT(-0500)] <yzen> im still reading your fwd

[10:08:26 CDT(-0500)] <yzen> yes

[10:08:34 CDT(-0500)] <colinclark> but it is possible that they are in fact also wanting to employ the flat matchmaker

[10:08:38 CDT(-0500)] <yzen> that and also customize matchamaker's match i think

[10:08:44 CDT(-0500)] <colinclark> Yes

[10:08:58 CDT(-0500)] <colinclark> They've got the problem that they seem to be just modifying framework code directly

[10:09:10 CDT(-0500)] <colinclark> I wish Nick would hang out here and share his code in Github so we could walk him through it

[10:09:17 CDT(-0500)] <colinclark> but it's pretty hard to call code that you've yourself overridden

[10:09:39 CDT(-0500)] <yzen> do we have access to him , maybe he can hang out here tomorrow ?

[10:10:23 CDT(-0500)] <colinclark> Let's send him an email

[10:10:33 CDT(-0500)] <colinclark> I'll be up fairly early tomorrow, I guess, for the MM team meeting

[10:10:43 CDT(-0500)] <yzen> colinclark: when does it happen ?

[10:10:51 CDT(-0500)] <colinclark> 9 am, I think, with the time change

[10:10:52 CDT(-0500)] <yzen> colinclark: i can join too ?

[10:10:55 CDT(-0500)] <colinclark> YES!

[10:10:56 CDT(-0500)] <yzen> ok

[10:10:59 CDT(-0500)] <colinclark> It's gotomeeting

[10:11:06 CDT(-0500)] <colinclark> It's typically at 8 am, but one hour shifted because of EDT

[10:11:15 CDT(-0500)] <yzen> ill be online but if i snooze can you ping me then (smile) ?

[10:11:18 CDT(-0500)] <colinclark> kasper_ can confirm when he's finished talking on this meeting (smile)

[10:11:20 CDT(-0500)] <colinclark> yes, I'll send you a text

[10:11:27 CDT(-0500)] <yzen> colinclark: thanks!

[10:15:44 CDT(-0500)] <yzen> colinclark: so im trying to think what's the best way to spend my time right now? come up with configuration examples, try refactoring (pro'lly not) or n/p tool

[10:16:38 CDT(-0500)] <colinclark> We're a bit stuck

[10:16:44 CDT(-0500)] <colinclark> But my sense of priority is this:

[10:16:48 CDT(-0500)] <colinclark> 1. Get the matchmakers working

[10:19:57 CDT(-0500)] <colinclark> 2. n/p tool

[10:20:51 CDT(-0500)] <yzen> colinclark: i think michelled should have enough to continue without me for the time being

[11:44:23 CDT(-0500)] <colinclark> yzen1: Quick question for you

[11:44:34 CDT(-0500)] <colinclark> So, it looks like Nick is directly modifying framework code

[11:44:39 CDT(-0500)] <colinclark> gpii.matchMaker.match()

[11:44:58 CDT(-0500)] <colinclark> I'm going to suggest that he creates his own match function and names it differently

[11:45:18 CDT(-0500)] <colinclark> it looks like that match function is defined as an invoker to the Matchmaker component

[11:45:33 CDT(-0500)] <colinclark> What, specifically, does he need to do to override the match function with his own?

[11:45:42 CDT(-0500)] <colinclark> A demands block, I assume

[11:45:44 CDT(-0500)] <colinclark> ?

[11:48:14 CDT(-0500)] <yzen> colinclark: that would be it

[11:48:15 CDT(-0500)] <yzen> but

[11:48:18 CDT(-0500)] <colinclark> eek

[11:48:19 CDT(-0500)] <colinclark> (smile)

[11:48:29 CDT(-0500)] <yzen> i m not sure whether they need device info as well

[11:48:41 CDT(-0500)] <yzen> and they would need more to get rid of ontology communication

[11:48:56 CDT(-0500)] <colinclark> Ok, so question:

[11:49:10 CDT(-0500)] <colinclark> Is it possible for Nick to do the following, setting aside the ontology server issue

[11:49:27 CDT(-0500)] <colinclark> 1. Create a new file, say, RuleBasedMatchMakerIntegration.js

[11:49:37 CDT(-0500)] <colinclark> 2. Create a new function, say, gpii.ruleBaseMatchmaker.match()

[11:50:00 CDT(-0500)] <colinclark> 3. Issue, in that file, a demands block against the Matchmaker component, overriding the default match function

[15:15:26 CDT(-0500)] <Bosmon> hi kasper_

[15:15:28 CDT(-0500)] <Bosmon> Are you there?

[15:21:51 CDT(-0500)] <kasper_> I am

[15:22:01 CDT(-0500)] <kasper_> Bosmon

[15:22:08 CDT(-0500)] <Bosmon> Ah ok

[15:22:15 CDT(-0500)] <Bosmon> I am just replying to you on the list....

[15:22:53 CDT(-0500)] <kasper_> oki doki

[15:26:04 CDT(-0500)] <Bosmon> What kind of Viking Language is that : P

[15:37:02 CDT(-0500)] <yzen> kasper_, colinclark so i have this branch now https://github.com/yzen/universal/tree/RuleBasedMatchMaker with the example of what i think Nick would want

[15:37:11 CDT(-0500)] <yzen> should i post it on the list for everyeone ?

[15:37:25 CDT(-0500)] <colinclark> I don't see any reason why not

[15:38:13 CDT(-0500)] <yzen> colinclark: ok

[15:38:25 CDT(-0500)] <yzen> this is all i had to do https://github.com/yzen/universal/commit/e678dba1bbf5f29a478971e584073a83f24a20d4

[15:38:55 CDT(-0500)] <kasper_> awesome!!! thanks yura

[15:39:01 CDT(-0500)] <yzen> Bosmon: hi , michelled and I were chatting about custom resolver configs in rendererComponent that would let us handle escape dot elpaths

[15:39:23 CDT(-0500)] <Bosmon> Hi yzen

[15:42:09 CDT(-0500)] <kasper_> Bosmon: thanks for the great news on the FLUID-4916

[15:47:01 CDT(-0500)] <yzen> Bosmon: is it only the resolver set config or both that we need to customize?

[15:47:24 CDT(-0500)] <Bosmon> You would probably need to configure both

[15:47:28 CDT(-0500)] <Bosmon> Especially if you want any autoBind to work

[15:47:57 CDT(-0500)] <yzen> Bosmon: we have to yes

[15:48:17 CDT(-0500)] <yzen> Bosmon: do we need a custom strategy or the one we are looking for is already in the framework ?

[15:48:29 CDT(-0500)] <Bosmon> You can just use the one used in ModelTransformations

[15:48:39 CDT(-0500)] <Bosmon> There is a long-standing JIRA I believe to move it into the core framework

[15:48:52 CDT(-0500)] <yzen> Bosmon: you mean the file right ?

[15:49:04 CDT(-0500)] <Bosmon> I mean, the particular strategy

[15:49:19 CDT(-0500)] <Bosmon> There's probably even a TODO on it!

[15:49:49 CDT(-0500)] <yzen> Bosmon: are you talking about model transformation in the gpii or infusion sorry ?

[15:50:14 CDT(-0500)] <Bosmon> yzen - what difference could there be?

[15:50:23 CDT(-0500)] <Bosmon> GPII uses Infusion for Model Transformation

[15:50:50 CDT(-0500)] <yzen> Bosmon: ok so it is in infusion's modelTransformation file (hence my original question (smile) )

[15:51:10 CDT(-0500)] <yzen> that's where we should be looking for it

[15:52:38 CDT(-0500)] <Bosmon> yzen - it is here

[15:52:39 CDT(-0500)] <Bosmon> https://github.com/fluid-project/infusion/blob/master/src/webapp/framework/core/js/ModelTransformations.js#L644-L653

[15:52:44 CDT(-0500)] <Bosmon> This is worse than I remembered.....

[15:53:02 CDT(-0500)] <Bosmon> Largely because of the additional complexity of the "schemaStrategy" which you don't need

[15:53:14 CDT(-0500)] <yzen> cool

[15:53:14 CDT(-0500)] <yzen> michelled: ^

[15:53:30 CDT(-0500)] <Bosmon> This is only used in operating wildcard transforms which are currently not used outside tests

[15:53:56 CDT(-0500)] <Bosmon> No, that's not true, I dimly remember the Lifecycle Manager uses one

[15:54:20 CDT(-0500)] <michelled> yzen had passed me this: https://github.com/GPII/universal/blob/master/gpii/node_modules/lifecycleManager/src/LifecycleManager.js#L138-L144

[15:56:00 CDT(-0500)] <Bosmon> Oh yes

[15:56:03 CDT(-0500)] <Bosmon> That is another duplicate of it

[15:56:11 CDT(-0500)] <Bosmon> Hence the urgency to get this stuff into the core framework : p

[15:56:19 CDT(-0500)] <Bosmon> Unfortunately the comments urging this seem to have vanished

[15:57:29 CDT(-0500)] <michelled> I'm not clear on where it would go in the core framework

[15:57:38 CDT(-0500)] <Bosmon> michelled - it would go into DataBinding.js

[15:58:29 CDT(-0500)] <michelled> oh, meaning it just moves there and we refer to it in the other places?

[15:58:54 CDT(-0500)] <Bosmon> michelled - yes, largely - or perhaps a little utility function to help people build these configurations

[15:58:55 CDT(-0500)] <Bosmon> Or both

[15:59:54 CDT(-0500)] <michelled> ok, once it's there, I'm not sure how I'm expected to use it in the NPGatheringTool: https://github.com/yzen/NPGatheringTool/blob/master/src/js/NPGatheringTool.js

[16:00:11 CDT(-0500)] <Bosmon> michelled - this can be supplied as part of the configuration to any RendererComponent

[16:00:35 CDT(-0500)] <yzen> Bosmon: but i guess we do not have a test case for that do we ?

[16:01:06 CDT(-0500)] <Bosmon> We have test cases for the "getConfig" part

[16:01:20 CDT(-0500)] <Bosmon> Several of the tests in RendererUtilitiesTests.js supply "resolvedGetConfig"

[16:01:22 CDT(-0500)] <Bosmon> resolver

[16:02:02 CDT(-0500)] <Bosmon> Although it's a rather bizarre name for it

[16:03:39 CDT(-0500)] <Bosmon> I guess it dates from the CSpace days when we had "resolvers"

[16:04:38 CDT(-0500)] <michelled> what do you think they should be called now?

[16:04:44 CDT(-0500)] <michelled> 'getConfig' ?

[16:04:47 CDT(-0500)] <Bosmon> Yes

[16:04:52 CDT(-0500)] <Bosmon> plain "getConfig" seems more reasonable

[16:05:16 CDT(-0500)] <michelled> I guess I should JIRA this up and then fix it

[16:06:22 CDT(-0500)] <Bosmon> Thanks, michelled!

[16:06:37 CDT(-0500)] <Bosmon> I should have a fixed FLUID-4929 shortly....

[16:19:47 CDT(-0500)] <michelled> Bosmon: do you think the issue is captured correctly in this JIRA? http://issues.fluidproject.org/browse/FLUID-4933

[16:22:04 CDT(-0500)] <Bosmon> michelled - that looks good - it would be nice to have a sample or a reference to some of the places where the configuration currently is

  • No labels