fluid-work IRC Logs-2012-10-10
- Fluid IRC Log Bot
[00:01:23 CDT(-0500)] <thealphanerd> sorry about the vanishing act there
[00:01:30 CDT(-0500)] <thealphanerd> I'm west coast now
[00:01:33 CDT(-0500)] <thealphanerd> so it is only 10 pm for me
[00:01:39 CDT(-0500)] <thealphanerd> although I don't do normal hours anyways{color}
[00:03:52 CDT(-0500)] <thealphanerd> Bosmon: do you have any example I could take a peek at of using infusion with node.js?
[00:03:57 CDT(-0500)] <thealphanerd> maybe a sample project
[00:05:06 CDT(-0500)] <Bosmon> Here's the GPII core project: https://github.com/GPII/universal
[00:05:26 CDT(-0500)] <Bosmon> Unfortunately it is not very regular or well documented
[00:05:37 CDT(-0500)] <Bosmon> It does sort of work : P
[00:05:49 CDT(-0500)] <thealphanerd> haha
[00:06:19 CDT(-0500)] <Bosmon> yura did most of the work in creating the "request" and "app" infrastructure
[00:06:39 CDT(-0500)] <Bosmon> It is build on the standard "express" module for node.js HTTP servers
[00:06:51 CDT(-0500)] <thealphanerd> yeah… I am about to start making a number of objects…. and was thinking it would be nice to do so with infusion
[00:07:02 CDT(-0500)] <Bosmon> It's all extremely raw stuff
[00:07:32 CDT(-0500)] <thealphanerd> fair enough
[00:07:34 CDT(-0500)] <Bosmon> But yes, it is the beginnings of our plans for server-side infrastructure using Infusion
[00:07:49 CDT(-0500)] <Bosmon> Right now it has no ability to render HTML interfaces except through the existing express mechanisms
[00:07:52 CDT(-0500)] <thealphanerd> have you seen _.js?
[00:08:00 CDT(-0500)] <Bosmon> Yes
[00:08:06 CDT(-0500)] <thealphanerd> do you use it at all?
[00:08:13 CDT(-0500)] <thealphanerd> or i guess you don't need to if you are using infusion
[00:08:14 CDT(-0500)] <Bosmon> It's neat and tidy, but it doesn't really do a lot : P
[00:08:19 CDT(-0500)] <Bosmon> We've had some discussions about it
[00:08:38 CDT(-0500)] <Bosmon> In theory it might be better to just defer to it for general functional programming tasks
[00:08:38 CDT(-0500)] <thealphanerd> I find it adds the ruby / python stuff missing from emc5
[00:08:49 CDT(-0500)] <Bosmon> But in practice it wouldn't buy us a great deal and would be a lot of upheaval
[00:09:01 CDT(-0500)] <Bosmon> All the FP stuff that we use at all regularly is already built into Infusion
[00:09:05 CDT(-0500)] <thealphanerd> I guess it is the difference between a hack and a framework
[00:09:40 CDT(-0500)] <thealphanerd> now once the obejct is done being built
[00:09:45 CDT(-0500)] <thealphanerd> do you jsut use require as per usual
[00:09:46 CDT(-0500)] <thealphanerd> ?
[00:09:52 CDT(-0500)] <thealphanerd> if you are making an npm module that is
[00:09:53 CDT(-0500)] <Bosmon> Well, that's a very interesting issue
[00:10:10 CDT(-0500)] <Bosmon> In the end we plan to disuse the npm system for Fluid-aware code
[00:10:16 CDT(-0500)] <Bosmon> You will see that there is a new thing called fluid.require
[00:10:22 CDT(-0500)] <Bosmon> Inside our module loader code
[00:10:29 CDT(-0500)] <thealphanerd> I've seen that
[00:10:37 CDT(-0500)] <Bosmon> But the Fluid approach to naming and addressing code is very different from the node.js model
[00:10:40 CDT(-0500)] <thealphanerd> but it kind of forces people wanting ot use a fluid module to need fluid
[00:10:51 CDT(-0500)] <Bosmon> Well sure... but they would have to have it anyway : P
[00:10:56 CDT(-0500)] <Bosmon> How else could they use a fluid module? : P
[00:11:03 CDT(-0500)] <thealphanerd> hmmm I'll rephrase
[00:11:20 CDT(-0500)] <thealphanerd> it would require them to use a different syntax specifically for npm modules designed in infusion
[00:11:31 CDT(-0500)] <Bosmon> Well, our aim is that in the end they will use no syntax
[00:11:36 CDT(-0500)] <Bosmon> fluid.require will eventually be removed
[00:11:43 CDT(-0500)] <Bosmon> It is just a stopgap measure until we build our new module loader
[00:11:51 CDT(-0500)] <thealphanerd> so how would that work then?
[00:11:58 CDT(-0500)] <Bosmon> Things will just load automatically : P
[00:12:25 CDT(-0500)] <Bosmon> After all, the IoC system should be powerful enough to automatically figure out what code is required for a particular definition
[00:12:38 CDT(-0500)] <Bosmon> This is actually once of the huge weaknesses of the node.js module loading system
[00:12:55 CDT(-0500)] <Bosmon> Unless you can get access to the code loading site of a 2nd-party library, it's impossible to load any 3rd-party code in it
[00:13:03 CDT(-0500)] <Bosmon> Which makes collaboration on large projects extremely difficult
[00:13:18 CDT(-0500)] <Bosmon> Something like the Fluid approach where dependencies are inferred automatically is the only way out
[00:13:27 CDT(-0500)] <Bosmon> Unfortunately fluid.require is an awful hack which temporarily makes things worse
[00:13:33 CDT(-0500)] <thealphanerd> so is this a problem with node or npm??
[00:13:46 CDT(-0500)] <Bosmon> Well, it's a problem with the way that that community thinks
[00:13:56 CDT(-0500)] <Bosmon> It affects all of the related "module" standards
[00:14:06 CDT(-0500)] <Bosmon> Not just npm, but amd etc. and all the others
[00:14:30 CDT(-0500)] <thealphanerd> hmmm… is it somethign that you think could be changed
[00:14:34 CDT(-0500)] <Bosmon> "require" is actually part of a thing called the "commonJS module spec"
[00:14:43 CDT(-0500)] <Bosmon> Not in less than about 20 years 
[00:15:11 CDT(-0500)] <Bosmon> People have been building up these ideas about how modules should work for more than 20 years
[00:15:22 CDT(-0500)] <Bosmon> It's reasonable to expect it will take more than 20 years to turn it around : P
[00:15:40 CDT(-0500)] <thealphanerd> to move closer to ioc
[00:15:47 CDT(-0500)] <Bosmon> http://wiki.commonjs.org/wiki/Modules
[00:15:52 CDT(-0500)] <Bosmon> Yes, and declarative programming in general
[00:16:15 CDT(-0500)] <Bosmon> CommonJS modules are designed for a world of code, all managed by individual programmers
[00:16:34 CDT(-0500)] <Bosmon> To tell people you don't want that world almost sounds like saying you don't want water to be wet : P
[00:17:18 CDT(-0500)] <Bosmon> One of the psychological traits common to almost all programmers is that they simply don't trust each other, and don't even trust themselves
[00:17:30 CDT(-0500)] <Bosmon> Hence they see things like insulating module systems as the highest kind of virtue
[00:17:31 CDT(-0500)] <thealphanerd> so how could it be done differently?
[00:17:39 CDT(-0500)] <thealphanerd> I'm still kind of wrapping my head around ico
[00:17:46 CDT(-0500)] <Bosmon> The fact I can't reach into 3rd party code and change the modules it loads is considered HIGHLY VIRTUOUS
[00:17:55 CDT(-0500)] <Bosmon> Since the person who wrote the code would prefer that I couldn't do this
[00:18:12 CDT(-0500)] <Bosmon> But if you think about it from the user perspective, you can see how damaging it is
[00:18:32 CDT(-0500)] <Bosmon> In order to change the activity of a 3rd-party library, I need to fork its code on github and ALTER it
[00:18:49 CDT(-0500)] <thealphanerd> and then change for package.json o reference a seperate package
[00:18:52 CDT(-0500)] <Bosmon> As opposed to some IOC-driven code where I would simply send it some different configuration
[00:18:54 CDT(-0500)] <thealphanerd> which you then need to maintain
[00:18:54 CDT(-0500)] <Bosmon> Yes, exactly
[00:19:19 CDT(-0500)] <Bosmon> So the "require" system only increases the fragility of already highly brittle code
[00:19:38 CDT(-0500)] <Bosmon> It's just one more point of contact between the code and its environment which is a hard binding that can't be changed except at the source level
[00:19:40 CDT(-0500)] <thealphanerd> so how would you bring external code in without require
[00:20:01 CDT(-0500)] <Bosmon> Well, under the Fluid IoC system, you only refer to code using "global function names"
[00:20:17 CDT(-0500)] <thealphanerd> but how would get node to initially load said code
[00:20:19 CDT(-0500)] <Bosmon> And it should just be the responsibility of the system to figure out where the code which produces those names can be found
[00:20:39 CDT(-0500)] <thealphanerd> so that by default for example, node knew to look in node_modules
[00:20:40 CDT(-0500)] <thealphanerd> ?
[00:20:58 CDT(-0500)] <Bosmon> Well, in the fulness of time we imagine a kind of "cascading" system that keeps a central index of which global names are found at which paths
[00:21:12 CDT(-0500)] <Bosmon> Periodically it would look in EVERY directory which matched a particular specification to see if it had any relevant code
[00:21:20 CDT(-0500)] <Bosmon> Using a naming convention similar to the node_modules system
[00:21:36 CDT(-0500)] <Bosmon> Only it would automatically look EVERYWHERE, not just upwards from the current directory on demand
[00:21:39 CDT(-0500)] <thealphanerd> would that be less efficient/
[00:21:59 CDT(-0500)] <Bosmon> It would certainly be more complex
[00:22:09 CDT(-0500)] <Bosmon> But at runtime, it might even be more efficient, since there would be no searching at that point
[00:22:20 CDT(-0500)] <Bosmon> That is, during production deployment, it would already know where every module was
[00:22:33 CDT(-0500)] <Bosmon> It would be slightly slower during development when the set of deployed code was changing frequently
[00:22:53 CDT(-0500)] <thealphanerd> i guess I would need to see it implemented ti fully wrap my head around it
[00:23:19 CDT(-0500)] <Bosmon> I guess we will need a basic version of it before, say, next summer
[00:23:32 CDT(-0500)] <Bosmon> Until then we will continue to suffer with fluid.require
[00:23:35 CDT(-0500)] <thealphanerd> hmmm… maybe I could work on the node.js stuff for gsoc next summer
[00:23:42 CDT(-0500)] <Bosmon> That would be awesome
[00:23:57 CDT(-0500)] <Bosmon> We should think about proposing suitable projects during the Spring
[00:24:03 CDT(-0500)] <thealphanerd> continue on my instrument… and couple it with node
[00:24:09 CDT(-0500)] <thealphanerd> but we have time to think about it 
[00:24:28 CDT(-0500)] <Bosmon> We proposed an IoC related project this year, but nobody took it
[00:24:35 CDT(-0500)] <Bosmon> Most likely because noone could understand what it was : P
[00:24:49 CDT(-0500)] <thealphanerd> stuff is head hurty
[00:24:58 CDT(-0500)] <thealphanerd> so I'm working right now on a quick little web app
[00:25:09 CDT(-0500)] <thealphanerd> to interface with a command line utility called osceleto
[00:25:10 CDT(-0500)] <thealphanerd> n
[00:25:17 CDT(-0500)] <Bosmon> Well, we have to believe that it can be made simple in the end
[00:25:36 CDT(-0500)] <Bosmon> I believe that if people started to be taught programming differently from the start, they'd find it quite straightforward
[00:25:41 CDT(-0500)] <thealphanerd> Bosmon: I think the problem is not simplicity… but merely thinking differently
[00:25:46 CDT(-0500)] <thealphanerd> idea jinx
[00:25:56 CDT(-0500)] <Bosmon> Actually if you think about what it takes to get somebody to the point that they're able to write conventional code well, it's VERY head hurty
[00:26:27 CDT(-0500)] <Bosmon> Right now it is doubly head hurty because at the moment there's no alternative to understanding BOTH ways of coding very well
[00:26:31 CDT(-0500)] <thealphanerd> its interesting how much my idea of programming has changed due to infusion though
[00:26:45 CDT(-0500)] <Bosmon> Infusion isn't yet at the stage of development where you can use it without already being a competent conventional developer
[00:27:11 CDT(-0500)] <Bosmon> But we imagine, eventually, a point at which ALL THE CODE IN THE WORLD has already been written : P
[00:27:33 CDT(-0500)] <Bosmon> I mean, how much code could there ACTUALLY be..... if you could actually find and use all of it effectively
[00:27:50 CDT(-0500)] <thealphanerd> well the problem is that things don't float free neough
[00:27:55 CDT(-0500)] <Bosmon> Yes
[00:28:04 CDT(-0500)] <Bosmon> There are many, many levels of the problem to be solved....
[00:28:17 CDT(-0500)] <thealphanerd> that was one of the cool things this summer… freeing functions from the confines of objects
[00:28:18 CDT(-0500)] <Bosmon> github is great in that it for the first time starts to enable something like the right community structure
[00:28:29 CDT(-0500)] <Bosmon> But unfortunately it still doesn't actually provide any real help with the problem of REUSE
[00:28:40 CDT(-0500)] <Bosmon> It just reduces the costs of "bad reuse"
[00:28:46 CDT(-0500)] <Bosmon> That is, fork or cut/paste
[00:29:42 CDT(-0500)] <Bosmon> And npm is fine as a distribution mechanism, but it doesn't do anything to move the "horizon" you bump into almost immediately when you discover someone's module doesn't do exactly what you want
[00:30:05 CDT(-0500)] <thealphanerd> do you use jslint when writing node?
[00:30:08 CDT(-0500)] <Bosmon> In some aspects, the world is moving in the right direction : P
[00:30:17 CDT(-0500)] <Bosmon> We are more and more tending to use "jshint" these days
[00:30:28 CDT(-0500)] <Bosmon> We have our own fork of jslint but mostly jshint does what we want now
[00:30:38 CDT(-0500)] <Bosmon> We haven't had time to make a wholesale move of the last bits of our stuff
[00:31:02 CDT(-0500)] <thealphanerd> are there particular flags for node code that you use?
[00:31:23 CDT(-0500)] <Bosmon> There's only one particularly relevant one
[00:31:26 CDT(-0500)] <Bosmon> The one for "assume node.js" : P
[00:31:34 CDT(-0500)] <Bosmon> Other than that, it just follows the rules for normal JS code
[00:31:49 CDT(-0500)] <Bosmon> It just automatically assumes that the various node globals like require/exports etc are defined
[00:33:05 CDT(-0500)] <thealphanerd> ahhh
[00:33:14 CDT(-0500)] <thealphanerd> I just switched my linter to jshint
[00:33:24 CDT(-0500)] <thealphanerd> not throwing a shit storm anymore
[00:34:08 CDT(-0500)] <Bosmon> It's much less snotty than Crockford's implementation
[00:34:17 CDT(-0500)] <Bosmon> I hear they're working on a new implementation that may even have test cases : P
[00:42:18 CDT(-0500)] <thealphanerd> for hint?
[00:42:23 CDT(-0500)] <Bosmon> yes
[00:42:34 CDT(-0500)] <Bosmon> The core developer is quite energetic
[00:42:43 CDT(-0500)] <thealphanerd> hmmm
[00:42:48 CDT(-0500)] <Bosmon> But I'm not sure he has grasped how big a work the complete reimplementation will be yet.....
[00:42:48 CDT(-0500)] <thealphanerd> cooolio
[00:43:21 CDT(-0500)] <thealphanerd> were you a gsoc mentor this usmmer?
[00:43:25 CDT(-0500)] <Bosmon> I was
[00:43:40 CDT(-0500)] <thealphanerd> are you going to the summit?
[00:43:51 CDT(-0500)] <Bosmon> Not this time
[00:43:56 CDT(-0500)] <thealphanerd> fair enough
[00:43:56 CDT(-0500)] <thealphanerd> '
[00:44:02 CDT(-0500)] <thealphanerd> I;'m right around the corner now
[00:44:07 CDT(-0500)] <thealphanerd> I wanna gate crash it
[00:44:10 CDT(-0500)] <Bosmon> cool
[00:44:14 CDT(-0500)] <Bosmon> I did get the T-shirt : P
[00:44:26 CDT(-0500)] <thealphanerd> I just got mine today
[00:44:31 CDT(-0500)] <thealphanerd> very well made shirt
[00:46:28 CDT(-0500)] <Bosmon> If you gatecrash the summit, make sure you inform them that all code must be abolished
[00:47:08 CDT(-0500)] <thealphanerd> all code?
[00:47:15 CDT(-0500)] <thealphanerd> must it all become data/
[00:47:17 CDT(-0500)] <thealphanerd> ?
[00:47:18 CDT(-0500)] <Bosmon> "essentially all code"
[00:47:53 CDT(-0500)] <thealphanerd> hehe
[00:47:54 CDT(-0500)] <Bosmon> So much of it that the small amount of actual code which remains will just be a tiny statistical blip
[00:48:45 CDT(-0500)] <Bosmon> Or looked at the other way, a world in which 99.9999% of the "code" which is produced is produced by people who we currently recognise as "non-programmers"
[00:49:00 CDT(-0500)] <Bosmon> Since clearly there are never ever going to be enough "programmers" to go around
[00:49:20 CDT(-0500)] <thealphanerd> hmmm
[00:50:23 CDT(-0500)] <Bosmon> We are living in a strange, pre-industrial world
[00:50:37 CDT(-0500)] <Bosmon> Where all "code" is made by hand by individual experts : P
[00:51:25 CDT(-0500)] <Bosmon> It's must like the world we were in when all cotton was spun by hand, etc.
[00:51:55 CDT(-0500)] <thealphanerd> so then will all code be gebnerated?
[00:52:32 CDT(-0500)] <Bosmon> Well, in a way yes, in a way no
[00:52:47 CDT(-0500)] <Bosmon> Clearly some substrate of "code" needs to remain under the system to make it actually run
[00:53:06 CDT(-0500)] <Bosmon> But above there will be something which is much more similar to "data"
[00:53:31 CDT(-0500)] <thealphanerd> I read a quote the other day
[00:53:37 CDT(-0500)] <thealphanerd> begininer programmers worry about code
[00:53:43 CDT(-0500)] <thealphanerd> decent programmers think about data
[00:53:50 CDT(-0500)] <thealphanerd> experts realize there is no difference
[00:53:51 CDT(-0500)] <Bosmon> I guess for some purposes of efficiency we may imagine generating "code" out of it, but it would be quite similar to the way in which high performance JS runtimes today will generate temporary little gobs of machine language from time to time
[00:54:10 CDT(-0500)] <Bosmon> Yes well, unfortunately in the 1960s the truth of this was much more obvious than it is today
[00:54:27 CDT(-0500)] <Bosmon> Unfortunately the level of interchangeability of code and data offered by Lisp/Scheme was never improved on
[00:54:51 CDT(-0500)] <Bosmon> The language just stagnated at its generally middling level of power and incomprehensibility : P
[00:55:21 CDT(-0500)] <Bosmon> In Lisp, all data is very clearly code, and all code is very clearly data
[00:55:39 CDT(-0500)] <Bosmon> But the interchangeability is so complete that you just end up in a featureless void of parentheses
[00:55:53 CDT(-0500)] <Bosmon> Noone ever moved on from there to think WHAT code exactly you wanted to be interchangeable with WHAT data : P
[00:56:52 CDT(-0500)] <Bosmon> But this is because all Lisp programmers were essentially schizoids.... they believed that solving a problem for themselves was good enough to solve it for everybody
[00:57:57 CDT(-0500)] <Bosmon> And they only ever planned for a world of people exactly like themselves
[00:58:04 CDT(-0500)] <Bosmon> A world of schizoid programmers.....
[01:34:56 CDT(-0500)] <thealphanerd> Bosmon: you still there?
[01:35:05 CDT(-0500)] <Bosmon> Just about : P
[01:35:09 CDT(-0500)] <thealphanerd> so
[01:35:15 CDT(-0500)] <thealphanerd> this was my original question about node
[01:35:27 CDT(-0500)] <thealphanerd> what do you use ot poke arouind in javascript land while programming in node
[01:35:35 CDT(-0500)] <thealphanerd> since you can't exactly use developer tools
[01:35:38 CDT(-0500)] <thealphanerd> in a browser that is
[01:35:39 CDT(-0500)] <Bosmon> There's a thing called node-inspector
[01:35:48 CDT(-0500)] <Bosmon> Which integrates with the debugging UI in Chrome
[01:35:55 CDT(-0500)] <Bosmon> It has a number of problems, but it's the best there is
[01:35:56 CDT(-0500)] <thealphanerd> snazzy
[01:36:16 CDT(-0500)] <Bosmon> Personally I mostly use a bunch of console.log statements unless I get really desperate
[01:36:29 CDT(-0500)] <thealphanerd> fair enough
[01:36:42 CDT(-0500)] <thealphanerd> break points are nice ot have though
[01:36:49 CDT(-0500)] <Bosmon> We're trying to write as many of our test cases as possible so that they run in the browser, even in code which in production would be node-only
[01:37:36 CDT(-0500)] <Bosmon> There's also a thing called BROWSERIFY which will take any node-aware code and package it so it runs in the browser
[01:37:46 CDT(-0500)] <Bosmon> It mocks up a certain selection of the core node libraries
[01:37:47 CDT(-0500)] <thealphanerd> interesting
[01:38:23 CDT(-0500)] <Bosmon> It is interesting, but in general we decided it was a bit too heavyweight for routine use
[01:38:46 CDT(-0500)] <Bosmon> It does involve an extra build step for the code packaging, and one of the marvellous advantages of JS is being mostly build-free
[01:38:53 CDT(-0500)] <Bosmon> But it's certainly something worth being aware of
[01:39:11 CDT(-0500)] <Bosmon> Most of its "cleverness" relates to unpicking the problems created by the "require" system which of course we hope to be free of anyway
[01:40:19 CDT(-0500)] <Bosmon> By far the biggest problem with node-inspector is that it only ever shows 10 stack frames at a time
[01:40:31 CDT(-0500)] <Bosmon> Which with the deep stacks created by Infusion is pretty fatal
[01:40:55 CDT(-0500)] <Bosmon> There doesn't seem to be any way to configure that problem away that I can see, it seems to require hacking on the node-inspector code itself
[01:41:02 CDT(-0500)] <Bosmon> It's surprisingly thinly maintained for such a crucial tool
[01:41:21 CDT(-0500)] <Bosmon> But then you can't expect someone to always appear in an open source community to do whatever work you consider crucial for free : P
[01:43:54 CDT(-0500)] <thealphanerd> fair enough
[08:11:10 CDT(-0500)] <Justin_o> jhung, cindyli: i don't think we'll be able to stop the process
[08:11:12 CDT(-0500)] <Justin_o> https://bitbucket.org/jobara/decapod-0.7-server-iteration2/src/1a304061d6d3/utils/backgroundTaskQueue.py?at=trunk#cl-47
[08:12:11 CDT(-0500)] <Justin_o> basically what we are using to run it as a background task basically just calls it as a function and doesn't even capture any return values or anything
[08:12:24 CDT(-0500)] <Justin_o> not that it may make much of a difference
[08:13:21 CDT(-0500)] <jhung> justin_o: okay. I think it's worth documenting in a JIRA and leave it.
[08:19:47 CDT(-0500)] <Justin_o> jhung: okay, going to check one other thing first
[08:19:55 CDT(-0500)] <Justin_o> jhung: did you file a jira for this yet
[08:19:57 CDT(-0500)] <Justin_o> ?
[08:20:27 CDT(-0500)] <jhung> justin_o: not yet, but I can do that in a few minutes...
[08:21:13 CDT(-0500)] <Justin_o> jhung: that's okay i can file one
[08:21:24 CDT(-0500)] <jhung> k thanks justin_o
[08:26:09 CDT(-0500)] <Justin_o> jhung: http://issues.fluidproject.org/browse/DECA-327
[08:27:42 CDT(-0500)] <jhung> thanks justin_o. What would be the long-term solution? Switching server platforms?
[08:36:39 CDT(-0500)] <Justin_o> jhung: potentially.. the other thing cindyli and I just looked at was to get the process id from the function we use to execute command line calls.. however, that one currently will wait till the command finishes executing before it returns the id
[08:37:01 CDT(-0500)] <Justin_o> so there maybe something there we could adjust, but it isn't immediately clear what that would be
[08:37:41 CDT(-0500)] <jhung> justin_o: okay. Let me know what you find.
[08:38:39 CDT(-0500)] <Justin_o> jhung: we're probably going to have to put it on hold at this point to get the other work done, but we can come back to it if you think it is high priority
[09:01:27 CDT(-0500)] <Justin_o> cindyli: I've updated http://wiki.fluidproject.org/display/fluid/Installing+Decapod+Stereo+Dewarping+Notes
[09:01:58 CDT(-0500)] <cindyli> thanks, Justin_o
[09:01:58 CDT(-0500)] <Justin_o> I'm running through dwarping now.. no errors but hasn't finished yet
[09:02:04 CDT(-0500)] <cindyli> cool
[10:02:09 CDT(-0500)] <michelled> alexn1: I'm just looking at your OER commons branch
[10:02:17 CDT(-0500)] <michelled> it's a huge improvement
[10:02:48 CDT(-0500)] <jhung> justin_o how long did it take to dewarp?
[10:03:02 CDT(-0500)] <Justin_o> jhung: a long time
[10:03:24 CDT(-0500)] <Justin_o> i didn't count, but it was quite a while.. i can run it again and give you the rough estimate on the time
[10:03:45 CDT(-0500)] <jhung> Ok thanks.
[10:04:02 CDT(-0500)] <alexn1> michelled: are you looking into OER-793 ?
[10:04:18 CDT(-0500)] <michelled> yes
[10:04:24 CDT(-0500)] <alexn1> michelled: ok
[10:05:09 CDT(-0500)] <alexn1> michelled: I had to add CSS for 2 more images and improved the code by eliminating copy paste with an introduced mixin
[10:05:41 CDT(-0500)] <michelled> alexn1: yes, the mixin is great
[10:06:47 CDT(-0500)] <alexn1> michelled: let me know if I need to improve anything or you have any second thoughts about any part of code there. I will address those.
[10:06:47 CDT(-0500)] <michelled> alexn1: I think you could get rid of a slight bit more repetition by using background-size instead of background in your mixin for :hover, .active and .disabled
[10:07:42 CDT(-0500)] <alexn1> michelled: you are referring px part of that background css statement ?
[10:08:12 CDT(-0500)] <michelled> yes, the only part that changes in those declarations
[10:09:42 CDT(-0500)] <alexn1> michelled: Yes I was thinking about this one. The only my few thoughts about this - I tried to do it before it generates so much CSS and then it is a bit tricky to read CSS rules instead of one background css rule.
[10:10:30 CDT(-0500)] <alexn1> michelled: my apologies for all those typing mistakes, my head is somewhere else solving problems.
[10:10:34 CDT(-0500)] <michelled> alexn1: tricky when? given that the CSS is being generated
[10:11:03 CDT(-0500)] <alexn1> sure. michelled give me a second
[10:20:05 CDT(-0500)] <alexn1> michelled: actually nevermind. It just extra few lines added and hard to read is pretty subjective. I will make a change in that pull request. Thanks a lot for looking into this michelled
[10:20:27 CDT(-0500)] <michelled> np alexn1
[10:30:13 CDT(-0500)] <alexn1> michelled: I made the change. Let me know what do you think about it https://github.com/anvk/OER-Commons/compare/ISKME:staging...OER-793
[10:31:43 CDT(-0500)] <michelled> alexn1: I'm wondering why you are passing width in - it looks to me like it will always be 38
[10:46:28 CDT(-0500)] <jhung> justin_o, cindyli : my dewarp somehow broke on my VM. I'm getting " File "/usr/local/lib/python2.7/dist-packages/pyflann-1.6.11-py2.7.egg/pyflann/index.py", line 27, in <module>
[10:46:28 CDT(-0500)] <jhung> from bindings.flann_ctypes import *
[10:46:28 CDT(-0500)] <jhung> ImportError: No module named bindings.flann_ctypes"
[10:46:35 CDT(-0500)] <jhung> did either of you experience similar?
[10:48:30 CDT(-0500)] <alexn1> michelled: It could potentially change. I just tried not to hardcode any values and leave function to be more dynamic
[10:49:04 CDT(-0500)] <alexn1> michelled: and it is not really passed. value 38 is used by default but it could be overwritten if passed
[10:49:29 CDT(-0500)] <alexn1> michelled: plus it actually changes for 2 icons
[10:49:31 CDT(-0500)] <alexn1> nclude write-toolbar-button(align-text, -294px, 60px);
[10:49:39 CDT(-0500)] <alexn1> @include write-toolbar-button(media, -608px, 81px);
[10:51:12 CDT(-0500)] <cindyli> no, jhung, did you copy the pyflann/ dir into your decapod-dewarping/ dir?
[10:52:56 CDT(-0500)] <michelled> ah, I didn't notice that alexn1
[10:54:15 CDT(-0500)] <michelled> this looks really great. you don't need to change this unless you want to, but I just wanted to clarify that I hadn't meant for you to remove using 'background' for the basic styling. I just meant that you should remove it - as you have - for the overrides for hover, active and disabled
[10:54:38 CDT(-0500)] <alexn1> michelled: my bad I did not mention it in the beginning but it is being a while so I'm trying to remember all the details
[10:55:35 CDT(-0500)] <alexn1> michelled: oh… great point
[11:00:09 CDT(-0500)] <alexn1> michelled: I assume this looks as the final version https://github.com/anvk/OER-Commons/compare/ISKME:staging...OER-793
[11:01:13 CDT(-0500)] <michelled> as long as you've tested it alexn1 - it looks really great. So much more maintainable
[11:02:37 CDT(-0500)] <alexn1> michelled: thx. I was doing test locally here every time I was about to paste comparison github link in a channel. I'm going to submit a pull request to staging then. Thanks a lot for your time and great feedback.
[11:03:20 CDT(-0500)] <alexn1> I will try to find a minute today and update on of other pull requests I have with the latest staging.
[11:04:25 CDT(-0500)] <michelled> alexn1: great
[11:13:52 CDT(-0500)] <Justin_o> fluid-everyone: we have a conflict with our space here so the community meeting will be cancelled this week, and the topic moved to one of the next two
[13:21:39 CDT(-0500)] <jessm> anastasiac: ping – i'm sorry to always ask – where is your documentation for a11y for the oer commons work?
[13:22:30 CDT(-0500)] <anastasiac> jessm: http://wiki.fluidproject.org/display/docs/Quick-and-Dirty+Website+Accessibility+Tests+-+and+Fixes and http://wiki.fluidproject.org/display/docs/Working+With+UI+Options+On+Your+Site I believe
[13:27:21 CDT(-0500)] <michelled> Bosmon: you were saying that it would be better to do something more conventional for this lookup table: https://github.com/michelled/videoPlayer/blob/FLUID-4701/js/VideoPlayer_html5Captionator.js#L51
[13:27:34 CDT(-0500)] <michelled> I'm not quite seeing how to do that
[13:27:38 CDT(-0500)] <Bosmon> Yes
[13:27:48 CDT(-0500)] <Bosmon> The choices for "standard things" include event listeners, invokers, and subcomponents
[13:28:09 CDT(-0500)] <Bosmon> The basic aim is to get over to a kind of system where demands blocks could be effective, as well as just "overriding configuration"
[13:28:19 CDT(-0500)] <Bosmon> Since demands blocks uniquely have the power to influence signatures as well as names
[13:28:30 CDT(-0500)] <michelled> right
[13:28:31 CDT(-0500)] <Bosmon> With the current system you have there, only the function name could be changed
[13:28:40 CDT(-0500)] <Bosmon> And as you say, it isn't immediately obvious what to do
[13:28:54 CDT(-0500)] <Bosmon> Although I was just speculating this is a case it would be nice if model transformations could help with in the long run
[13:30:20 CDT(-0500)] <Bosmon> The lookup table you have written there is good
[13:30:25 CDT(-0500)] <Bosmon> The question is what happens to it next
[13:32:08 CDT(-0500)] <Bosmon> Perhaps one really cheap way out might be to just use fluid.invoke rather than fluid.invokeGlobalFunction
[13:32:26 CDT(-0500)] <Bosmon> It seems a bit rickety but is conceivable
[13:32:31 CDT(-0500)] <michelled> what's the difference?
[13:32:47 CDT(-0500)] <Bosmon> The call via fluid.invoke will be routed accounting for any relevant demands blocks
[13:32:59 CDT(-0500)] <Bosmon> Whereas fluid.invokeGlobalFunction just invokes the exact named function directly
[13:33:12 CDT(-0500)] <Bosmon> We really haven't made any serious use of fluid.invoke so far, but it just occured to me
[13:33:16 CDT(-0500)] <Bosmon> yura may be interested : P
[13:33:59 CDT(-0500)] <michelled> perhaps I should just change from the lookup table to invokers of the same name - ones that could be found based on track type
[13:34:30 CDT(-0500)] <michelled> although that would be very odd naming for the invokers
[13:34:48 CDT(-0500)] <Bosmon> Yes
[13:35:01 CDT(-0500)] <Bosmon> You couldn't really guarantee that arbitrary mime type names were usable as invoker names
[13:41:03 CDT(-0500)] <Bosmon> I was thinking you might do something "cute" like generating type tags from the names.... but actually it isn't enough just to have ONE of these active at a time, I see you need support for multiple track types per component
[13:41:15 CDT(-0500)] <Bosmon> So probably the scheme using fluid.invoke() is the best one we can think of for now
[13:41:35 CDT(-0500)] <Bosmon> We should also remember to use it in other cases where we have ordinarily used fluid.invokeGlobalFunction
[13:46:07 CDT(-0500)] <michelled> Bosmon: what do I pass for environment to invoke?
[13:46:13 CDT(-0500)] <Bosmon> Nothing is fine
[13:57:18 CDT(-0500)] <jhung> justin_o, cindyli - dewarp UI is here: http://wiki.fluidproject.org/display/fluid/Decapod+0.7+Dewarp+UI+Design
[13:57:29 CDT(-0500)] <Justin_o> jhung: thanks
[13:58:02 CDT(-0500)] <Justin_o> jhung: can we centre the ui on the page
[13:59:12 CDT(-0500)] <Justin_o> jhung: hmm.. you want to report back the number of pairs that were found before dwarfing?
[13:59:18 CDT(-0500)] <michelled> Bosmon: can you look at my pull request once more? https://github.com/fluid-project/videoPlayer/pull/69/files
[13:59:28 CDT(-0500)] <jhung> justin_o: very true. Originally we had intended to put the Export Queue in that space to the right.
[13:59:29 CDT(-0500)] <michelled> I've tested it and it works and the tests all pass
[14:00:00 CDT(-0500)] <jhung> justin_o: yes. Or any sort of message to confirm that it is indeed a valid archive for dewarping.
[14:00:19 CDT(-0500)] <Justin_o> jhung: this is interesting.. because cindyli and I had thought the processes worked a bit differently
[14:00:47 CDT(-0500)] <Justin_o> jhung: we were thinking that it is a single process.. so you would upload the file and it would automatically unpack and dewarp it
[14:01:43 CDT(-0500)] <Justin_o> also when it says dwarfing capture the number refers to the pair right?
[14:03:03 CDT(-0500)] <Bosmon> michelled - I notice that VideoPlayer_transcript.js still needs some of the same treatment
[14:03:37 CDT(-0500)] <jhung> Justin_o: 1. Yes, it was done this way because the dewarp takes so long. We may need to present a warning before we dewarp.
[14:03:40 CDT(-0500)] <michelled> Bosmon: I'd rather not touch transcripts in this pull request because it's in need of a full overhaul and I'm working on that in another branch
[14:03:53 CDT(-0500)] <Bosmon> Also line 356 of that file is extremely strange
[14:03:55 CDT(-0500)] <Bosmon> michelled - ok
[14:04:22 CDT(-0500)] <jhung> 2. Yes. The numbers refer to the index of the pair currently being dewarped.
[14:05:10 CDT(-0500)] <Justin_o> jhung: one more, the save dialog that you have at the end.. that's just filler for the browsers save dialog
[14:05:11 CDT(-0500)] <Justin_o> ?
[14:05:31 CDT(-0500)] <jhung> yes.
[14:05:37 CDT(-0500)] <michelled> Bosmon: I just kept transcripts working with the new Captionator fork
[14:06:05 CDT(-0500)] <Justin_o> jhung: okay.. cindyli and I will have to update the server for the change to how dwarping is done
[14:06:48 CDT(-0500)] <jhung> Thanks justin_o and cindyli. I believe the Calibration UI will be a very similar interaction.
[14:06:58 CDT(-0500)] <Justin_o> jhung: okay
[14:11:27 CDT(-0500)] <Bosmon> michelled - how do the html5Captionator.hideAllTracks and showCurrentTrack methods actually work?
[14:13:55 CDT(-0500)] <Bosmon> That is, how does assigning anything to track.mode actually have any effect?
[14:14:02 CDT(-0500)] <Bosmon> Is this some odd kind of HTML% magic?
[14:14:05 CDT(-0500)] <Bosmon> HTML5
[14:14:25 CDT(-0500)] <michelled> well, if anything it's Captionator magic
[14:14:30 CDT(-0500)] <michelled> let me look
[14:15:44 CDT(-0500)] <Justin_o> cindyli, jhung: I made some changes to the server spec for dewarp.. let me know what you think http://wiki.fluidproject.org/display/fluid/Proposed+Decapod+Dewarp+Server+Architecture
[14:19:15 CDT(-0500)] <Bosmon> michelled - I guess I'm just wondering why it isn't necessary to fire some kind of event to let captionator know that track.mode has been updated
[14:19:57 CDT(-0500)] <jhung> Justin_o: looks good.
[14:20:31 CDT(-0500)] <michelled> Bosmon: looks like we are banking on an implementation detail in captionator 
I guess I hadn't read the existing code clearly enough.
[14:20:54 CDT(-0500)] <Bosmon> And if we are depending on some particular lifecycle activity of captionator in order to honour this setting from preInit, one would worry that 3rd parties who might call "hideAllTracks" wouldn't get the benefit of this
[14:21:11 CDT(-0500)] <Bosmon> Although we might well declare hideAllTracks etc. an implementation detail of the component, it still seems potentially dodgy
[14:21:53 CDT(-0500)] <Bosmon> In particular, how do we know that the refreshCaptions method will always work?
[14:22:09 CDT(-0500)] <Bosmon> It seems to just call one of these two methods as a final action
[14:25:08 CDT(-0500)] <michelled> Bosmon: I can't tell from this whether there is a browser event that we should be firing: http://dev.w3.org/html5/spec/single-page.html#text-track
[14:25:18 CDT(-0500)] <michelled> or whether we should just be changing the mode on the Track
[14:25:57 CDT(-0500)] <Bosmon> Oh, ok
[14:26:03 CDT(-0500)] <Bosmon> So "track" really is an HTML5 native object
[14:26:17 CDT(-0500)] <michelled> oh, yeah - just not available everywhere yet
[14:26:22 CDT(-0500)] <michelled> hence Captionator
[14:26:43 CDT(-0500)] <Bosmon> Well ok, but if it wasn't REALLY a native, how could it sense this update?
[14:26:47 CDT(-0500)] <michelled> Track is now in Safari and Chrome when you turn on a flag
[14:27:17 CDT(-0500)] <michelled> internally, captionator checks for the mode before showing a caption - every time
[14:28:00 CDT(-0500)] <Bosmon> I see.... but this means then that it won't react until the next time it is due to show a caption?
[14:28:57 CDT(-0500)] <Bosmon> I notice that captionator is actually using a JS "property" to track the mode flag
[14:29:14 CDT(-0500)] <Bosmon> But I wonder which browsers this is good for
[14:29:56 CDT(-0500)] <Bosmon> The relevant block is here: https://github.com/michelled/videoPlayer/blob/30b3fd380be45456d5436f61624f95c9305cb6de/lib/captionator/js/captionator.js#L214-225
[14:30:03 CDT(-0500)] <Bosmon> What do we know about the portability profile of this code......
[14:30:40 CDT(-0500)] <Bosmon> I guess it conceivably works in IE9 and 10
[14:30:44 CDT(-0500)] <Bosmon> Is that all we need to support?
[14:31:55 CDT(-0500)] <michelled> no, we need IE8 too, but we are using media js for that. cindyli has a branch that is still waiting for someone to pick up that puts in IE8 support
[14:32:44 CDT(-0500)] <Bosmon> ok
[14:34:40 CDT(-0500)] <Bosmon> It looks like this construction will be supported on all of our supported browsers then.... http://kangax.github.com/es5-compat-table/
[14:34:53 CDT(-0500)] <Bosmon> Do we explicitly list somewhere what the required browser support for the HTML5 captionator is?
[14:35:18 CDT(-0500)] <michelled> no
[14:35:37 CDT(-0500)] <michelled> I guess we haven't made a decision on what the official browser support for the video player is
[14:36:02 CDT(-0500)] <michelled> but unofficially, I'd say it's latest Chrome, FF, Safari and IE 8, 9, 10
[14:37:37 CDT(-0500)] <Bosmon> Ok
[14:37:54 CDT(-0500)] <Bosmon> These lines seem left over from a very early implementation and seem unnecessary: https://github.com/michelled/videoPlayer/blob/30b3fd380be45456d5436f61624f95c9305cb6de/js/VideoPlayer_html5Captionator.js#L96-98
[14:38:20 CDT(-0500)] <michelled> yeah, good catch
[14:42:24 CDT(-0500)] <Bosmon> Other than this, this looks ok
[14:42:48 CDT(-0500)] <Bosmon> I'm a little suspicious of the track-counting events, but there doesn't seem to be any huge immediate benefit to improving it
[14:43:05 CDT(-0500)] <michelled> yes, I was very uncomfortable when I added that
[14:43:08 CDT(-0500)] <Bosmon> For example, if one of the tracks fires zero or more than 1 event, or there are zero tracks, the component will jam
[14:43:29 CDT(-0500)] <Bosmon> But we don't really have any clear improved alternative to having the component jam
[14:43:37 CDT(-0500)] <Bosmon> We should still note it as an implementation risk to be looked at
[14:43:46 CDT(-0500)] <michelled> ok
[14:48:55 CDT(-0500)] <Bosmon> Just thinking about the fetchAmaraJSON function
[14:49:09 CDT(-0500)] <Bosmon> I'm still astounded that this line works at all: var url = "http://www.universalsubtitles.org/api/1.0/subtitles/?video_url=" + videoUrl + "&callback=?";
[14:51:41 CDT(-0500)] <Bosmon> michelled - would you like to try properly URI-encoding it and seeing if it still works?
[14:56:40 CDT(-0500)] <michelled> Bosmon: I just wrapped it in 'encodeURI' and it does still work
[14:56:46 CDT(-0500)] <Bosmon> cool
[14:57:04 CDT(-0500)] <Bosmon> I guess that leaving "monkey-patching" as the expected means of configuration here is sort of acceptable
[14:57:22 CDT(-0500)] <Bosmon> If universalsubtitles moves or goes away, the world has changed in some very significant way....
[14:58:09 CDT(-0500)] <michelled> yes
[14:58:47 CDT(-0500)] <michelled> also, given that jsonp is somewhat dangerous I was hoping that hiding it away like that would cause people to think about whether they really want to change that url
[14:58:53 CDT(-0500)] <michelled> am I being silly?
[14:59:09 CDT(-0500)] <Bosmon> Well, I think they shouldn't be discouraged from changing that URL if they need to : P
[14:59:13 CDT(-0500)] <Bosmon> Either they need to or they don't
[14:59:24 CDT(-0500)] <Bosmon> Right now our current strategy is based on assuming that it is enormously unlikely
[15:00:21 CDT(-0500)] <michelled> to be honest, we'll be changing it soon to use the new amara API which involved two calls to them - first to get the ID of the video then to get the subtitles
[15:00:46 CDT(-0500)] <michelled> so it feels like the whole strategy would change - not just the url
[15:00:52 CDT(-0500)] <Bosmon> ok
[15:01:11 CDT(-0500)] <Bosmon> I'm wondering whether it might not be better to just split off all Amara-specific stuff into its own file
[15:01:25 CDT(-0500)] <Bosmon> This is now much easier now that it isn't hard-coded into the captionator wrapper
[15:03:03 CDT(-0500)] <michelled> I could see how that might be better - perhaps I can do it with the transcript refactoring work?
[15:03:19 CDT(-0500)] <Bosmon> ok
[15:03:30 CDT(-0500)] <Bosmon> I think this is ready to go then
[15:04:51 CDT(-0500)] <michelled> thanks!
[15:20:45 CDT(-0500)] <michelled> anastasiac: my 4701 branch is in now - I know you have a branch based on it
[15:20:54 CDT(-0500)] <michelled> I've made updates based on code review from Bosmon
[15:21:21 CDT(-0500)] <anastasiac> michelled: yay! congrats. I'll update my branches. You captionator 4701 branch is also in?
[15:21:28 CDT(-0500)] <anastasiac> *your
[15:21:58 CDT(-0500)] <alexn2> michelled: I managed to update another branch to the latest staging https://github.com/anvk/OER-Commons/compare/ISKME:staging...OER-798 Could you please review it whenever you have a free minute?
[15:22:12 CDT(-0500)] <michelled> anastasiac: not into the project repo yet anastasiac, but the comments in the video player branch point to the correct branch in my repo
[15:22:38 CDT(-0500)] <anastasiac> michelled, my changes involve changes to captionator itself, built upon your changes
[15:22:47 CDT(-0500)] <anastasiac> any eta on the captionator branch going in?
[15:23:14 CDT(-0500)] <anastasiac> why has it not been merged yet?
[15:23:19 CDT(-0500)] <michelled> interesting. I think colin wanted me to improve the code before it went in but we agreed that we should move forward on the video player itself
[15:23:29 CDT(-0500)] <michelled> anastasiac: I guess I'll pick that branch up again
[15:23:46 CDT(-0500)] <michelled> sure alexn2
[15:24:43 CDT(-0500)] <alexn2> michelled: thx !
[15:27:12 CDT(-0500)] <alexn2> michelled: do not hesitate to ping me for any question since it is a pretty big change in a branch which involved almost every file type in OER Commons: coffee, js, html markup, django files.
[15:28:02 CDT(-0500)] <michelled> ok alexn2
[15:29:05 CDT(-0500)] <michelled> anastasiac: your pull request for 4780 means both of alexn2's pull requests for 4780 and 4783 should be closed, right?
[15:29:15 CDT(-0500)] <michelled> sorry, 4743
[15:30:20 CDT(-0500)] <anastasiac> michelled, yes, that's correct
[15:33:18 CDT(-0500)] <michelled> anastasiac: I'm feeling a little swamped - do you think you could merge the current demo branch into the alexn2's branch for FLUID-4787?
[15:33:34 CDT(-0500)] <anastasiac> sure, michelled
[15:33:40 CDT(-0500)] <michelled> thx
[15:40:02 CDT(-0500)] <anastasiac> michelled, I'm a bit confused about FLUID-4787: I'm finding that currently, the demo branch is already successfully hiding native controls for webkit browsers. Not quite sure when that happened… can you confirm?
[15:40:20 CDT(-0500)] <anastasiac> might be a webkit upgrade??
[15:40:59 CDT(-0500)] <michelled> anastasiac: no, the bug fix probably went in accidentally, but the main thing in alexn2's branch is the test refactoing
[15:41:18 CDT(-0500)] <anastasiac> ok, michelled, just double-checking my sanity
[15:41:20 CDT(-0500)] <michelled> the bug was a typo in a path
[15:42:23 CDT(-0500)] <michelled> anastasiac: on this line: https://github.com/anvk/videoPlayer/blob/1289a5d68147cc145eb7fc310b5167249550a27d/js/VideoPlayer_html5Captionator.js#L97
[15:42:36 CDT(-0500)] <michelled> there used to be a missing 's'
[15:43:14 CDT(-0500)] <anastasiac> michelled, sorry, I'm confused. Is that comment related to FLUID-4787?
[16:45:09 CDT(-0500)] <thealphanerd> Bosmon: you there?
[18:43:48 CDT(-0500)] <Bosmon> Hey thealphanerd
[18:43:53 CDT(-0500)] <thealphanerd> eyo