fluid-work IRC Logs-2013-01-31
[10:19:06 CST(-0600)] <yzen1> colinclark: would you have a moment to review these 2 pull requests https://github.com/fluid-project/infusion/pull/257 and https://github.com/fluid-project/infusion/pull/256?
[10:20:41 CST(-0600)] <colinclark> yzen: Yup, I think so
[10:21:21 CST(-0600)] <yzen> colinclark: thanks
[14:14:12 CST(-0600)] <Justin_o> anastasiac: do we have a common way to get the times from a track no matter which type of transcript format it is from?
[14:15:03 CST(-0600)] <anastasiac> Justin_o, when you say "get the times from the track", do you mean retrieve time codes from the track file itself?
[14:15:31 CST(-0600)] <Justin_o> anastasiac: not sure how to describe this properly.. maybe i'll just show you the test i'm trying to write
[14:25:49 CST(-0600)] <Bosmon> avtar - is it just me, or is our JIRA running very slowly right now?
[14:26:09 CST(-0600)] <Bosmon> I'm getting about a 10 second pause on responding to every request
[14:26:50 CST(-0600)] <Justin_o> Bosmon: it seems okay locally here for me
[14:27:21 CST(-0600)] <Justin_o> Bosmon: by the way, do you have thoughts on the e-mail i sent to the work list about the order of options in the defaults
[14:28:07 CST(-0600)] <Bosmon> Justin_o - my thoughts are similar to those of Ford Prefect when asked what colour the first wheel should be
[14:28:23 CST(-0600)] <Justin_o> Bosmon:
[14:29:24 CST(-0600)] <Justin_o> this is just a convention anyways.. to make it easier for us to find things.. so i guess we can just settle on something, whatever that is, soon.
[14:32:53 CST(-0600)] <Justin_o> anastasiac: i filed that issue we were talking about for the transcript time codes http://issues.fluidproject.org/browse/VP-261
[14:34:00 CST(-0600)] <anastasiac> thanks, Justin_o
[14:38:05 CST(-0600)] <avtar> Bosmon: one sec
[14:42:14 CST(-0600)] <Bosmon> Still slow for me
[14:42:19 CST(-0600)] <Bosmon> Even loading a JIRA page I just loaded
[14:44:26 CST(-0600)] <yzen> colinclark: have you had a chance to take a look at the pull requests by any chance ? there are 3 now
[14:44:36 CST(-0600)] <colinclark> not yet, yzen
[14:44:42 CST(-0600)] <colinclark> but i will!
[14:44:53 CST(-0600)] <yzen> colinclark: i can ask Bosmon if you want, if he has time ?
[14:45:00 CST(-0600)] <colinclark> sheesh
[14:45:11 CST(-0600)] <colinclark> i'm getting dropped as yzen's code reviewer
[14:45:12 CST(-0600)] <colinclark>
[14:45:18 CST(-0600)] <Bosmon> No you aren't
[14:45:21 CST(-0600)] <yzen> tsk tsk tsk
[14:45:32 CST(-0600)] <avtar> Bosmon: what's the jira# you're looking at?
[14:45:58 CST(-0600)] <Bosmon> avtar - any JIRA request at all
[14:46:44 CST(-0600)] <Bosmon> For example, this very small page takes 10 seconds to load for me
[14:46:44 CST(-0600)] <Bosmon> http://issues.fluidproject.org/browse/FLUID-4911
[14:47:04 CST(-0600)] <colinclark> it loads instantaneously for me
[14:47:07 CST(-0600)] <yzen> Bosmon: avtar i noticed it too
[14:47:08 CST(-0600)] <colinclark> but i am in the office
[14:47:22 CST(-0600)] <yzen> it takes for rever to inline edit the jira for me as well
[14:47:26 CST(-0600)] <yzen> forever
[14:47:57 CST(-0600)] <colinclark> weird
[14:48:40 CST(-0600)] <colinclark> It's pretty fast on my phone, too, which is not on the OCAD network
[14:48:54 CST(-0600)] <colinclark> Could it be a Chrome thing?
[14:51:22 CST(-0600)] <Bosmon> It's stopped happening now
[14:51:39 CST(-0600)] <Bosmon> avtar - did you do anything?
[14:52:03 CST(-0600)] <avtar> i'm talking to tomcat
[14:52:53 CST(-0600)] <colinclark> mreow
[14:53:08 CST(-0600)] <avtar> Bosmon: could you run this and tell me what results you get?
[14:53:12 CST(-0600)] <avtar> curl -w "\n time_namelookup: % \n time_pretransfer: % \n time_starttransfer: % \n\n time_total: % \n\n" -o /dev/null -s http://issues.fluidproject.org/browse/FLUID-4911
[14:53:46 CST(-0600)] <Bosmon> I will do that, although I will have to warn you that I'll be doing it on Windows
[14:53:52 CST(-0600)] <colinclark> You didn't ask me, but I love testing things. I got 0.177 for total time.
[14:54:06 CST(-0600)] <Bosmon> 0.658
[14:55:07 CST(-0600)] <Bosmon> got 1.777 2nd time
[14:55:17 CST(-0600)] <Bosmon> Bulk of which is in time_starttransfer: 1.550
[14:55:29 CST(-0600)] <Bosmon> Getting worse and worse
[14:55:37 CST(-0600)] <Bosmon> time_starttransfer: 3.726
[15:07:20 CST(-0600)] <colinclark> Seems to be valid for any assignment
[15:07:29 CST(-0600)] <yzen> colinclark: i think your example is what i was talking about, and it seems to be working in case of truthy check on assignement
[15:07:36 CST(-0600)] <colinclark> http://pastie.org/5995603
[15:08:05 CST(-0600)] <colinclark> It seems only to work for self-assignment
[15:08:08 CST(-0600)] <Bosmon> Oh, fascinating
[15:08:11 CST(-0600)] <Bosmon> How remarkable
[15:08:15 CST(-0600)] <Bosmon> Especially, after 7 years
[15:08:23 CST(-0600)] <colinclark> http://pastie.org/5995615
[15:08:27 CST(-0600)] <Bosmon> To discover what a remarkable subtlety COLLINISM depends upon
[15:09:38 CST(-0600)] <Bosmon> I guess the mere act of having embarked on a var x = statement causes the value to synchronously cease to become undefined - even though it as yet has no value in the slow
[15:09:40 CST(-0600)] <Bosmon> slot
[15:10:35 CST(-0600)] <Bosmon> In theory, if the ECMAScript standard were worth a damn, we would be able to verify that this is actually some specified behaviour
[15:23:47 CST(-0600)] <colinclark> So I guess we should decide, Bosmon and yzen: are we comfortable recommending var foo = foo || require("foo") or would we like the extra conceptual safety of a typeof() check instead?
[15:23:54 CST(-0600)] <colinclark> at the cost of a few more characters
[15:24:02 CST(-0600)] <Bosmon> colinclark - I'm happy with the standard version
[15:24:28 CST(-0600)] <Bosmon> I'd need to see hard evidence to convince me that we should go with typeof() given the former has been manifestly working in every JS engine for the last 7 years
[15:25:55 CST(-0600)] <yzen> colinclark: i m up for what you've proposed originally
[15:26:00 CST(-0600)] <colinclark> ok
[15:26:03 CST(-0600)] <colinclark> So I'll update the JIRA
[15:27:31 CST(-0600)] <colinclark> Bosmon, yzen: Here's the latest description I've written: http://issues.fluidproject.org/browse/FLUID-4911
[15:27:38 CST(-0600)] <colinclark> Do you think it's suitable comprehensive and comprehensible?
[15:28:51 CST(-0600)] <yzen> colinclark: looks good
[15:28:57 CST(-0600)] <colinclark> I made a few more small edits
[15:29:34 CST(-0600)] <Bosmon> Perhaps it should include a summary of our recent discoveries on the nature of "self-assignment"
[15:38:47 CST(-0600)] <colinclark> yzen: For this pull request: https://github.com/fluid-project/infusion/pull/257
[15:38:59 CST(-0600)] <colinclark> One quick question: when, specifically do we create a stub window?
[15:39:12 CST(-0600)] <colinclark> And where have you observed the particular issue that this pull request fixes?
[15:48:33 CST(-0600)] <yzen> colinclark: so we need window when we are loading all of infusion framework in node. here's the line: https://github.com/fluid-project/infusion/blob/master/src/webapp/module/fluid.js#L35
[15:49:00 CST(-0600)] <colinclark> ok
[15:49:03 CST(-0600)] <yzen> so what happens is that since progressive enhancement now included into the framework when loading in node, the check always return true
[15:49:10 CST(-0600)] <colinclark> Aha!
[15:49:31 CST(-0600)] <colinclark> Could you add a comment to this JIRA, describing the actual issue you encountered? http://issues.fluidproject.org/browse/FLUID-4871
[15:49:45 CST(-0600)] <colinclark> That way I can actually know what to test for, prior to pushing your fix.
[15:50:01 CST(-0600)] <yzen> sure
[15:50:56 CST(-0600)] <colinclark> thanks
[15:51:12 CST(-0600)] <colinclark> yzen: jessm will make fun of me for saying this...
[15:51:16 CST(-0600)] <colinclark> but I was just thinking of Derrida
[15:51:32 CST(-0600)] <colinclark> where he talks about writing having this rather unusual quality, in comparison to speech
[15:51:45 CST(-0600)] <yzen> colinclark: i added the comment
[15:51:52 CST(-0600)] <colinclark> He talks about writing being able to survive "the radical absence of its author"
[15:52:45 CST(-0600)] <colinclark> Similarly, I imagine pull requests should be able to survive such radical absences of the author as vacations and pair programming sessions with michelled.
[15:53:14 CST(-0600)] <Bosmon> Yes well, the absence doesn't even need to be all that radical
[15:53:19 CST(-0600)] <Bosmon> He just needs to be gone
[15:53:30 CST(-0600)] <Bosmon> Or else, as is overwhelmingly likely, not remember what he did 2 years ago
[15:53:34 CST(-0600)] <colinclark> lol
[15:53:49 CST(-0600)] <colinclark> The latter case seems especially key, when it comes to code
[15:54:09 CST(-0600)] <Bosmon> I'm amazed reading some of these rambling postings even from 2011
[15:55:55 CST(-0600)] <colinclark> Bosmon: I guess we are more or less missing any basic testing scaffolding for our Node module
[15:56:11 CST(-0600)] <colinclark> I mean, I can do an "npm install" of Infusion into Flocking and see if it still barfs
[15:56:21 CST(-0600)] <colinclark> Or I could presumably do the same with the GPII
[15:56:50 CST(-0600)] <colinclark> Does it make sense to have a basic Node.js app that can run some of our Infusion tests or something to this effect?
[15:56:55 CST(-0600)] <colinclark> Perhaps it's even already possible?
[15:57:10 CST(-0600)] <Bosmon> colinclark - such an app would be great
[15:57:22 CST(-0600)] <colinclark> So what would we want it to do?
[15:57:28 CST(-0600)] <colinclark> Justin_o: You might have some thoughts on this, too
[15:57:37 CST(-0600)] <Bosmon> We would want it to VERIFY THAT THE SYSTEM IS WORKING : P
[15:57:42 CST(-0600)] <colinclark> indeed :
[15:57:43 CST(-0600)] <colinclark>
[15:57:52 CST(-0600)] <colinclark> Is it relatively trivial to run, say, the core Infusion tests in Node.js at this point?
[15:57:52 CST(-0600)] <Bosmon> Basically something like KASPARD's integration tests, only more of them
[15:57:53 CST(-0600)] <Bosmon> And working
[15:58:09 CST(-0600)] <Bosmon> colinclark - it is not trivial
[15:58:14 CST(-0600)] <colinclark> shoot
[15:58:14 CST(-0600)] <Bosmon> Since they are written in "browser style"
[15:58:19 CST(-0600)] <colinclark> ah
[15:58:33 CST(-0600)] <colinclark> What, specifically, delimits the "browser style?"
[16:06:11 CST(-0600)] <Bosmon> colinclark - see fluid-tech
[16:06:26 CST(-0600)] <Bosmon> Well o
[16:06:27 CST(-0600)] <Bosmon> k
[16:06:31 CST(-0600)] <Bosmon> There's more to it than that
[16:06:51 CST(-0600)] <Bosmon> Actually maybe there isn't
[16:07:15 CST(-0600)] <Bosmon> There may be nothing more than that issue that prevents us reasonably straighforwardly running our "browser-based" Infusion tests in node
[16:13:50 CST(-0600)] <avtar> Bosmon: i'm going to enable profiling on this jira instance to troubleshoot this further
[16:14:14 CST(-0600)] <avtar> which means it'll have to be restarted once we're done
[16:14:39 CST(-0600)] <Bosmon> avtar - thanks, cool
[16:21:39 CST(-0600)] <avtar> Bosmon: could you try that url again?
[16:21:42 CST(-0600)] <avtar> or any
[17:18:36 CST(-0600)] <thealphanerd> Bosmon: did you see twitter "flight"
[17:19:50 CST(-0600)] <Bosmon> I didn't
[17:20:01 CST(-0600)] <thealphanerd> http://twitter.github.com/flight/
[17:20:04 CST(-0600)] <thealphanerd> sounds like infusion
[17:20:10 CST(-0600)] <thealphanerd> "Flight is a lightweight, component-based JavaScript framework that maps behavior to DOM nodes. "
[17:20:16 CST(-0600)] <Bosmon> avtar - even worse now - time_starttransfer: 6.207
[17:20:21 CST(-0600)] <thealphanerd> "Flight is distinct from existing frameworks in that it doesn't prescribe or provide any particular approach to rendering or providing data to a web application. It's agnostic to how requests are routed"
[17:20:29 CST(-0600)] <Bosmon> Sounds nothing like Infusion
[17:20:36 CST(-0600)] <thealphanerd> well I guess I don't know anything
[17:20:39 CST(-0600)] <thealphanerd> thanks for reminding me
[17:20:40 CST(-0600)] <Bosmon> We'd never talk about "mapping behaviour to DOM nodes" : P
[17:20:40 CST(-0600)] <thealphanerd>
[17:20:56 CST(-0600)] <thealphanerd> I was thinking more about it being component based
[17:21:05 CST(-0600)] <Bosmon> EVERY bloody framework is "component based" : P
[17:21:09 CST(-0600)] <Bosmon> it's like "breathing air"
[17:21:10 CST(-0600)] <thealphanerd>
[17:21:34 CST(-0600)] <thealphanerd> well then
[17:21:42 CST(-0600)] * thealphanerd tucks tail between legs
[17:21:51 CST(-0600)] <thealphanerd> I guess I didn't learn anything this past summer
[17:22:24 CST(-0600)] <Bosmon> Well, it certainly is pretty hard to successfully describe how our approach is different
[17:22:53 CST(-0600)] <Bosmon> But a dead giveway is when you look at their classic, nested-callback ugliness
[17:23:18 CST(-0600)] <Bosmon> https://github.com/twitter/flight/blob/master/README.md
[17:23:26 CST(-0600)] <Bosmon> Their approach isn't declarative in the slightest way
[17:23:43 CST(-0600)] <Bosmon> I mean, look at this:
[17:23:45 CST(-0600)] <Bosmon> this.selectMenuItem = function(e) {
[17:23:45 CST(-0600)] <Bosmon> this.select('menuItemSelector').toggleClass(this.attr.selectedClass);
[17:23:45 CST(-0600)] <Bosmon> this.trigger('uiLoadUrl', {
[17:23:45 CST(-0600)] <Bosmon> url: $(e.target).attr('href');
[17:23:45 CST(-0600)] <Bosmon> });
[17:23:48 CST(-0600)] <Bosmon> What could possibly be worse
[17:23:54 CST(-0600)] <Bosmon> Or, less like Infusion.....
[17:24:52 CST(-0600)] <thealphanerd> lol
[17:24:57 CST(-0600)] <thealphanerd> I didn't dig through the code
[17:25:15 CST(-0600)] <Bosmon> The only framework out there that is remotely like Infusion is "wire.js"
[17:25:46 CST(-0600)] <Bosmon> https://github.com/cujojs/wire
[17:25:55 CST(-0600)] <Bosmon> They're the only guys I saw at jsconf who had even heard of IoC
[17:27:05 CST(-0600)] <Bosmon> avtar - even worse recently - time_starttransfer: 6.207
[17:27:59 CST(-0600)] <avtar> Bosmon: this is bizarre
[17:28:00 CST(-0600)] <avtar> time_starttransfer: 0.080
[17:28:08 CST(-0600)] <thealphanerd> have to run to class
[17:28:11 CST(-0600)] <thealphanerd> signal processing time
[17:28:28 CST(-0600)] <Bosmon> And they also have some enlightened functional ideas
[17:28:29 CST(-0600)] <Bosmon> https://github.com/cujojs/wire/issues/69
[17:28:32 CST(-0600)] <Bosmon> Look at this recent improvement
[17:29:17 CST(-0600)] <thealphanerd> neat
[17:29:22 CST(-0600)] <thealphanerd> so you have fall back functionality
[17:29:46 CST(-0600)] <Bosmon> They have "promise-aware AOP"
[17:29:47 CST(-0600)] <thealphanerd> so you can have f1 be a injected function only able to run once and f2 as a fallback?
[17:29:49 CST(-0600)] <Bosmon> Which we haven't implemented yet : P
[17:29:55 CST(-0600)] <Bosmon> https://github.com/cujojs/wire/blob/master/docs/connections.md#promise-aware-aop
[17:30:12 CST(-0600)] <thealphanerd> Crockford was talking about promises recently
[17:30:15 CST(-0600)] <thealphanerd> in his monad talk
[17:51:34 CST(-0600)] <avtar> Bosmon: are you experiencing performance issues with any other sites?
[17:51:42 CST(-0600)] <Bosmon> Not that I see
[17:52:03 CST(-0600)] <Bosmon> JIRA has got better again recently
[17:52:10 CST(-0600)] <avtar> http://tools.pingdom.com/fpt/#!/vvNBsxW1J/http://issues.fluidproject.org/browse/FLUID-4871
[17:52:39 CST(-0600)] <Bosmon> ok
[17:52:44 CST(-0600)] <Bosmon> I'll have to accept that
[17:52:47 CST(-0600)] <avtar> well
[17:52:49 CST(-0600)] <avtar> no
[17:53:08 CST(-0600)] <avtar> we should still figure this out
[17:53:26 CST(-0600)] <Bosmon> If it's working well from SOMEWHERE outside OCAD, it's clearly not in your ballpark
[17:53:43 CST(-0600)] <Bosmon> It's good for me right now too
[17:53:50 CST(-0600)] <Bosmon> So I'll load up that ping page the next time it goes bad
[17:54:01 CST(-0600)] <Bosmon> Right now I have time_starttransfer: 0.224
[17:54:24 CST(-0600)] <avtar> ok
[17:54:44 CST(-0600)] <avtar> gonna grab dinner but email me
[17:54:47 CST(-0600)] <avtar> or i'll check the channel logs
[17:54:50 CST(-0600)] <Bosmon> Thanks!
[18:29:33 CST(-0600)] <Bosmon> Hey, ALPHER NERDD!
[18:29:38 CST(-0600)] <Bosmon> How was SigProc!
[18:33:26 CST(-0600)] <thealphanerd> I'm in it right now
[18:33:30 CST(-0600)] <thealphanerd> Julius is demo'ing faust
[18:34:00 CST(-0600)] <thealphanerd> showing us some block diagrams of a reverb + flanger
[18:34:09 CST(-0600)] <thealphanerd> now we are talking about feedforward comb filters
[18:34:39 CST(-0600)] <thealphanerd> https://ccrma.stanford.edu/~jos/Delay/Feedforward_Comb_Filter.html
[18:34:42 CST(-0600)] <Bosmon> great
[18:36:35 CST(-0600)] <thealphanerd> indeed
[18:36:49 CST(-0600)] <thealphanerd> so much knowledge to squeeze in my brain
[18:56:21 CST(-0600)] <Bosmon> I find it makes things a lot better to concentrate on a smaller number of fundamentals.... otherwise you get snowed down by a blizzard of instances : P
[18:57:00 CST(-0600)] <Bosmon> In this case, you should make sure you are really completely clear about a) linear algebra and the theory of linear differential operators, b) complex variable theory
[19:02:41 CST(-0600)] <thealphanerd> nope nope and nope
[19:02:42 CST(-0600)] <thealphanerd>
[19:02:52 CST(-0600)] <thealphanerd> feel free to mentor me though
[19:02:56 CST(-0600)] <thealphanerd> I'm open to suggestions
[19:29:17 CST(-0600)] <Bosmon> Sure
[19:29:40 CST(-0600)] <Bosmon> I guess it's hard to find REALLY GOOD source materials
[19:29:51 CST(-0600)] <Bosmon> Although back in the day I was really fond of what came to be known as THE BOOK OF ALL KNOWLEDGE
[19:30:24 CST(-0600)] <Bosmon> Well, I was going to say, this thing is so ancient now that it seems unlikely you'd buy a copy
[19:30:35 CST(-0600)] <Bosmon> but it actually seems that it is SO ancient it is now in the public domain
[19:30:40 CST(-0600)] <Bosmon> http://archive.org/details/AnIntroductionToLinearAnalysis
[19:31:10 CST(-0600)] <Bosmon> This book actually contains a substantial proportion of a full undergraduate course on maths, in a relatively clear and organised presentation
[19:32:07 CST(-0600)] <Bosmon> You'll discover the basics of all of the topics that you're touching on in your courses, including ODEs and the Laplace transform, etc.
[19:32:46 CST(-0600)] <Bosmon> Towards the end it veers a lot more into the "physics" side of the theory which you can skip
[19:33:07 CST(-0600)] <Bosmon> But this is really the basics of "everything an engineer should need to know about mathematics" as well as a few other things
[19:33:39 CST(-0600)] <Bosmon> Unfortunately for complex variable you'll need to go somewhere else
[19:40:02 CST(-0600)] <Bosmon> This guide doesn't seem bad
[19:40:03 CST(-0600)] <Bosmon> http://www.math.wustl.edu/~sk/books/guide.pdf
[19:40:32 CST(-0600)] <Bosmon> Takes pretty much the expected path through