fluid-work IRC Logs-2013-03-21

[10:57:43 CDT(-0500)] <colinclark> Justin_o, jessm: https://github.com/HenrikJoreteg/SimpleWebRTC

[10:59:51 CDT(-0500)] <colinclark> Justin_o: https://hacks.mozilla.org/2013/03/making-webrtc-simple-with-conversat-io/

[11:01:56 CDT(-0500)] <colinclark> Did the room die?

[11:09:55 CDT(-0500)] <colinclark> Justin_o: Here's the server to go with it: https://github.com/andyet/signalmaster

[11:10:20 CDT(-0500)] <Justin_o> colinclark: cool.. so we have all the pieces then

[11:10:33 CDT(-0500)] <colinclark> I think so, at least to do some prototyping/GSoC work

[12:52:52 CDT(-0500)] <colinclark> Justin_o: Our friends from uPortal stumbled across an issue I encountered years ago and sadly never filed a JIRA about

[12:53:10 CDT(-0500)] <colinclark> Prototype.js causes the Infusion event system to break because it is "extending" the Array prototype

[12:53:12 CDT(-0500)] <Justin_o> colinclark:

[12:53:26 CDT(-0500)] <colinclark> And we are using a rather loose for…in statement when iterating over an array

[12:53:47 CDT(-0500)] <colinclark> causing it to treat Prototypes unnecessary .each method as if it were an event listener

[12:53:54 CDT(-0500)] <Justin_o> colinclark: right.. we do use has own property

[12:54:07 CDT(-0500)] <Justin_o> sorry.. don't use

[12:54:09 CDT(-0500)] <colinclark> We don't in this case, yes

[12:54:24 CDT(-0500)] <colinclark> I remember reporting this issue personally to Bosmon back when I wrote a webOS app years ago

[12:54:37 CDT(-0500)] <colinclark> webOS shipped with Prototype.js linked to every application back in the day

[12:54:58 CDT(-0500)] <colinclark> We probably shouldn't be for…in'ing over Arrays in the first place

[12:55:06 CDT(-0500)] <Justin_o> colinclark: okay

[12:55:13 CDT(-0500)] <Justin_o> was there a performance gain in doing it though

[12:55:16 CDT(-0500)] <colinclark> I don't know

[12:55:28 CDT(-0500)] <colinclark> it's likely on Bosmon would remember the intention behind this odd idiom

[12:55:36 CDT(-0500)] <colinclark> I'm surprised it doesn't get flagged by JSHint

[12:55:48 CDT(-0500)] <Justin_o> colinclark: i wonder if we don't check it

[12:55:56 CDT(-0500)] <colinclark> This is exactly behaviour like this that makes, in my mind, Prototype.js unsuitable for use in a portal

[12:56:37 CDT(-0500)] <Justin_o> colinclark: yes.. since it starts stomping on other people

[12:56:53 CDT(-0500)] <colinclark> Justin_o: Typically, there's never a need to use hasOwnProperty() when iterating over keys in an object

[12:57:08 CDT(-0500)] <colinclark> Because no objects in Infusion are prototypal

[12:57:35 CDT(-0500)] <colinclark> meaning there's no way to accidentally encounter something that isn't "yours"

[12:57:45 CDT(-0500)] <colinclark> the problem occurs only when two things happen:

[12:57:51 CDT(-0500)] <Justin_o> colinclark: yes.. so are we saying.. and this might be reasonable… that infusion isn't guaranteed to work with languages that mess around with the prototypes of base objects

[12:57:56 CDT(-0500)] <colinclark> 1. Someone extends a built-in type

[12:58:21 CDT(-0500)] <colinclark> 2. Someone iterates through one of these built-in types making an assumption about what kinds of keys might be in it

[12:58:33 CDT(-0500)] <colinclark> yeah, I guess I'd say the reverse is equally true

[12:58:58 CDT(-0500)] <colinclark> Prototype does not guarantee that it is compatible with other JavaScript libraries due to the fact that it extension of built-in types.

[12:59:04 CDT(-0500)] <colinclark> Both appear to be true in this particular case

[12:59:12 CDT(-0500)] <colinclark> I'd rather only the second case be true…

[12:59:21 CDT(-0500)] <colinclark> I'll file a JIRA

[12:59:22 CDT(-0500)] <Justin_o> colinclark: right

[12:59:25 CDT(-0500)] <Justin_o> okay..

[12:59:32 CDT(-0500)] <colinclark> and then we'll see if we can patch it

[13:10:12 CDT(-0500)] <colinclark> Justin_o: I think this was fixed in a refactoring of the framework at some point, which is good news

[13:10:31 CDT(-0500)] <colinclark> It will be difficult, however, to tell uPortal to upgrade to a prerelease version of Infusion

[13:10:32 CDT(-0500)] <Justin_o> colinclark: oh that's good

[13:10:38 CDT(-0500)] <Justin_o>

[13:10:38 CDT(-0500)] <colinclark> so we may have to just provide a patch that they can apply

[13:11:01 CDT(-0500)] <colinclark> I guess the best way to handle something like this in Git is to make a special branch that people can use?

[13:11:02 CDT(-0500)] <Justin_o> colinclark: which version are they using?

[13:11:05 CDT(-0500)] <colinclark> 1.4

[13:11:44 CDT(-0500)] <Justin_o> colinclark: the tag is there

[13:12:03 CDT(-0500)] <Justin_o> i don't know if we'd need an actual branch

[13:12:42 CDT(-0500)] <colinclark> Where would we put the fix?

[13:16:00 CDT(-0500)] <Justin_o> colinclark: we would work from the 1.4 tag and create a new tag that is 1.4.1 i guess.

[13:16:19 CDT(-0500)] <colinclark> you can commit to tags in git?

[13:20:00 CDT(-0500)] <colinclark> It makes me sad whenever I have to install Ant and Maven on a machine

[13:20:04 CDT(-0500)] <colinclark> can't wait for Grunt-based build scripts

[13:20:29 CDT(-0500)] <Justin_o> colinclark: +1 to new build scripts

[13:20:53 CDT(-0500)] <Justin_o> colinclark: I think a tag is just an alias for a particular commit

[13:21:15 CDT(-0500)] <Justin_o> so you could go to that commit and make another commit off of it.. i think.. i should probably try this.. but i think it should be possible

[14:58:30 CDT(-0500)] <alexn1> Bosmon: ayt? I have a bit of a difficulty trying to fix the following jira http://issues.fluidproject.org/browse/FLUID-4940. I thought that you could help me with it or at least give me some hints where to look at. Because I'm not quiet sure why Infusion does not have an access to jQuery in this particular case.

[14:59:10 CDT(-0500)] <colinclark> Hey michelled, do you understand Justin_o's comments to me earlier about tags and branches?

[14:59:36 CDT(-0500)] <colinclark> I'm thinking that the best solution to http://issues.fluidproject.org/browse/FLUID-4941 is to create a 1.4.x branch from the 1.4 tag and fix it there

[14:59:54 CDT(-0500)] <colinclark> I think it's unlikely that we'll be able to put out a formally-tested release, but it will be available for users if they want

[15:00:04 CDT(-0500)] <colinclark> alexn1: As far as I know, Bosmon is away today

[15:00:10 CDT(-0500)] <michelled> I was just reading it colinclark. I think he's suggesting that you work on the actual 1.4 branch that already exists

[15:00:14 CDT(-0500)] <colinclark> I had a quick look at your JIRA but I don't fully understand it

[15:00:18 CDT(-0500)] <michelled> and make another tag with your fix

[15:00:36 CDT(-0500)] <colinclark> michelled: There is a 1.4 tag, but no 1.4 branch

[15:00:45 CDT(-0500)] <alexn1> colinclark: what part of it is confusing? so that I can expand on it in the JIRA

[15:00:46 CDT(-0500)] <colinclark> I'm figuring I am missing some detail about how tags work in Git

[15:01:54 CDT(-0500)] <alexn1> colinclark: let me try to improve JIRA's description.

[15:02:02 CDT(-0500)] <colinclark> It's hard to say, exactly

[15:02:09 CDT(-0500)] <colinclark> Maybe I can just reiterate what I understand

[15:02:14 CDT(-0500)] <colinclark> and you can point out anything I'm missing

[15:02:30 CDT(-0500)] <colinclark> So, first of all, you've got a custom build of Infusion which specifically omits jQuery

[15:02:33 CDT(-0500)] <colinclark> is that correct?

[15:02:37 CDT(-0500)] <alexn1> yes

[15:02:49 CDT(-0500)] <colinclark> So OER Commons supplies jQuery on its own, is that correct?

[15:02:56 CDT(-0500)] <alexn1> yes it does

[15:03:07 CDT(-0500)] <alexn1> I tried to replicate the same in my test branch I created

[15:03:20 CDT(-0500)] <alexn1> where jQuery is provided outside of Infusion.js

[15:03:33 CDT(-0500)] <alexn1> just through the script tag pointing to the right file

[15:03:44 CDT(-0500)] <colinclark> And so you're saying that the UI Options iFrame HTML pages fails, due to the lack of jQuery, is that right?

[15:04:14 CDT(-0500)] <alexn1> that is exactly what is happening. jQuery would not be resolved jQuery

[15:04:21 CDT(-0500)] <alexn1> it is not there in the iframe

[15:04:31 CDT(-0500)] <colinclark> Is this the page, specifically, that you're having problems with? https://github.com/fluid-project/infusion/blob/master/src/webapp/components/uiOptions/html/FatPanelUIOptionsFrame.html

[15:05:28 CDT(-0500)] <alexn1> actually I'm having problems with the following one https://github.com/fluid-project/infusion/blob/master/src/webapp/demos/uiOptions/html/uiOptions.html

[15:05:47 CDT(-0500)] <colinclark> the demo page, ok

[15:05:50 CDT(-0500)] <alexn1> but with the custom build all includes will look like the following ones

[15:05:56 CDT(-0500)] <alexn1> <script type="text/javascript" src="../../../../../src/webapp/lib/jquery/core/js/jquery.js"></script>

[15:05:56 CDT(-0500)] <alexn1> <script type="text/javascript" src="../../../MyInfusion.js"></script>

[15:06:03 CDT(-0500)] <colinclark> Right

[15:06:12 CDT(-0500)] <alexn1> they will be generated by ant

[15:06:30 CDT(-0500)] <colinclark> What's "they," exactly?

[15:06:31 CDT(-0500)] <alexn1> I mean. they are generated by ant when I ran a build script

[15:06:38 CDT(-0500)] <alexn1> the lines ^

[15:06:43 CDT(-0500)] <alexn1> 2 includes

[15:06:47 CDT(-0500)] <alexn1> one for MyInfusion.js

[15:06:48 CDT(-0500)] <michelled> colinclark: I don't know much about git tags, but I think your plan makes sense. the KING might know something we don't though

[15:06:59 CDT(-0500)] <alexn1> and another for jquery.js

[15:07:11 CDT(-0500)] <colinclark> Those lines in the HTML file are generated by the build script, you're saying, alexn1? Interesting. I had forgotten that we were doing any dynamic head modification.

[15:07:30 CDT(-0500)] <colinclark> Whenever Justin_o has a free second, perhaps he can clarify. I think he's on a call right now.

[15:07:35 CDT(-0500)] <colinclark> (to me, I mean)

[15:07:36 CDT(-0500)] <alexn1> colinclark: yes they were. I was pretty excited when Justin_o pointed out this feature to me

[15:07:42 CDT(-0500)] <colinclark> alexn1: I can help you with your issue, I hope

[15:08:12 CDT(-0500)] <alexn1> colinclark: thanks. I was trying to understand on what is happening but so far no luck and no good searches in google

[15:08:29 CDT(-0500)] <colinclark> Okay-just so I'm 100% clear-you're saying that the UI Options demo page actually has its head material rewritten by the build script?

[15:08:41 CDT(-0500)] <alexn1> colinclark: yes

[15:08:44 CDT(-0500)] <colinclark> wow

[15:08:47 CDT(-0500)] <colinclark> Okay.

[15:08:51 CDT(-0500)] <colinclark> So next question...

[15:08:55 CDT(-0500)] <colinclark> What does this have to do with OER Commons?

[15:09:17 CDT(-0500)] <colinclark> (It's nice to be working on some Infusion work today)

[15:10:43 CDT(-0500)] <alexn1> colinclark: well I was looking into OERC problem and then tried to replicate the same issue in the demo (as Justin_o suggested) and when I tried to replicate the same setup (which is Infusion without jQuery included into it, and jQuery included through a script tag) I ran into the same problem at the same line in the Infusion.js

[15:12:37 CDT(-0500)] <alexn1> basically I tried to create smaller test case to see if this scenario would work but it failed

[15:13:15 CDT(-0500)] <alexn1> now I'm trying to understand why it failed because jQuery is resolved properly and only in this load() function jQuery is not resolved

[15:13:35 CDT(-0500)] <colinclark> Which load() function?

[15:13:53 CDT(-0500)] <alexn1> Justin_o has mentioned jQuery self-cleaning capabilities when it would remove itself from the code base but I did not had a chance to research that

[15:15:15 CDT(-0500)] <colinclark> You're going too fast for me, alexn1

[15:15:23 CDT(-0500)] <alexn1> colinclark: trying to find the code block in github

[15:15:28 CDT(-0500)] <colinclark> I'm not the sharpest knife in our developer drawer

[15:15:39 CDT(-0500)] <colinclark> I need you to go nice and slow

[15:15:48 CDT(-0500)] <colinclark> Thanks, links always help

[15:16:28 CDT(-0500)] <alexn1> colinclark: sorry I will try to move slowly. Let me first find an exact code block where the error happens

[15:17:12 CDT(-0500)] <colinclark> sure, no problem

[15:17:18 CDT(-0500)] <cindyli> hi, Bosmon

[15:17:34 CDT(-0500)] <alexn1> colinclark: wow MyInfusion.js file is so long that github refuses to show it to me or to reference specific line numbers

[15:19:56 CDT(-0500)] <alexn1> colinclark: sorry but the best I can get is https://raw.github.com/anvk/infusion/FLUID-4940-bug/build/assembled/MyInfusion.js and then if you search for "that.renderUIOContainer = that.jQuery(" in it

[15:21:09 CDT(-0500)] <alexn1> it is an exact line where the error happens because iframeWindow.jQuery is undefined line above

[15:22:16 CDT(-0500)] <alexn1> this is load() function of the UIOptions fatPanel iframe

[15:23:14 CDT(-0500)] <colinclark> So is a valid version of jQuery being linked into the fatPanel iFrame?

[15:24:33 CDT(-0500)] <alexn1> well uiOptions.html has an include for jQuery 1.7.2 which is also used for Infusion 1.5

[15:25:32 CDT(-0500)] <alexn1> jQuery is not present in iframeWindow at all

[15:25:35 CDT(-0500)] <Justin_o> colinclark: here's an example of what i mean https://github.com/jobara/infusion/tree/infusion-1.4.1

[15:31:21 CDT(-0500)] <colinclark> alexn1: I guess what I'm asking is, does the fatPanel iFrame attempt to import a version of jQuery?

[15:31:33 CDT(-0500)] <colinclark> and if it does, does it reference a valid path?

[15:31:45 CDT(-0500)] <colinclark> i.e. Is jQuery actually where the iFrame page thinks it is?

[15:32:00 CDT(-0500)] <alexn1> colinclark: I'm not sure. where would I check that ?

[15:32:14 CDT(-0500)] <colinclark> In Firebug or the Chrome debugging console?

[15:32:18 CDT(-0500)] <colinclark> That's where I'd start

[15:32:23 CDT(-0500)] <colinclark> The network panel should show you

[15:32:38 CDT(-0500)] <colinclark> you may have to View Only This Frame or whatever

[15:32:44 CDT(-0500)] <colinclark> Justin_o: How does this magic work?

[15:32:51 CDT(-0500)] <colinclark> And why is it advantageous magic?

[15:34:00 CDT(-0500)] <alexn1> colinclark: let me double check on that

[15:34:33 CDT(-0500)] <colinclark> cool, alexn1

[15:35:11 CDT(-0500)] <Justin_o> colinclark: lets start with the disclaimer that I don't' know everything about git and could be making some errors in my assumptions..

[15:35:34 CDT(-0500)] <colinclark> You are one of my go-to Git experts, so you needn't disclaim

[15:37:24 CDT(-0500)] <Justin_o> colinclark: so this is what I believe to be happening.. tags are global to the repo.. so they can refer to a commit in any branch

[15:37:40 CDT(-0500)] <colinclark> Even branches which no longer exist?

[15:37:55 CDT(-0500)] <Justin_o> what i did was to create a new temporary branch did my work, raged, pushed the tag.

[15:38:00 CDT(-0500)] <Justin_o> then deleted the temp branch

[15:38:15 CDT(-0500)] <Justin_o> colinclark: i believe it won't get pruned because it is still refrenced

[15:38:18 CDT(-0500)] <Justin_o> by the tag

[15:38:52 CDT(-0500)] <colinclark> Ok, that sort of makes sense

[15:38:59 CDT(-0500)] <colinclark> and answers my first question--the mechanism of your magic

[15:39:08 CDT(-0500)] <colinclark> the second question is, "why is this magic advantageous?"

[15:39:42 CDT(-0500)] <alexn1> colinclark: you were totally right. The iframe was pointing to the wrong jQuery. thanks I can close the ticket and double check on OERC if it is the same problem there.

[15:40:22 CDT(-0500)] <colinclark> Sure. Maybe update your JIRA with a few details when you close it, in case others encounter this issue.

[15:40:55 CDT(-0500)] <alexn1> colinclark: already closed but I will put more description into it about this

[15:41:38 CDT(-0500)] <Justin_o> colinclark: i think tags better denote "release" points as opposed to active work

[15:42:18 CDT(-0500)] <Justin_o> colinclark: also we won't all have to carry around the extra branch.. you can imagine in time if we do this a lot, there could be many potential branches..

[15:42:59 CDT(-0500)] <colinclark> I was surveying other projects to see what they do

[15:43:16 CDT(-0500)] <colinclark> uPortal seems to typically carry around a number of release branches:https://github.com/jasig/uPortal

[15:43:33 CDT(-0500)] <colinclark> jQuery appears to do the same, though to a lesser extent: https://github.com/jquery/jquery

[15:43:59 CDT(-0500)] <colinclark> Backbone does not, and only consists of a master branch: https://github.com/documentcloud/backbone

[15:44:31 CDT(-0500)] <colinclark> Looks like Twitter Bootstrap is fairly minimal in their branch usage, but they do have a few: https://github.com/twitter/bootstrap

[15:45:12 CDT(-0500)] <Justin_o> i suppose there is some legacy from svn that gets carried around..

[15:45:22 CDT(-0500)] <colinclark> Ember.js seems to use release branches similarly, along with a lot of other branches that seem typical of single-developer projects: https://github.com/emberjs/ember.js

[15:45:46 CDT(-0500)] <colinclark> That's a good cross-section of hipster JS projects, most of which probably didn't start out in SVN

[15:46:08 CDT(-0500)] * michelled is impressed that the KING raged

[15:46:33 CDT(-0500)] <Justin_o> http://stackoverflow.com/questions/9810050/git-tag-vs-release-beta-branches

[15:48:41 CDT(-0500)] <colinclark> Raging King

[15:50:17 CDT(-0500)] <Justin_o> i don't mean to rage.. i just feel that in git tags make more sense to mark "release" points.. and that branches are better work in progress

[15:51:20 CDT(-0500)] <colinclark> Justin_o: I don't think you were raging. michelled was teasing you about a typo

[15:51:34 CDT(-0500)] <michelled> likely autocorrect

[15:51:39 CDT(-0500)] <colinclark> right

[15:51:39 CDT(-0500)] <Justin_o> colinclark, michelled : did you still need to look at that test tag in my repo.. i want to delete it so i don't get confused later

[15:51:48 CDT(-0500)] <colinclark> you can delete it

[15:52:03 CDT(-0500)] <colinclark> michelled: Am I skimming the nvie post correctly in thinking that they are advocating the use of "release" and "hot fix" branches?

[15:53:01 CDT(-0500)] <Justin_o> colinclark, michelled: that typo is hilarious i hadn't caught it

[15:53:39 CDT(-0500)] <alexn1> colinclark: thx for help!! now after I fix jquery include in iframe I get a totally different error in OERC, which is a good step forward

[15:53:49 CDT(-0500)] <colinclark> Glad to hear it, alexn1

[15:54:15 CDT(-0500)] <colinclark> When I'm getting weird errors like that, I often check in the Net panel just to double-check that everything I expect is getting loaded properly.

[15:54:33 CDT(-0500)] <Justin_o> colinclark: they might be, but they also have development and master as separate branches so the work flow is a bit different.. but i just skimmed through it myself

[15:56:37 CDT(-0500)] <Justin_o> colinclark, michelled: i have to run now.. good chatting with you about this stuff.. i find it pretty interesting..

[15:56:43 CDT(-0500)] <colinclark> yup, me too

[15:56:59 CDT(-0500)] <colinclark> I want to get a fix out to uP, but I guess the first step is to make the fix and push it up to a branch in my own fork, first