fluid-work IRC Logs-2014-01-07
[08:49:32 CST(-0600)] <Justin_o_> Bosmon: are you there?
[09:09:23 CST(-0600)] <Bosmon7> Hi Justin_o_
[09:09:26 CST(-0600)] <Bosmon7> I am here a little
[09:27:08 CST(-0600)] <Justin_o_> Bosmon7: hello, sorry i missed this
[09:27:33 CST(-0600)] <Justin_o_> Bosmon7: i'm wondering if you have ideas around model sharing (e.g. model relays) and dynamic components
[09:28:41 CST(-0600)] <Bosmon7> Justin_o_ - perhaps you can be more specific
[09:35:40 CST(-0600)] <Justin_o_> Bosmon7: so we have something that's i guess like your repeating input field from CSpace.. basically a user can enter in some captions info, and a new set of inputs will appear.. but these all need to be fed back to a parent model to manage
[09:36:49 CST(-0600)] <Justin_o_> Bosmon7: you can look at the designs for milestone 1 here http://wiki.fluidproject.org/display/fluid/FLOE+Metadata+Authoring+Design
[09:37:51 CST(-0600)] <Justin_o_> we may just end up going with the two static fields but eventually we were planning on having the dynamically increasing set.. and we were thinking of using dynamic components to help with this.. but it's the model management that is tripping us up at the moment.
[09:40:32 CST(-0600)] <jhung1> Justin_o_, cindyli - I was going to remove the closed tasks in the Floe Iteration Plan page. Is that okay?
[09:40:52 CST(-0600)] <Justin_o_> jhung1: yes please.. we might want to close out FLOE-111 too
[09:43:21 CST(-0600)] <Bosmon7> Justin_o_ - yes, it seems reasonable
[09:43:40 CST(-0600)] <Bosmon7> I can't remember enough of the details of "old modelRelay" to see why this might problematic
[09:46:22 CST(-0600)] <Justin_o_> Bosmon7: hmm.. okay.. will the new model relay system handle this okay.. and does it also come with model transformations.. the problem we are having is around the fact that the model in the parent will be an array and trying to associate those values with a particular dynamic component.. perhaps we need model transformations here.
[09:47:31 CST(-0600)] <Bosmon7> Justin_o_ - I see what you mean
[09:47:41 CST(-0600)] <Bosmon7> This is a facility that actually isn't implemented for "new modelRelay" either
[09:47:55 CST(-0600)] <Bosmon7> So it may be to your advantage that you currently only have the old, simpler impl to work with : P
[09:47:55 CST(-0600)] <Justin_o_>
[09:48:06 CST(-0600)] <Justin_o_> i guess that's good
[09:48:24 CST(-0600)] <Justin_o_> any ideas of how we might tackle this issue?
[09:52:08 CST(-0600)] <Bosmon7> Justin_o_ - you'll just have to synthesize the required configuration yourself, probably based on a variant base grade of your existing modelRelay
[09:52:08 CST(-0600)]
<Bosmon7> Note that both the variables
and
are available in dynamicComponent configuration material
[09:52:08 CST(-0600)] <Bosmon7> And so given the latter, you should be able to produce suitable modelRelay configuration
[09:54:46 CST(-0600)]
<Justin_o_> Bosmon7: what does
give you?
[09:55:58 CST(-0600)] <Bosmon7> Justin_o_ - it gives you the path of the particular piece of source material used to instantiate the dynamic component
[09:56:21 CST(-0600)]
<Bosmon7> So in particular, if you had instantiated it from
.model.arrayThing it would give you the path into the model's array
[09:57:36 CST(-0600)] <Justin_o_> Bosmon7: oh okay... so that might work.. we can explore that..
[09:59:54 CST(-0600)] <Justin_o_> Bosmon7: when do you think we'll have model transformations built in with the model relay?
[10:00:03 CST(-0600)] <Bosmon7> Justin_o_ - it just needs review
[10:00:47 CST(-0600)] <Justin_o_> oh cool.. so soon.. by the way, did you see michelled's comments on your FLUID-5185 pull request?
[10:00:53 CST(-0600)] <Bosmon7> But don't expect the work of integrating it to be very quick
[10:00:53 CST(-0600)] <Bosmon7> We will "have" it
[10:00:53 CST(-0600)] <Bosmon7> But it will exist integrated initially only in the context of the Pager
[10:00:55 CST(-0600)] <Bosmon7> THis will just start off a long process of converting and vetting our components one by one
[10:01:55 CST(-0600)] <colinclark> I actually started reviewing it yesterday, so it will be in soon, I expect
[10:01:58 CST(-0600)] <Bosmon7> Justin_o_ - yes, I have been working on answering those
[10:02:08 CST(-0600)] <Bosmon7> colinclark - awesome
[10:02:16 CST(-0600)] <Justin_o_> okay, that makes sense.. perhaps we could help trying it out in the metadata demo.. we may have a need for some model transformations there
[10:02:53 CST(-0600)] <Bosmon7> Justin_o_ - yes, certainly for any new developments, we should start out by using the new component grades
[10:03:06 CST(-0600)] <Bosmon7> Once we have 100% conversion, we can ditch all of the old code
[10:03:14 CST(-0600)] <Bosmon7> But I don't plan for this before the 1.5 release
[10:03:18 CST(-0600)] <Bosmon7> 1.5 will be a "fat release"
[10:04:38 CST(-0600)] <Justin_o_> Bosmon7: that's all reasonable.. i guess 2.0 will be the lean version of infusion
[10:04:50 CST(-0600)] <Bosmon7> Justin_o_ - right
[10:05:45 CST(-0600)] <colinclark> Bosmon7: I have a quick, lame question for you
[10:05:52 CST(-0600)] <Bosmon7> Hi colinclark
[10:05:59 CST(-0600)] <Bosmon7> I'm absolutely convinced it will be a great question
[10:06:04 CST(-0600)] <colinclark> I have a model listener that looks roughly like this:
[10:07:06 CST(-0600)]
<colinclark> modelListeners:
[10:07:06 CST(-0600)]
<colinclark> when I log "
.path", it's actually an array
[10:07:06 CST(-0600)] <colinclark> ["pots", "0"]
[10:07:13 CST(-0600)] <Bosmon7> Oh yes
[10:07:18 CST(-0600)] <colinclark> I was surprised by that
[10:07:34 CST(-0600)] <Bosmon7> Yes, the framework has moved over to segment arrays pretty much universally
[10:07:42 CST(-0600)] <Bosmon7> As an attempt to economise on "parsing garbage"
[10:08:13 CST(-0600)] <colinclark> My model looks like this:
[10:08:22 CST(-0600)] <Bosmon7> The "old framework" spent an inordinate amount of time packing things into string ELs and then parsing them out again
[10:08:26 CST(-0600)] <colinclark> right
[10:08:31 CST(-0600)] <colinclark> paths: [0, 27, 0, 192]
[10:08:41 CST(-0600)] <colinclark> I'd like to listen for changes in the "leaves"
[10:08:55 CST(-0600)] <colinclark> sorry, that should be pots: [0, 27, 0, 192]
[10:08:58 CST(-0600)] <Bosmon7> yup
[10:09:14 CST(-0600)] <colinclark> so if one item in the array changes, I want to hear about it with that specific value
[10:09:31 CST(-0600)] <colinclark> So should I just use a utility somewhere to reconstitute a path?
[10:09:40 CST(-0600)] <colinclark> from the array?
[10:09:44 CST(-0600)] <Bosmon7> Well - why would you want to reconstitute it?
[10:09:50 CST(-0600)] <Bosmon7> Surely it already contains exactly what you need to know
[10:10:27 CST(-0600)] <Bosmon7> And in fact it would be quickest to use it in the form given, rather than any other
[10:10:52 CST(-0600)] <colinclark> interesting
[10:11:13 CST(-0600)] <Bosmon7> You, like the framework, would only then go to parse out the damn thing again once you had reconstituted the path....
[10:11:51 CST(-0600)] <Bosmon7> Yes.... it took me a while to come round to this point of view
[10:11:59 CST(-0600)] <colinclark> Ok, I guess that makes some sense
[10:12:24 CST(-0600)] <colinclark> and again speaks to the role of Model Relay in terms of actually covering most of the cases of what you'd want to DO with the path anyway
[10:27:58 CST(-0600)] <colinclark> hey Justin_o_
[10:41:19 CST(-0600)] <colinclark> Bosmon7: I just added this little section to the "IoC References" wiki page http://wiki.fluidproject.org/display/docs/IoC+References#IoCReferences-ReservedIoCNames
[10:41:51 CST(-0600)] <Bosmon7> colinclark - that's very helpful, thanks
[10:42:00 CST(-0600)] <Justin_o_> colinclark: hello
[10:42:13 CST(-0600)] <colinclark> Did you name something "source," too?
[10:42:20 CST(-0600)] <Bosmon7> I mentioned privately in chat that we might well be able to remove this restriction
[10:44:17 CST(-0600)] <Justin_o_> colinclark: i had run into an issue where naming anything with source at the beginning didn't work.. e.g. sourceAnything.. but i'm pretty sure Bosmon7 fixed that now
[10:44:47 CST(-0600)] <Justin_o_> that list of reserved words is pretty useful
[10:45:43 CST(-0600)] <colinclark> I'm just filing an issue about my experience, in case it's helpful to others
[10:45:45 CST(-0600)] <Bosmon7> It's fixed but may well still be in the review queue
[10:45:50 CST(-0600)] <colinclark> and then Bosmon7 can use that as the basis for a more specific issue about removal of the restriction
[11:03:56 CST(-0600)] <colinclark> Bosmon7, Justin_o_: not my clearest JIRA in the world, but at least it features cats: http://issues.fluidproject.org/browse/FLUID-5244
[11:06:01 CST(-0600)] <Bosmon7> Thanks for your giant *FARM.CATT*, colinclark!
[12:21:50 CST(-0600)] <anastasiac> by the way, yzen, I forgot to mention: Happy Birthday!
[12:22:40 CST(-0600)] <yzen> thanks
[13:38:21 CST(-0600)] <Bosmon8> Thanks, kasparnet for your very thorough recent panic list
[13:38:39 CST(-0600)] <Bosmon8> I am looking down the list starting at the most urgent ones.... but still find myself a bit puzzled
[13:38:52 CST(-0600)] <Bosmon8> For example this one: https://github.com/GPII/universal/pull/180/files
[13:38:56 CST(-0600)] <Bosmon8> Appears as if it might be harmless
[13:39:09 CST(-0600)] <Bosmon8> But I wonder how I could possibly know if it is safe to be merged : P
[13:39:16 CST(-0600)] <Bosmon8> yzen, colinclark may also have some input on this issue
[13:39:52 CST(-0600)] <Bosmon8> This pull request has to me the unfortunate combination of properties of apparently being "very very urgent" whilst at the same time "sort of unfathomable" .......
[13:41:47 CST(-0600)] <yzen> Bosmon8: what would make you feel better about this patch ?
[13:46:13 CST(-0600)] <sgithens> kasparnet: Are you going to run the actual pilots on Monday, or is that just when the review starts? ie. After a bunch of frantic merges on friday I hope it works over the weekend
[14:32:49 CST(-0600)] <kasparnet> sgithens: the review is monday but we'll be doing demos there so things have to work
[14:33:48 CST(-0600)] <kasparnet> Bosmon8: I might have miscategorized some of them - I thought that one was a requirement for matchmaker integration (ST and RB matchmakers)
[14:42:10 CST(-0600)] <michelled> kasparnet: will the demo be on Monday or on Wednesday?
[14:42:22 CST(-0600)] <kasparnet> michelled: wednesday
[14:42:51 CST(-0600)] <kasparnet> monday will be spent going through the demo, presentations, etc
[14:42:56 CST(-0600)] <colinclark> kasparnet: I was just thinking about Matchmaker integration, based on Andy's response
[14:43:03 CST(-0600)] <colinclark> I feel like there are some pieces missing
[14:43:18 CST(-0600)] <colinclark> based on the comment where he says "Its tested to work in the architecture master as it was on xmas if you integrate it manually (replacing the .match function)"
[14:43:26 CST(-0600)] <colinclark> that doesn't quite sound like an integration to me
[14:43:44 CST(-0600)] <colinclark> but maybe there's something about the nature of an integration that I am unaware
[14:43:45 CST(-0600)] <colinclark> of
[14:43:55 CST(-0600)] <colinclark> yzen: How does it look from your perspective?
[14:44:26 CST(-0600)] <colinclark> is the issue that we need the Matchmaker Proxy to be reviewed and pushed?
[14:47:01 CST(-0600)] <kasparnet> colinclark: I think (and yura/michelle - correct me if I'm wrong) we ended up deciding that the ST MM would be run as a separate server - and the solution for now is that andy will be running his own instance of a specially modified universal - where the matchmaker part is replaced
[14:47:24 CST(-0600)] <kasparnet> colinclark: (he would then only run the 'matchmaker' part of the framework as a service)
[14:47:37 CST(-0600)] <colinclark> oh, ok
[14:47:39 CST(-0600)] <yzen> kasparnet: colinclark: so as far as i know Nick has a working version of the rule based match maker that works as a standalone
[14:47:57 CST(-0600)] <yzen> there were only a couple of changes to the older repo that he had related to updating to the latest universal
[14:48:03 CST(-0600)] <kasparnet> colinclark: though this might just be me making stuff up cause I dont want new crazy and scary things to come up
[14:48:32 CST(-0600)] <yzen> colinclark: kasparnet it should be working with the server without any issues, it's just the matter of pointing the proxy to the right standalone match makers
[14:49:13 CST(-0600)] <colinclark> How is that done, yzen?
[14:49:28 CST(-0600)] <yzen> statistical one, afaik, is almost the same and unless customization of match is done differently from the rule based matchmaker example, there might be something wrong
[14:50:01 CST(-0600)] <yzen> well we have a top level configuration in universal along with the one we usually use that configures the proxy instead of the actual match maker
[14:50:03 CST(-0600)] <colinclark> This is Andy's repository, yzen: https://github.com/AndreasStiegler/GPII_StatisticalMatchmaker1
[14:50:57 CST(-0600)] <colinclark> So it sounds like we first need to get the Matchmaker Proxy into master
[14:51:09 CST(-0600)] <colinclark> and then something needs to be done to create configuration files for each Matchmaker?
[14:51:11 CST(-0600)] <michelled> yzen: what does the configuration look like? can you point me to the working one?
[14:51:32 CST(-0600)] <yzen> https://github.com/yzen/universal/blob/GPII-270/gpii/node_modules/matchMaker/configs/proxy.json
[14:51:57 CST(-0600)] <yzen> this is the one used by the top level config: https://github.com/yzen/universal/blob/GPII-270/gpii/configs/fm.ps.sr.dr.mm.os.lms.multipleMatchMakers.json
[14:52:30 CST(-0600)] <colinclark> So what does Andy need to do to support the Proxy API?
[14:52:34 CST(-0600)] <colinclark> or is he already good?
[14:53:08 CST(-0600)] <colinclark> Looks like he's using older-style "demands" configuration, and needs to update his module to run as a server?
[14:53:12 CST(-0600)] <colinclark> is that right?
[14:53:31 CST(-0600)] <yzen> colinclark: he does not have to do anything except for making sure that his match maker server runs as a standalone server, which is similar to the previous pilot iteration
[14:53:56 CST(-0600)] <yzen> colinclark: yes that was the only change nick and i had to do to make sure his repo supports latest universal
[14:54:05 CST(-0600)] <colinclark> ok
[14:54:14 CST(-0600)] <colinclark> So I'll compare Nick's module to Andy's
[14:54:17 CST(-0600)] <yzen> colinclark: and even then the only reason we needed to update to the latest was because of solutions data being updated slightly
[14:54:28 CST(-0600)] <colinclark> and that should tell me specifically what Andy needs to do?
[14:54:47 CST(-0600)] <yzen> colinclark: ya instead of demands we are are now leverage grades and grade linkage ability
[14:54:51 CST(-0600)] <colinclark> kasparnet and michelled: Who's on deck to review the Matchmaker Proxy? And do they know they are? And do they have a timeline for it?
[14:55:09 CST(-0600)] <yzen> https://github.com/NickKaklanis/RuleBased_MatchMaker/blob/master/lib/RuleBasedMatchMaker.js#L34-L53
[14:56:47 CST(-0600)] <yzen> and this https://github.com/NickKaklanis/RuleBased_MatchMaker/blob/master/lib/RuleBasedMatchMaker.js#L67-L71
[14:56:53 CST(-0600)] <kasparnet> colinclark: Bosmon8 will be reviewing the matchmaker proxy stuff - and yeah - I think he's well aware of it (or well - I sent out the pull-request mail a few hours ago, so he's very-recently-well-aware of it)
[14:57:12 CST(-0600)] <colinclark> thanks, yzen, for the links
[14:57:14 CST(-0600)] <colinclark> very helpful
[14:57:32 CST(-0600)] <kasparnet> colinclark: no timeline, but it's on the "very very very pressing" shortlist
[14:58:01 CST(-0600)] <yzen> colinclark: there was an issue with older version and now the framework forced to correct something (access to the request)
[15:00:10 CST(-0600)] <Bosmon8> yzen, colinclark - sorry to be away at dinner
[15:00:22 CST(-0600)] <Bosmon8> yzen's original question is a good one, "what would make me feel better about it"
[15:00:32 CST(-0600)] <Bosmon8> Clearly #1 at the list would be... "some tests"
[15:00:44 CST(-0600)] <Bosmon8> But there may be some good reasons why these are not sensible to produce
[15:01:01 CST(-0600)] <Bosmon8> For example, the CORS functionality itself is, I believe, at least somewhat tested at the kettle level
[15:01:11 CST(-0600)] <yzen> Bosmon8: well we have core tests, if you want to test core in universal it is really testing kettle no?
[15:01:18 CST(-0600)] <Bosmon8> So it would seem redundant to test it again, especially if the content of the patch is simply "to enable the use of CORS"
[15:01:41 CST(-0600)] <Bosmon8> All the same, the reviewer needs some kind of assurance about the pull request : P
[15:03:33 CST(-0600)] <Bosmon8> kasparnet - I am "aware" of the proxy stuff, yes
[15:03:37 CST(-0600)] <Bosmon8> But the issue is somewhat the same
[15:03:43 CST(-0600)] <Bosmon8> The code "looks sensible" to me
[15:03:47 CST(-0600)] <Bosmon8> And this pull request has at least SOME tests
[15:04:22 CST(-0600)] <Bosmon8> But our test cases being what they are for the GPII still, I'm still not completely clear on how I can actually run them
[15:05:46 CST(-0600)] <Bosmon8> It seems that despite our best efforts we really are at the same situation that we were at the pilots previously - that is, we have lots of functionality on hand that we "have belief that it works" but have no reliable way of actually verifying this
[15:05:57 CST(-0600)] <Bosmon8> That is, some test cases which "anyone" can run
[15:06:04 CST(-0600)] <Bosmon8> kasparnet - do you think that is right?
[15:07:11 CST(-0600)] <kasparnet> Bosmon8: well - yes and no - that depends on how you define "anyone".. We do have a pretty decent unit test coverage that anyone should be able to run (provided they have windows when testing windows stuff, linux when testing linux stuff, etc)
[15:07:59 CST(-0600)] <kasparnet> Bosmon8: and we do have acceptance tests, which (with the prerequisite of having NVDA installed in windows) should work provided the tester has the relevant platform available
[15:08:35 CST(-0600)] <kasparnet> Bosmon8: I guess the "relevant platform available" is what's prevents 'anyone' to run it ... we still need that damn VM to distribute
[15:16:24 CST(-0600)] <michelled> yzen: perhaps, if it's not possible to write tests for the pull request, you could provide Bosmon8 with a description of how to prove that it's working
[15:16:34 CST(-0600)] <michelled> maybe you could screen share and show him?
[15:18:14 CST(-0600)] <michelled> Bosmon8: we have never managed to 'make back the ground' we lost when we cut our last hack branches for pilots and hackathons. we have been slowly moving towards that, but we aren't there yet
[15:18:54 CST(-0600)] <michelled> I feel confident that we will indeed get to the point where we have a lovely set of easily run tests and all the functionality that we regularly depend on and demo in the master repository
[15:19:17 CST(-0600)] <michelled> but that unfortunately isn't going to be possible before the review.
[15:19:29 CST(-0600)] <colinclark> uh oh
[15:20:18 CST(-0600)] <michelled> I'm not suggesting that we put anything in to master that we aren't happy with. so if things really can't go in - so be it. if there is a way we can be happy with it, let's strive for that.
[15:23:26 CST(-0600)] <colinclark> I think the thing we need right now, Bosmon / Bosmon8 is specificity
[15:23:38 CST(-0600)] <colinclark> I see seventeen pending pull requests to Universal
[15:24:17 CST(-0600)] <colinclark> So if there are ones we have concerns about, we need a very specific to do list of what needs to be addressed about them
[15:29:27 CST(-0600)] <Bosmon8> Ok
[15:29:48 CST(-0600)] <Bosmon8> Well, interestingly from my point of view, the issue doesn't seem to be that much about "specificity"
[15:30:04 CST(-0600)] <Bosmon8> But just that I still don't know how I can basically test the architecture in a way that is credible
[15:31:18 CST(-0600)] <Bosmon8> So of those "very very urgent" and "very urgent" pull requests on my plate, I see lots of things that "seem reasonable" and that I wouldn't have a strong reason to object to based on the code that is in them
[15:33:13 CST(-0600)] <Bosmon8> But I just have no way of telling whether they will screw the system up completely
[15:34:53 CST(-0600)] <michelled> hmmm… I suppose people have been relying on manual testing. is that what you do kasparnet, yzen, colinclark, sgithens?
[15:35:49 CST(-0600)] <kasparnet> michelled: yeah, I generally run unit tests (browser and non-browser), then acceptance and finally logging in/out a few people
[15:36:06 CST(-0600)] <Bosmon8> The trouble is, I'm on the move with an underpowered Windows laptop with no VMs on it
[15:36:18 CST(-0600)] <Bosmon8> So my capability to test things is very limited
[15:36:49 CST(-0600)] <Bosmon8> And I won't be back home and at work fully until Thursday, which seems cutting it a bit fine for things which are "very very urgent"
[15:37:24 CST(-0600)] <michelled> ah, perhaps I can help there - why don't you tell me when pull requests you are actually happy with from reading the code perspective and I'll try to test them out as best as I can
[15:37:43 CST(-0600)] <Bosmon8> Ok, well I am "in theory" happy with both of my "very very" urgent ones
[15:38:01 CST(-0600)] <Bosmon8> https://github.com/GPII/universal/pull/180/files seems completely innocuous
[15:38:17 CST(-0600)] <Bosmon8> Although it still seems a strange feature of Kettle's design that one actually needs to do this
[15:38:43 CST(-0600)] <Bosmon8> The kettle.use.* system and its mysterious motivations is something we will need to shoulder after yura's departure
[15:39:38 CST(-0600)] <colinclark> Which is why yzen and anastasiac have a plan to thoroughly document Kettle prior to his departure
[15:39:39 CST(-0600)] <michelled> is this the second one? https://github.com/GPII/universal/pull/174
[15:39:44 CST(-0600)] <Bosmon8> Yes
[15:39:56 CST(-0600)] <Bosmon8> I just entered a small query on that, but otherwise I am happy with it too
[15:40:45 CST(-0600)] <michelled> kasparnet: so, do you generally run the tests etc on windows and linux or also android?
[15:42:04 CST(-0600)] <yzen> Bosmon8: well as far as the GPII-270 goes you the tests cover success and failure scenarios, and you can run then on any platform
[15:42:12 CST(-0600)] <yzen> just like with the rest of the universal tests
[15:43:07 CST(-0600)] <Bosmon8> yzen - it seems unclear that I can really run them "on any platform"
[15:43:25 CST(-0600)] <Bosmon8> For example there's some material in this test, for example, which refers to Windows high contrast settings
[15:43:41 CST(-0600)] <Bosmon8> Which from my experience, with our current testing infrastructure, can only be run on a suitable Windows system
[15:43:43 CST(-0600)] <Bosmon8> Isn't this the case?
[15:44:14 CST(-0600)] <colinclark> I just commented on both pull requests so that it's clear where we're at in terms of the status of these two pull requests
[15:44:18 CST(-0600)] <yzen> Bosmon8: it only tests the proxy to the match maker not the whole architecture
[15:45:22 CST(-0600)] <Bosmon8> yzen - ok - perhaps we should adopt a special annotation at the head of a test case which explains its portability profile
[15:45:38 CST(-0600)] <kasparnet> michelled: well, most of the changes I review are specific to a platform (even if they may reside in universal) so I generally just test on that platform
[15:46:32 CST(-0600)] <michelled> kasparnet: and what do you do about the currently failing windows tests?
[15:47:30 CST(-0600)] <Bosmon8> So you're saying that I could run "ProxyTests.js" on any platform, even though its material appears to have Windows-specific tests?
[15:47:46 CST(-0600)] <Bosmon8> Actually I see now that the input_TestCase12_new.json seems unrelated
[15:49:10 CST(-0600)] <yzen> Bosmon8: yes it should not matter, all the tests in universal should run on any platform
[15:49:38 CST(-0600)] <yzen> if there are test cases that use prefs that are platform specific, they are not testing the actual application of those prefs
[15:49:51 CST(-0600)] <Bosmon8> yzen - ok, I issued a few pull request queries for that one
[15:50:17 CST(-0600)] <kasparnet> michelled: well - haven't reviewed anything after the failing windows tests - but will have to do so tomorrow – not quite sure what to do about it though
[15:50:34 CST(-0600)] <Bosmon8> kasparnet - which are our failures now?
[15:50:54 CST(-0600)] <kasparnet> Bosmon8: apparently there is an issue with the acceptance tests
[15:51:01 CST(-0600)] <kasparnet> failing under windows
[15:51:15 CST(-0600)] <kasparnet> (not the high-contrast 64bit thing)
[15:51:47 CST(-0600)] <kasparnet> Bosmon8: yzen is currently working on fixing it, I believe
[15:52:35 CST(-0600)] <yzen> Bosmon8: the same issue that i though moduleSource can help, it seems like with latest changes environment is still attempted to be resovled
[15:53:59 CST(-0600)] <yzen> Bosmon8: regarding that user , it's an example of how match maker preference should look like in the preference set
[15:59:29 CST(-0600)] <Bosmon8> yzen - it still resolves the environment "at an inappropriate time"?
[15:59:37 CST(-0600)] <yzen> yes
[15:59:39 CST(-0600)] <Bosmon8> Ok
[15:59:47 CST(-0600)] <Bosmon8> Can you link me to the relevant line of configuration?
[16:00:02 CST(-0600)] <yzen> of the test case ?
[16:00:06 CST(-0600)] <Bosmon8> yes
[16:00:24 CST(-0600)] <yzen> this for example https://github.com/yzen/windows/blob/GPII-75/tests/AcceptanceTests.js#L459
[16:01:01 CST(-0600)] <Bosmon8> Ah
[16:01:34 CST(-0600)] <Bosmon8> Well, isn't that strange?
[16:01:47 CST(-0600)] <Bosmon8> Surely by definition that is the one piece of configuratoin that could never be resolved "early"
[16:01:54 CST(-0600)] <Bosmon8> Since it is interpreted directly by the settings handler
[16:02:04 CST(-0600)] <Bosmon8> Well, or rather, the flow manager
[16:02:16 CST(-0600)] <yzen> Bosmon8: well this is passed as component options (for the test case holder)
[16:02:34 CST(-0600)] <yzen> so naturally it gets resolved right ?
[16:02:54 CST(-0600)] <Bosmon8> Well, if it were, it could only be resolved in a completely corrupted way
[16:03:03 CST(-0600)] <Bosmon8> But I guess what you told me didn't rule that out
[16:03:08 CST(-0600)] <Bosmon8> You did say it was resolved "early" : P
[16:03:13 CST(-0600)] <yzen> yes
[16:03:18 CST(-0600)] <Bosmon8> Without saying that it was resolved in an entirely incorrect way : P
[16:03:45 CST(-0600)] <yzen> well surely if you pass json as component options and it has ioc references the framework will try to resolve it no ?
[16:03:53 CST(-0600)]
<Bosmon8> In theory the IoC system could indeed try to brokenly interpret "
.APPDATA" as a context name
[16:04:02 CST(-0600)] <yzen> yes
[16:04:10 CST(-0600)] <Bosmon8> Although I guess the standard parsing rules would actually terminate the context at the first }
[16:04:30 CST(-0600)] <Bosmon8> So it would actually consider that the context is "{environment"
[16:04:53 CST(-0600)] <Bosmon8> And that the EL path is "APPDATA}\\nvda
nvda.ini"
[16:05:38 CST(-0600)]
<yzen> 15:11:49.141: ASSERTION FAILED: Failed to resolve reference
.APP
[16:05:39 CST(-0600)] <yzen> DATA - could not match context with name environment from component { typeName:
[16:05:40 CST(-0600)] <yzen> "kettle.tests.testCaseHolder"
[16:05:51 CST(-0600)] <Bosmon8> ok
[16:06:05 CST(-0600)] <Bosmon8> If you'd shown me the actual error message, we might have saved some time
[16:06:20 CST(-0600)] <Bosmon8> So it looks like you just need an additional mergePolicy inside the acceptance testing framework
[16:06:32 CST(-0600)] <Bosmon8> In theory we didn't need "moduleSource" at all
[16:07:18 CST(-0600)] <yzen> yes i thought so , i also though i can try using fluid.noexpand
[16:07:21 CST(-0600)] <yzen> but it did not work
[16:07:41 CST(-0600)] <Bosmon8> Well, fluid.noexpand may well be entirely broken, on the evidence we've had recently
[16:07:47 CST(-0600)] <yzen> so the acceptance framework does not create components , it just expands the testDefs block to include extra steps in the sequence
[16:08:05 CST(-0600)] <yzen> Bosmon8: are you suggesting i need to make one ?
[16:08:08 CST(-0600)] <Bosmon8> Well, I think not, it seems "noexpand" has some test cases
[16:08:13 CST(-0600)] <Bosmon8> So it probably still works
[16:08:16 CST(-0600)] <Bosmon8> Well ok
[16:08:28 CST(-0600)] <Bosmon8> Let's explore this idea that "the acceptance framework does not create components" : P
[16:10:00 CST(-0600)] <yzen> ok sure, so it means i can't contribute a mergePolicy right ?
[16:10:08 CST(-0600)] <Bosmon8> Well
[16:10:20 CST(-0600)] <Bosmon8> Surely the only issue could be the opposite - that it in fact DOES create some kind of component
[16:10:54 CST(-0600)]
<Bosmon8> Otherwise what would this EL reference be a reference to: var testDefRef = "
.options.testDef";
[16:11:49 CST(-0600)] <yzen> hmm that
[16:12:07 CST(-0600)] <Bosmon8> Can you link me to the copy of universal you are currently working with?
[16:13:03 CST(-0600)] <yzen> Bosmon8: my copy of universal is broken , since i can't point to an infusion commit since 5185 is out of sync with master
[16:13:11 CST(-0600)] <Bosmon8> ok
[16:13:15 CST(-0600)] <Bosmon8> But just to read the code
[16:13:19 CST(-0600)] <yzen> Bosmon8: its universal as is with kettle 5185 branch
[16:13:30 CST(-0600)] <Bosmon8> I see
[16:13:45 CST(-0600)] <yzen> Bosmon8: kettle test utils https://github.com/yzen/kettle/blob/FLUID-5185/test/utils/js/KettleTestUtils.js
[16:14:00 CST(-0600)] <Bosmon8> Surely there were changes to univeral's AcceptanceTests.js?
[16:14:11 CST(-0600)] <Bosmon8> The one I just quoted from
[16:14:29 CST(-0600)] <yzen> not sure which version your testDefRef is from
[16:14:33 CST(-0600)] <yzen> it is not in the latest master
[16:14:37 CST(-0600)] <Bosmon8> ok
[16:14:39 CST(-0600)] <Bosmon8> Let me check
[16:15:58 CST(-0600)] <Bosmon8> yzen.... so the quoted line is not present
[16:16:00 CST(-0600)] <Bosmon8> But a very similar one is
[16:16:01 CST(-0600)] <Bosmon8> https://github.com/GPII/universal/blob/master/tests/AcceptanceTests.js#L182
[16:16:09 CST(-0600)] <Bosmon8> Which suggests potential for the problem we are seeing
[16:16:38 CST(-0600)] <Bosmon8> Clearly the block "settingsHandlers" is part of the options of SOME component
[16:16:54 CST(-0600)] <yzen> Bosmon8: yes the test case holder
[16:17:09 CST(-0600)] <yzen> that's what I mentioned earlier
[16:17:11 CST(-0600)] <Bosmon8> Unfortunately there are so many things in the world called "tests" it is hard to see what it is
[16:17:32 CST(-0600)] <yzen> tests - https://github.com/yzen/kettle/blob/FLUID-5185/test/utils/js/KettleTestUtils.js#L349
[16:17:38 CST(-0600)] <Bosmon8> Sorry, thanks
[16:17:40 CST(-0600)] <Bosmon8> With you now
[16:17:58 CST(-0600)] <Bosmon8> Ah fascinating
[16:18:06 CST(-0600)] <Bosmon8> And the builder function is hardwired into Kettle : P
[16:18:10 CST(-0600)] <Bosmon8> As it its grade : P
[16:19:15 CST(-0600)] <Bosmon8> So it seems that all that is required to is to extend "kettle.tests.buildTestCase" to be able to interpret more material from a "testDef"
[16:19:23 CST(-0600)] <Bosmon8> That is, to allow it to accept some gradeNames as well
[16:19:29 CST(-0600)] <Bosmon8> How lucky we are we still have you around : P
[16:20:05 CST(-0600)] <yzen> ok ill try to fix it tonight or tomorrow morning
[16:20:43 CST(-0600)] <Bosmon8> Then all we need to do is define a "gpii.tests.AcceptanceTestCaseHolder" grade with the appropriate mergePolicy
[16:20:53 CST(-0600)] <yzen> ok ill try that
[16:21:20 CST(-0600)] <Bosmon8> And add it into the options round about this line: https://github.com/GPII/universal/blob/master/tests/AcceptanceTests.js#L136
[16:52:21 CST(-0600)] <colinclark> Bosmon8: another quick and simplistic question for you
[16:52:25 CST(-0600)] <colinclark> if you can spare a sec
[16:52:42 CST(-0600)] <colinclark> or Bosmon
[16:52:44 CST(-0600)] <colinclark> either one of you
[16:52:49 CST(-0600)] <Bosmon8> Hi colinclark - it is me
[16:53:52 CST(-0600)] <colinclark> I have a component that fires an event
[16:54:23 CST(-0600)] <colinclark> and it passes along a "raw" object
[16:54:28 CST(-0600)] <colinclark> which another component listens for
[16:54:34 CST(-0600)] <colinclark> "parses" the raw object
[16:54:49 CST(-0600)] <colinclark> and fires a subsequent "higher level" event
[17:03:02 CST(-0600)] <colinclark> sorry
[17:03:11 CST(-0600)] <colinclark> someone waked into my office
[17:03:23 CST(-0600)] <colinclark> anyway, I wonder if there's any kind of simple way to handle this
[17:03:41 CST(-0600)] <colinclark> It's a kind of boiling scenario
[17:04:00 CST(-0600)] <colinclark> but in this particular case a Node.js Buffer needs to get JSONified in between
[17:06:37 CST(-0600)] <Bosmon8> You could write an expander in the args list of a boiled event
[17:06:48 CST(-0600)] <Bosmon8> It's a little unsightly but not unheard-of
[17:33:17 CST(-0600)] <Bosmon8> colinclark ^
[17:36:16 CST(-0600)] <colinclark> hi sorry, i'm back
[17:37:11 CST(-0600)] <michelled> Bosmon8: the error we are getting is http://pastie.org/8612209
[17:37:23 CST(-0600)] <michelled> does it seem like the same issue that yzen was seeing in tests?
[17:37:45 CST(-0600)] <colinclark> It's comparable to the issue I was seeing also when debugging on Ubuntu over the holidays
[17:37:53 CST(-0600)] <colinclark> but I checked for stray copies of Infusion and it appears to be all there
[17:38:19 CST(-0600)] <colinclark> michelled: I think I might, as a next step, try cloning a fresh copy of the windows repository
[17:38:20 CST(-0600)] <colinclark> and running the build scripts, etc.
[17:38:53 CST(-0600)] <colinclark> Bosmon8: So if I put an expander in the args list of the event, it will be expanded automatically every time the event fires? That's great
[17:38:57 CST(-0600)] <michelled> sure
[17:39:16 CST(-0600)] <colinclark> I guess I'll still have the issue of the expander eating my Buffer?
[17:39:21 CST(-0600)] <colinclark> in its voracious way
[17:43:56 CST(-0600)] <Bosmon8> colinclark - hopefully the issue only bites in the other direction
[17:44:03 CST(-0600)] <colinclark> chomp
[17:44:08 CST(-0600)] <Bosmon8> That is, an expander which returns a Buffer, rather than one which consumes one
[17:44:15 CST(-0600)] <colinclark> ok
[17:44:19 CST(-0600)] <colinclark> ok, that will help tidy up this code a lot
[17:44:44 CST(-0600)] <colinclark> sadly it won't reduce the latency of the sound it produces
[17:44:50 CST(-0600)] <colinclark> but that'll come
[17:44:55 CST(-0600)] <colinclark> michelled
[17:44:59 CST(-0600)] <colinclark> 's issue is very strange
[17:45:12 CST(-0600)] <colinclark> I mean, it looks like the same issue I wrestled with over the holiday
[17:45:16 CST(-0600)] <Bosmon8> michelled - that issue looks like it is caused by a mismatched version of Infusion being visible to Kettle
[17:45:19 CST(-0600)] <Bosmon8> Yes
[17:45:24 CST(-0600)] <Bosmon8> And it will have a very similar kind of cause
[17:45:44 CST(-0600)] <colinclark> At the point of the error, kettle.gradeLinkageRecord.userLoginHandlerSession does indeed have the "autoInit" grade
[17:45:50 CST(-0600)] <colinclark> so i can't think of what else it could be
[17:45:56 CST(-0600)] <colinclark> but I can't find any extra Infusions anywhere
[17:46:22 CST(-0600)] <Bosmon8> colinclark - as we discovered, the error never really refers to the absence of "autoInit" itself
[17:46:29 CST(-0600)] <Bosmon8> But actually to an "incomplete grade hierarchy"
[17:46:43 CST(-0600)] <Bosmon8> In this case what will be missing is "fluid.gradeLinkageRecord"
[17:46:53 CST(-0600)] <Bosmon8> You should try grepping throughout the tree for this to see what you find
[17:47:09 CST(-0600)] <Bosmon8> It may be that what has happened is that the version of Infusion is simply incorrect, rather than duplicated
[17:47:19 CST(-0600)] <Bosmon8> Since this depends on a framework feature which was only added a month or so ago
[17:47:29 CST(-0600)] <colinclark> ah, interesting
[17:48:00 CST(-0600)] <Bosmon8> Perhaps some kind of bad merge or checkout or npm install has somehow trashed the infusion revision
[17:48:28 CST(-0600)] <Bosmon8> But firstly search for as many versions of FluidIoC.js as you can find
[17:48:45 CST(-0600)] <Bosmon8> And then check that each one (hopefully just 1!) has fluid.defaults("fluid.gradeLinkageRecord") in it
[17:50:56 CST(-0600)] <avtar> colinclark, michelled: find /path/to/src -name infusion -type d
[17:52:58 CST(-0600)] <Bosmon8> Of course what has happened might be even more bizarre, and you actually have zero versions of Infusion in the checkout
[17:53:33 CST(-0600)] <colinclark> There is definitely one
[17:53:36 CST(-0600)] <Bosmon8> I remember in the very early days of working with node having issues with resolution "spilling" out into further parent directories until it eventually finds an appropriate node_modules
[17:53:46 CST(-0600)] <Bosmon8> Ok.... what does its FluidIoC.js look like
[17:53:53 CST(-0600)] <colinclark> We're blasting universal and re-running the build script first
[17:53:59 CST(-0600)] <Bosmon8> ok
[17:54:06 CST(-0600)] <colinclark> and then avtar's going to run his find script
[17:54:09 CST(-0600)] <Bosmon8>
[17:54:11 CST(-0600)] <colinclark> whcih is probably far more accurate than my eyes
[17:54:49 CST(-0600)] <Bosmon8> Or as we troglodytes say, dir FluidIoC.js /s
[17:55:37 CST(-0600)] <Bosmon8> Actually you really are on Windows, aren't you
[17:55:43 CST(-0600)] <Bosmon8> So the suggestion isn't completely troglodytic
[17:59:29 CST(-0600)] <colinclark> no, it's not
[17:59:41 CST(-0600)] <colinclark> michelled and I spent a few minutes REASONING about the issue
[17:59:54 CST(-0600)] <colinclark> while she waited for the monstrous universal repository to clone itself
[18:00:11 CST(-0600)] <colinclark> and our best bet is that it's a mismatched version of Infusion
[18:02:19 CST(-0600)] <Bosmon8> Yes
[18:02:36 CST(-0600)] <Bosmon8> Although like these CATTs, it's a little hard to imagine how it got there : P
[18:02:37 CST(-0600)] <Bosmon8> http://www.boredpanda.com/funny-sleeping-cats/
[18:04:12 CST(-0600)] <colinclark> these are amazing cats
[18:04:31 CST(-0600)] <colinclark> avtar was just telling me a story about how painful the massive size of Universal has been for him
[18:04:37 CST(-0600)] <colinclark> when running deployment tests as part of the costing project
[18:04:40 CST(-0600)] <Bosmon8> Right
[18:05:03 CST(-0600)] <colinclark> and how he ended up making yum packages instead of using git as a result
[18:05:04 CST(-0600)] <Bosmon8> Another reason we should make sure that Tony's mega-commit gets cherry-picked before it finally goes in : P
[18:05:08 CST(-0600)] <colinclark> lol
[18:05:10 CST(-0600)] <colinclark> yes
[18:05:36 CST(-0600)] <colinclark> wow, look at these tucked-in cats
[18:05:41 CST(-0600)] <colinclark> about halfway down
[18:05:43 CST(-0600)] <Bosmon8> Yes
[18:05:48 CST(-0600)] <colinclark> that might be the best thing ever
[18:05:48 CST(-0600)] <Bosmon8> Some of them seem on the other side of plausible
[18:06:00 CST(-0600)] <Bosmon8> Especially the one which appears to have fallen asleep in what looks like a drying rack
[18:06:17 CST(-0600)] <colinclark> the one folded into a box is pretty amazing, too
[18:06:25 CST(-0600)] <colinclark> he's basically unrecognizable as a cat
[18:06:31 CST(-0600)] <Bosmon8> hahahaha
[18:06:50 CST(-0600)] <colinclark> cats are so gifted at sleeping
[18:07:00 CST(-0600)] <Bosmon8> I feel that the one in a boot must have been put there
[18:07:10 CST(-0600)] <Bosmon8> Since I can't see how a CATT could get into a boot end-on without tipping it over
[18:07:42 CST(-0600)] <Bosmon8> Still cloning universal?
[18:07:54 CST(-0600)] <Bosmon8> Couldn't avtar just clone it from another instance of itself on the filesystem?
[18:08:37 CST(-0600)] <avtar> Bosmon8: the repo was getting cloned on new VMs
[18:08:50 CST(-0600)] <avtar> each time a new VM was provisioned
[18:09:50 CST(-0600)] <colinclark> As far as I know, michelled exclaimed a few minutes ago "I have a working system!"
[18:09:52 CST(-0600)] <Bosmon8> avtar - yes - couldn't you have set up a recent clone locally on NFS or so?
[18:09:57 CST(-0600)] <Bosmon8> colinclark - great
[18:09:58 CST(-0600)] <colinclark> So it must have been the case that she had an old version of Infusion
[18:10:02 CST(-0600)] <Bosmon8> ok
[18:10:08 CST(-0600)] <Bosmon8> Shame we can't find out what version she has
[18:10:09 CST(-0600)] <Bosmon8> had
[18:10:29 CST(-0600)] <avtar> Bosmon8: creating a package seemed like a better approach than sharing the fs using nfs
[18:10:31 CST(-0600)] <colinclark> I recommended that she, when reviewing changes that include new versions of dependencies in package.json, always delete the old version and run npm install again
[18:10:33 CST(-0600)] <michelled> colinclark: once you have the system running, how do you shut it down properly?
[18:10:45 CST(-0600)] <Bosmon8> michelled - CTRL-C
[18:10:47 CST(-0600)] <colinclark> CTRL-C
[18:10:47 CST(-0600)] <colinclark>
[18:10:49 CST(-0600)] <colinclark> it's awsome
[18:10:50 CST(-0600)] <michelled> ok
[18:10:54 CST(-0600)] <colinclark> awesome
[18:11:09 CST(-0600)] <Bosmon8> colinclark - hadn't she already got into that workflow? : P
[18:11:23 CST(-0600)] <michelled> so, the pull request I merged in didn't have any changes to package.json
[18:11:30 CST(-0600)] <colinclark> michelled: that's particularly weird
[18:11:40 CST(-0600)] <colinclark> after my holiday, I've become immensely distrustful of npm
[18:11:57 CST(-0600)] <Bosmon8> michelled - which pull request was it?
[18:12:15 CST(-0600)] <michelled> 180
[18:12:27 CST(-0600)] <colinclark> and I'm also distrustful of the fact that for vague and unspecified reasons, we still use Node 0.8.x on Windows
[18:12:31 CST(-0600)] <michelled> so, Bosmon8 what's the best practise when testing a pull to universal?
[18:12:40 CST(-0600)] <michelled> I currently have a clean and working system
[18:12:48 CST(-0600)] <Bosmon8> michelled - surely this was exactly what I was asking you and the team earlier
[18:14:03 CST(-0600)] <michelled> I'm going to fetch yzen's branch, merge it in, run nom install (even though there are no changes to package.json)
[18:14:16 CST(-0600)] <michelled> then start up the system and try out timothy's usb
[18:14:21 CST(-0600)] <michelled> does that sound reasonable?
[18:14:33 CST(-0600)] <Bosmon8> It's because I couldn't really lay my hands on any very usable best practices I was reluctant to review the pull requests : P
[18:14:38 CST(-0600)] <Bosmon8> Yes
[18:14:56 CST(-0600)] <Bosmon8> And you're on Windows now?
[18:15:09 CST(-0600)] <Bosmon8> And for these reasons still can't expect to run KASPARNET's acceptance tests?
[18:15:20 CST(-0600)] <colinclark> nom nom install
[18:16:25 CST(-0600)] <avtar> colinclark: have you tried this package manager for windows? http://chocolatey.org/
[18:16:34 CST(-0600)] <colinclark> No, I haven't
[18:16:43 CST(-0600)] <colinclark> I was going to ask you about it once
[18:17:13 CST(-0600)] <michelled> Bosmon8: yes
[18:17:50 CST(-0600)] <michelled> Bosmon8: if I've only merged in something new to universal, I don't need to rebuild in the windows directory, do I?
[18:17:50 CST(-0600)] <Bosmon8> michelled - I would try a couple of users via the web interface too
[18:18:01 CST(-0600)] <Bosmon8> michelled - no
[18:18:10 CST(-0600)] <Bosmon8> By rebuild you mean an npm install or so?
[18:18:18 CST(-0600)] <Bosmon8> We don't really yet have "builds" in GPII
[18:18:25 CST(-0600)] <avtar> colinclark: it appears to have packages for most of the dependencies listed on the gpii wiki
[18:18:30 CST(-0600)] <Bosmon8> Just a half-assed bunch of shell scripts that check things out in a particular arrangement : P
[18:18:42 CST(-0600)] <colinclark> oh, grunt
[18:18:56 CST(-0600)] <colinclark> some day we will be cursing you, like we curse npm now
[18:18:56 CST(-0600)] <michelled> I mean running the "build.cmd" which seems to clone universal if it doesn't exist and run nom install
[18:18:58 CST(-0600)] <avtar> node 0.10.24 though
[18:19:01 CST(-0600)] <colinclark> nom nom nom
[18:19:09 CST(-0600)] <Bosmon8> nom nom
[18:19:16 CST(-0600)] <colinclark> avtar: I think we probably should consider this
[18:19:33 CST(-0600)] <colinclark> actually
[18:19:34 CST(-0600)] <Bosmon8> michelled - I don't think I've ever run the build.cmd script except when testing build.cmd itself : P
[18:19:35 CST(-0600)] <colinclark> you know
[18:19:52 CST(-0600)] <colinclark> michelled: I do sometimes use it
[18:19:53 CST(-0600)] <Bosmon8> But this is mostly because I keep my checkout in a non-standard arrangement just to demonstrate that it is still possible
[18:20:05 CST(-0600)] <colinclark> but generally only in context of blasting the top-level node_modules directory and re-running it
[18:20:09 CST(-0600)] <colinclark> avtar: Actually
[18:20:22 CST(-0600)] <colinclark> So, I was thinking in the case of the Linux problems I faced
[18:20:38 CST(-0600)] <Bosmon8> This is because I still someday dream of a fix for http://issues.gpii.net/browse/GPII-3
[18:20:38 CST(-0600)] <colinclark> that we might want to stop embracing "whatever's in the distribution's package manager"
[18:20:53 CST(-0600)] <Bosmon8> But our architecture is only so old so it is impossible for JIRAs to be older than 18 months
[18:21:02 CST(-0600)] <colinclark> avtar: is it tedious to produce yum and ubuntu packages for things like Node.js and some of our other dependencies
[18:21:15 CST(-0600)] <colinclark> and, for that matter "choclatey" packages
[18:21:20 CST(-0600)] <colinclark> chocolatey
[18:21:57 CST(-0600)] <colinclark> I think in general you have to be quite vigilant for changes to package.json anywhere in our infrastructure, michelled
[18:22:11 CST(-0600)] <colinclark> which I think, practically, means universal, windows, linux, and android
[18:22:24 CST(-0600)] <colinclark> I think the best practice should be to blast, then npm install
[18:22:42 CST(-0600)] <colinclark> since I'm not convinced that all versions of npm are smart enough to recognize changes in a git-tracked dependency
[18:23:07 CST(-0600)] <Bosmon8> colinclark - I believe that none of them are
[18:23:11 CST(-0600)] <Bosmon8> At least, I've never seen one that was
[18:24:13 CST(-0600)] <Bosmon8> I guess I should reword that "cannot init component" diagnostic slightly
[18:24:30 CST(-0600)] <Bosmon8> It's not completely unhelpful, but it's not completely helpful either
[18:35:48 CST(-0600)] <avtar> colinclark: here's an fpm example https://github.com/disqus/fpm-recipes/blob/master/keepalived/Makefile similar to what we just discussed
[18:36:12 CST(-0600)] <colinclark> Bosmon8: How might you reword it?
[18:37:10 CST(-0600)] <avtar> they (disqus) only generate deb packages https://github.com/disqus/fpm-recipes/blob/master/include/base.mk#L64-L69
[18:37:28 CST(-0600)] <avtar> but a similar approach could be used to create debs and rpms
[18:37:34 CST(-0600)] <avtar> not sure about windows though
[18:38:32 CST(-0600)] <colinclark> avtar: I just pinged you on a Github issue
[18:38:52 CST(-0600)] <colinclark> Bosmon8 has pointed out the challenge of actually testing a CORS-related fix that yzen made
[18:39:02 CST(-0600)] <colinclark> I wonder if it's something you'd be able to easily help michelled test?
[18:39:27 CST(-0600)] <colinclark> Have you deployed the Cloud-based Flow Manager before?
[18:40:40 CST(-0600)] <Bosmon8> colinclark - the revised message might say, "The grade hierarchy of component Xxxxx is incomplete - most likely, a file declaring one of the grades [aaaaa, bbbb, cccc] is missing, outdated, or corrupt"
[18:40:52 CST(-0600)] <colinclark> ok
[18:41:20 CST(-0600)] <colinclark> I'm trying to think if there's anyway to detect multiple Infusion instances in a Kettle app
[18:41:29 CST(-0600)] <Bosmon8> colinclark there is, yes
[18:41:35 CST(-0600)] <Bosmon8> And I remember suggesting that yzen actually do this : P
[18:41:39 CST(-0600)] <colinclark> aha
[18:41:49 CST(-0600)] <colinclark> where's the point at which it needs to be done, though?
[18:42:06 CST(-0600)] <Bosmon8> It should be sufficient to do it at the point kettle initialises
[18:42:21 CST(-0600)] <Bosmon8> Clearly we don't need to cater for perverse cases like continuously self-modifying filesystems : P
[18:42:34 CST(-0600)] <Bosmon8> The only issue.... is where to STOP
[18:42:47 CST(-0600)] <Bosmon8> Which brings in a lot of the discussions we had in Linz about our need for a custom module loader
[18:43:04 CST(-0600)] <colinclark> yes, I remember those discussions quite well
[18:43:23 CST(-0600)] <colinclark> we have quite a lot of work ahead of us
[18:43:37 CST(-0600)] <colinclark> it's nice to have michelled helping us with it
[18:43:49 CST(-0600)] <Bosmon8> Yes, it is great
[18:44:52 CST(-0600)] <Bosmon8> I remember that the starting point for a lot of our plans would be a specially named file, which had the signification - "for all compliant node_modules below this point in the FS, load EVERYTHING"
[18:45:13 CST(-0600)] <Bosmon8> Which would later be refined to "Behave AS IF you had loaded everything"
[18:45:19 CST(-0600)] <avtar> colinclark: i see it now
[18:46:07 CST(-0600)] <Bosmon8> Which is also just the kind of FS barrier that we need in order to curtail our recursive search for duplicate copies of Infusion
[18:47:20 CST(-0600)] <Bosmon8> I'm also trying to remember the precise fate of yzen's "kettleModuleLoader" scheme that we eventually reasoned had to be abandoned
[18:47:56 CST(-0600)] <Bosmon8> With avtar's help, we eventually established that an app which expects to modify its own code loading filesystem cannot be tolerated
[18:48:55 CST(-0600)] <Bosmon8> Ah
[18:48:59 CST(-0600)] <Bosmon8> It actually still seems to be there
[18:49:19 CST(-0600)] <Bosmon8> Another thing for he and anastasiac to explain next week
[18:51:04 CST(-0600)] <Bosmon8> So another thing we will be free of when we write our own module loader is the bizarre requirement handed on to kettle users to sprinkle these kettleModuleLoader.js files everywhere
[18:59:24 CST(-0600)] <colinclark> it is there
[18:59:36 CST(-0600)] <colinclark> and I believe it's not, at least, self modifying
[18:59:54 CST(-0600)] <colinclark> it's annoying, in that everyone who ever creates a kettle app has to stick one of these files in their configuration
[19:00:01 CST(-0600)] <colinclark> anyway, I think most of us are heading out for the night
[19:00:15 CST(-0600)] <colinclark> michelled and I have made a plan to chip and chisel away at the outstanding pull requests
[19:00:24 CST(-0600)] <colinclark> where i'll do some further reviews
[19:00:32 CST(-0600)] <colinclark> time for me to do something more than writing reports
[19:00:45 CST(-0600)] <colinclark> Bosmon8: I think the one thing that might be lingering is this Infusion bug you were working on
[19:00:49 CST(-0600)] <colinclark> I forget the JIRA number