fluid-work IRC Logs-2011-07-21

Owned by Fluid IRC Log Bot
Last updated: Jul 21, 2011Version comment
32 min read

[07:57:29 CDT(-0500)] <lahabana> Bosmon: Hi are you here? I'd need a little help with the renderer
[08:09:54 CDT(-0500)] <colinclark> Morning, Justin_o
[08:10:38 CDT(-0500)] <Justin_o> colinclark: hello
[08:10:47 CDT(-0500)] <colinclark> So I made some progress last night
[08:10:56 CDT(-0500)] <colinclark> My FLUID-4219 branch should have all the latest
[08:11:13 CDT(-0500)] <colinclark> the upgrade to the new Rhino had caused the other JavaScript-portions of the build to break
[08:11:26 CDT(-0500)] <colinclark> wow, extra dashes
[08:11:31 CDT(-0500)] <colinclark> anyway, it was an easy fix
[08:11:44 CDT(-0500)] <colinclark> but I'm encountering a more interesting and problematic issue
[08:12:10 CDT(-0500)] <colinclark> It looks like we're only rewriting some of the theme selectors
[08:12:20 CDT(-0500)] <colinclark> So, if we have .fl-theme-rust
[08:12:53 CDT(-0500)] <colinclark> We are successfully rewriting it to .fl-theme-uio-rust in all cases except when we've got an element selector
[08:13:06 CDT(-0500)] <colinclark> so .fl-theme-rust .cat will be rewritten
[08:13:17 CDT(-0500)] <colinclark> ".fl-theme-rust a" will not
[08:13:25 CDT(-0500)] <colinclark> I'll write a unit test for this case
[08:13:33 CDT(-0500)] <colinclark> and see if I can figure out what's going on
[08:13:42 CDT(-0500)] <colinclark> but it looks like maybe our parser doesn't like it much
[08:14:03 CDT(-0500)] <colinclark> I guess, worst case, we've got a brute force technique
[08:14:17 CDT(-0500)] <colinclark> we can just take the stylesheet as a giant string and .replace() it
[08:14:21 CDT(-0500)] <colinclark> but it's not idael
[08:19:31 CDT(-0500)] <Justin_o> oh.. yah.. that's too bad..
[08:19:39 CDT(-0500)] <Justin_o> so i guess it's a bug with the parser for sure..
[08:19:49 CDT(-0500)] <Justin_o> any chance that the parser has been updated since you pulled it down
[08:20:10 CDT(-0500)] <mlam> hey colinclark , Justin_o : looks like FLUID-4219 is still on the go?
[08:20:26 CDT(-0500)] <colinclark> Nearly finished, but we're still going, mlam
[08:20:36 CDT(-0500)] <mlam> so it was an issue with the CSSParser itself?
[08:20:57 CDT(-0500)] <colinclark> welcome back
[08:21:26 CDT(-0500)] <colinclark> mlam: This is the latest... things have changed quite a bit
[08:21:27 CDT(-0500)] <colinclark> https://github.com/colinbdclark/infusion/tree/FLUID-4219
[08:21:28 CDT(-0500)] <mlam> thanks! it's good to be back, even though it's smoking hot here
[08:21:38 CDT(-0500)] <mlam> ok, taking a look
[08:22:08 CDT(-0500)] <colinclark> Justin_o: I think it's quite likely an issue with the parser, but I won't know until I write that unit test and do some debugging
[08:22:39 CDT(-0500)] <Justin_o> colinclark: okay..
[08:22:47 CDT(-0500)] <Justin_o> colinclark: so this is the last hurdle?
[08:22:57 CDT(-0500)] <colinclark> I'm assuming so, yes
[08:25:52 CDT(-0500)] <Justin_o> colinclark: (smile) that's good
[08:26:15 CDT(-0500)] <colinclark> I did some tweaking and renaming of the bootStrapper.js
[08:26:22 CDT(-0500)] <colinclark> I made all the functions public
[08:26:27 CDT(-0500)] <colinclark> I'm not quite sure how they were working before
[08:26:37 CDT(-0500)] <colinclark> since they were all wrapped in a closure and defined simply with var
[08:26:42 CDT(-0500)] <colinclark> but you were using them in several files
[08:26:54 CDT(-0500)] <colinclark> So, at least with the latest Rhino, I was encountering errors on long()
[08:26:55 CDT(-0500)] <colinclark> log()
[08:27:22 CDT(-0500)] <colinclark> They all seemed like fairly useful functions
[08:27:29 CDT(-0500)] <colinclark> so making them public seemed reasonable
[08:27:42 CDT(-0500)] <Justin_o> colinclark: that's a good point.. i wonder how they did work
[08:27:51 CDT(-0500)] <Justin_o> i guess the scoping in the old version of rhino wasn't working
[08:29:43 CDT(-0500)] <colinclark> something was up, yes
[08:29:49 CDT(-0500)] <colinclark> Anyway, things are looking really good
[08:30:04 CDT(-0500)] <colinclark> We should probably do at least a little bit of tidy-up of the other build file
[08:30:07 CDT(-0500)] <colinclark> which I can do
[08:30:22 CDT(-0500)] <colinclark> Since we no longer need JSON2.js, for example
[08:34:24 CDT(-0500)] <Justin_o> colinclark: yes.. you can probably refactor the reading in of the json file too.. as this has been abstracted out to the bootstrapper
[08:34:33 CDT(-0500)] <colinclark> right, yes
[08:34:46 CDT(-0500)] <colinclark> also the weird globalism caused by Rhino
[08:37:26 CDT(-0500)] <lahabana> colinclark: hi can you tell me when you are available please
[08:41:22 CDT(-0500)] <colinclark> Hi lahabana I'll have some time at around noon EDT today
[08:41:54 CDT(-0500)] <colinclark> So I think that's 18:00 your time.
[08:42:49 CDT(-0500)] <lahabana> 17 I'm in England atm
[08:43:45 CDT(-0500)] <lahabana> can you give me a name of somebody who can help me with the renderer?
[08:48:41 CDT(-0500)] <colinclark> most people here can probably help with that
[08:48:50 CDT(-0500)] <colinclark> michelled, maybe is a good person to ask
[08:57:17 CDT(-0500)] <lahabana> colinclark thx
[08:57:41 CDT(-0500)] <colinclark> michelled: Do you have a few minutes to answer some of lahabana's questions about the Renderer?
[08:57:57 CDT(-0500)] <michelled> sure - ask away lahabana
[08:58:01 CDT(-0500)] <lahabana> colinclark : thx I was going to ask the same (smile)
[08:58:07 CDT(-0500)] <colinclark> (smile)
[08:58:35 CDT(-0500)] <lahabana> hi so I've read the doc and there's a few things I still don't understand
[08:59:05 CDT(-0500)] <lahabana> I'd like to do a renderer autoBinded to my data model
[08:59:23 CDT(-0500)] <lahabana> most of my model is booleans as it's buttons...
[09:00:02 CDT(-0500)] <lahabana> what I don't understand is how I'm supposed to tell my renderer it's a boolean and how he will change the data?
[09:01:28 CDT(-0500)]

<lahabana> do I have to link my protoTree to the model by doing something like playButton:

Unknown macro: {valueBinding}

?


[09:01:31 CDT(-0500)] <michelled> tell me a little more about your interface - what are the buttons? what values do they have
[09:01:45 CDT(-0500)] <lahabana> so it's a videoPlayer
[09:01:56 CDT(-0500)] <lahabana> so for example there's a play/pause button
[09:02:09 CDT(-0500)] <lahabana> a captionOn/off button
[09:02:18 CDT(-0500)] <lahabana> a scrubber
[09:02:33 CDT(-0500)] <lahabana> 2 text boxes with the total and the current Time
[09:02:40 CDT(-0500)] <lahabana> and a fullscreen switch
[09:03:36 CDT(-0500)] <lahabana> the data related to these buttons are in my model as model.states.play for eg (this being a boolean)
[09:05:55 CDT(-0500)] <michelled> I'm not sure you can use autobinding to do what you want. seems to me that there would not be a way for the framework to know what value to set seeing as a button doesn't naturally have an on/off state
[09:06:54 CDT(-0500)] <lahabana> so do you mean I have to make the renderer just render it
[09:07:02 CDT(-0500)] <lahabana> and then do the binding myself?
[09:08:53 CDT(-0500)] <michelled> yes, I think that is what you'll need to do - create an even handler for the button that alters the state in the model
[09:09:00 CDT(-0500)] <michelled> colinclark, anastasiac: am I missing something?
[09:11:35 CDT(-0500)] <lahabana> ok thx then also I was wondering if it was possible to inject css classes through the renderer
[09:11:57 CDT(-0500)] <anastasiac> michelled, lahabana, your buttons sound a bit like checkboxes (i.e. they have on/off state) so perhaps they could be bound to a model the way checkboxes would be
[09:12:17 CDT(-0500)] <lahabana> and how is that?
[09:12:47 CDT(-0500)] * anastasiac rummages though notes and examples
[09:12:50 CDT(-0500)] <michelled> lahabana: you can add classes using the addClass renderer decorator: http://wiki.fluidproject.org/display/fluid/Renderer+Decorators
[09:13:15 CDT(-0500)] <lahabana> michelled: thx (smile)
[09:14:18 CDT(-0500)] <michelled> np
[09:18:57 CDT(-0500)] <anastasiac> lahabana, to bind your UI to the data model, you don't necessarily need to "tell" the renderer the data type. If you use a checkbox (styled to look like a button), then the Renderer will automatically treat it as a boolean. You just hook the element to the model using the "valuebinding"
[09:19:49 CDT(-0500)] <lahabana> ho ok I understand better
[09:20:16 CDT(-0500)] <anastasiac> we really do need some better demos and tutorials for this stuff, I know
[09:20:32 CDT(-0500)] <lahabana> yes (wink)
[09:20:49 CDT(-0500)] <lahabana> also the implementation changed quite a lot recently no?
[09:21:36 CDT(-0500)] <michelled> I don't think the renderer has changed much - it's the introduction of IoC that's been the major change in the framework lately
[09:21:55 CDT(-0500)] <lahabana> ok
[09:22:32 CDT(-0500)] <lahabana> I was saying that cause the protoTrees look quite different on each documentation
[09:22:34 CDT(-0500)] <anastasiac> lahabana, the new renderer stuff that we don't have sufficient demos/examples for is the "proto-tree" stuff. Our demo doesn't use prototrees
[09:22:46 CDT(-0500)] <anastasiac> (smile)
[09:22:53 CDT(-0500)] <lahabana> (wink)
[09:23:54 CDT(-0500)] <michelled> lahabana: if you haven't seen it, you might find this chart interesting: http://praegnanz.de/html5video/
[09:24:35 CDT(-0500)] <lahabana> ho thx michelled
[09:24:42 CDT(-0500)] <michelled> np
[09:30:32 CDT(-0500)] <lahabana> michelled: is there something special to do to use a fluid.rendererComponent as a subComponent with IoC and autoInit?
[09:32:00 CDT(-0500)] <michelled> are you using the gradename renderercomponent?
[09:32:11 CDT(-0500)] <lahabana> yes
[09:32:18 CDT(-0500)] <lahabana> gradeNames: ["fluid.rendererComponent", "autoInit"],
[09:32:19 CDT(-0500)] <lahabana> finalInitFunction: "fluid.videoPlayer.controllers.finalInit",
[09:32:34 CDT(-0500)] <lahabana> and the error is: ASSERTION FAILED: Cannot autoInit component fluid.videoPlayer.controllers which does not have an initFunction and gradeName defined
[09:32:55 CDT(-0500)] <lahabana> and if I change it to a viewComponent there's no problem
[09:33:03 CDT(-0500)] <michelled> are you including the correct js files?
[09:33:19 CDT(-0500)] <lahabana> sorry (wink)
[09:33:51 CDT(-0500)] <lahabana> I thought I had an infusionAll but I'm including the files one by one
[09:34:16 CDT(-0500)] <michelled> you'll need renderer utilities in order to use renderercomponent
[09:34:23 CDT(-0500)] <michelled> hopefully that will get rid of the error (smile)
[09:34:37 CDT(-0500)] <lahabana> thx
[09:49:39 CDT(-0500)] <jessm> heidi_: ping
[09:49:45 CDT(-0500)] <heidi_> jessm hiya
[09:49:59 CDT(-0500)] <jessm> heidi_: is there something you've pushed to Git?
[09:50:07 CDT(-0500)] <heidi_> jessm not yet no
[09:50:27 CDT(-0500)] <jessm> ah, ok, i thought you were pushing yesterday and i just wasn't seeing
[09:51:00 CDT(-0500)] <heidi_> jessm yeah, sent some emails this morning about github organising
[09:51:12 CDT(-0500)] <jessm> heidi_: yeah, i see the thread
[09:51:23 CDT(-0500)] <heidi_> jessm once that's sorted, i'll push what i have.
[09:51:45 CDT(-0500)] <heidi_> Justin_o you around?
[09:51:55 CDT(-0500)] <Justin_o> heidi_: hello
[09:52:13 CDT(-0500)] <heidi_> hey. am i able to rename idi repos? i'm not sure how to do that
[09:52:19 CDT(-0500)] <jessm> k, i'm going to reboot in hopes of achieving greater clarity
[09:52:26 CDT(-0500)] <Justin_o> heidi_: yes.. you should be able to
[09:52:35 CDT(-0500)] <Justin_o> got to the repo and click the admin button at the top
[09:53:02 CDT(-0500)] <heidi_> Justin_o aha, perfect
[09:53:03 CDT(-0500)] <Justin_o> heidi_: although you should probably do this sparingly as it may affect people who have pulled it down
[09:53:30 CDT(-0500)] <heidi_> Justin_o right. i'm assuming no one has yet. there's nothing in it
[09:54:09 CDT(-0500)] <Justin_o> heidi_: yes.. now should be okay
[09:54:10 CDT(-0500)] <heidi_> Justin_o colinclark huslage wordpress-IDI an okay repo name for wordpress theme and config? i'm not sure why i'm finding this so confusing
[09:54:45 CDT(-0500)] <Justin_o> heidi_: if we ever switch to some other cms.. would we be able to reuse anything from that repo?
[09:54:57 CDT(-0500)] <heidi_> Justin_o no it will be wp specific
[09:56:04 CDT(-0500)] <Justin_o> heidi_: okay.. i think the name is fine for me
[09:56:29 CDT(-0500)] <heidi_> k
[09:56:51 CDT(-0500)] <heidi_> Justin_o or should it be wordpress-inclusivedesign.ca ...that specific
[09:57:24 CDT(-0500)] <heidi_> not sure what aaron is thinking for config storage... i see he just left, doh
[09:57:41 CDT(-0500)] <cindyli> Justin_o: i've pushed 4348 that removes pageEnhancer from fat panel IoC tree into my github - https://github.com/cindyli/infusion/commits/FLUID-4348. as discussed, can you try the new fat panel on ur mac?
[09:58:31 CDT(-0500)] <Justin_o> cindyli: thanks .. i'll try to test that out
[09:58:41 CDT(-0500)] <cindyli> thanks, Justin_o
[09:59:14 CDT(-0500)] <Justin_o> heidi_: hmm.. i guess that would make it more clear as to what it is
[09:59:44 CDT(-0500)] <Justin_o> heidi_: I guess what's ever easier for people i'm good with
[10:01:15 CDT(-0500)] <heidi_> Justin_o okay i'll just name it wordpress-inclusivedesign.ca and move on (smile)
[10:01:31 CDT(-0500)] <heidi_> Justin_o how to make new repos?
[10:02:34 CDT(-0500)] <Justin_o> heidi_: go to your dashboard
[10:03:01 CDT(-0500)] <Justin_o> heidi_: actually.. it might be easier to just skype this one
[10:03:12 CDT(-0500)] <heidi_> sure, i'll login
[10:03:24 CDT(-0500)] <Justin_o> heidi_: okay.. call me when you're ready
[10:05:17 CDT(-0500)] <anastasiac> cindyli, are you working on a UI Options branch in which specifying the path to the TableOfContents template is not necessary?
[10:05:29 CDT(-0500)] <colinclark> heidi_ and Justin_o: So, in the medium term, I think we'll probably have three things...
[10:06:00 CDT(-0500)] <colinclark> 1. A series of stylesheets that represent our look and feel across all applications and content management systems
[10:06:17 CDT(-0500)] <colinclark> This will include an FSS theme custom to the IDI, along with any other extensions we might need
[10:06:43 CDT(-0500)] <colinclark> So the goal here is to do as much of our look and feel in a reusable way, so we don't have to do all the styling all over again for MediaWiki, and then again for another app, etc.
[10:06:54 CDT(-0500)] <colinclark> that brings us to the second thing, then
[10:07:03 CDT(-0500)] <cindyli> anastasiac: well, i have a branch for that that works with the old ui options template loader. but with the new loader i'm working on right now, that branch is sort of useless. need a re-work
[10:07:12 CDT(-0500)] <colinclark> 2. An application-specific theme. In this case, we're talking about a WordPress theme
[10:07:27 CDT(-0500)] <colinclark> Our ideal situation is to have as little of the actual styling done within this thing
[10:07:29 CDT(-0500)] <anastasiac> ok, thanks, cindyli. I'll wait until the work is closer to finished
[10:07:42 CDT(-0500)] <cindyli> thanks, anastasiac
[10:07:50 CDT(-0500)] <colinclark> and, as I mentioned the other day, heidi_, to treat this as a kind of "reset," which we use to ensure that the CMS emits all the markup and classnames that we need
[10:08:07 CDT(-0500)] <colinclark> 3. A series of site-specific application configurations
[10:08:34 CDT(-0500)] <colinclark> So, in this case, we'll have WordPress configuration for the particular site--inclusivedesign.ca
[10:08:50 CDT(-0500)] <colinclark> As it stands today, we've got #1 and #2 mixed up, which is fine
[10:08:59 CDT(-0500)] <colinclark> but I hope we can get to a point sooner rather than later where this isn't so much the case
[10:09:02 CDT(-0500)] <Justin_o> cindyli: did you remove the hiding logic from the FLUID-4348.. i think you need to take that out too
[10:09:33 CDT(-0500)] <cindyli> Justin_o: the func makeVisible?
[10:09:41 CDT(-0500)] <cindyli> yes, that needs to go
[10:09:52 CDT(-0500)] <colinclark> The good news with Git, as Jorge pointed out, is that it's not difficult to split things off into new repositories later
[10:09:54 CDT(-0500)] <Justin_o> cindyli: yes.. and the style related stuff to hide initially
[10:09:56 CDT(-0500)] <colinclark> heidi_: is this making sense to you?
[10:10:12 CDT(-0500)] <Justin_o> cindyli: i'm wondering if it's still in, becaus my uio is missing (smile).. i'll look through the code though
[10:10:24 CDT(-0500)] <heidi_> colinclark that all sounds good... processing... and trying to picture it as concrete repos
[10:10:25 CDT(-0500)] <cindyli> ya, styling classes, i forgot that. thanks for reminding, Justin_o
[10:11:30 CDT(-0500)] <heidi_> colinclark #1 would live in fluid-project as a new IDI theme
[10:11:42 CDT(-0500)] <heidi_> er, fluid theme? no... different
[10:11:52 CDT(-0500)] <colinclark> no
[10:12:01 CDT(-0500)] <Justin_o> cindyli: np.. please let me know when you push that up
[10:12:14 CDT(-0500)] <colinclark> It would still be something specific to the IDI, but implemented as an FSS theme
[10:12:28 CDT(-0500)] <colinclark> As concrete repositories, it would look something like this
[10:12:32 CDT(-0500)] <heidi_> ok
[10:12:39 CDT(-0500)] <colinclark> #1: look-and-feel
[10:12:45 CDT(-0500)] <colinclark> #2: wordpress-fss-theme
[10:12:52 CDT(-0500)] <colinclark> #: wordpress-inclusivedesign.ca
[10:13:00 CDT(-0500)] <colinclark> #3, that is
[10:13:38 CDT(-0500)] <colinclark> It will probably take a few design iterations to get this sort of structure into place
[10:13:44 CDT(-0500)] <colinclark> but that's our goal
[10:13:57 CDT(-0500)] <colinclark> it seems to me the worst thing we could do is redo all the same work over and over again
[10:13:59 CDT(-0500)] <colinclark> in terms of styling
[10:14:01 CDT(-0500)] <colinclark> for each new app
[10:14:04 CDT(-0500)] <heidi_> thing about the wordpress idi theme is that it has specifics to content... it's not going to be a generic theme for any blog page i don't htink
[10:14:20 CDT(-0500)] <heidi_> for ex the styling of this front page http://dev.inclusivedesign.ca/wordpress/
[10:14:28 CDT(-0500)] <colinclark> Yep, I've seen all that
[10:14:29 CDT(-0500)] <heidi_> is based around... our front page content
[10:14:31 CDT(-0500)] <colinclark> That's fine
[10:14:47 CDT(-0500)] <colinclark> I'm not suggesting that we're going to rush out and share this with the WordPress community
[10:14:58 CDT(-0500)] <colinclark> But I think you'll find that this site isn't radically different from lots of other sites
[10:15:09 CDT(-0500)] <colinclark> you're going to have to squint a bit, when you start to define the semantics for the site
[10:15:28 CDT(-0500)] <heidi_> wordpress-fss-theme doesn't mention it's tie to inclusivedesign.ca , but that doesn't matter?
[10:15:32 CDT(-0500)] <colinclark> be a bit more abstract than "this is where the 'join the IDI mailing list' section goes"
[10:15:45 CDT(-0500)] <colinclark> heidi_: Names can always be changed
[10:15:54 CDT(-0500)] <colinclark> Again, think of the goal
[10:16:00 CDT(-0500)] <colinclark> Make sure #1 is a reusable as possible
[10:16:06 CDT(-0500)] <colinclark> Make sure #2 is as generic as possible
[10:16:18 CDT(-0500)] <colinclark> There will be, undoubtedly, some rough edges in practice (smile)
[10:16:33 CDT(-0500)] <heidi_> yeah... ideals and reality compromising.
[10:16:39 CDT(-0500)] <heidi_> will aim for that tho
[10:17:29 CDT(-0500)] <colinclark> I think we can do more than just aim for it
[10:17:32 CDT(-0500)] <colinclark> we can do it (smile)
[10:17:35 CDT(-0500)] <colinclark> So, we know the goal
[10:17:47 CDT(-0500)] <colinclark> then, case by case, we can evaluate how to actually implement it
[10:17:53 CDT(-0500)] <colinclark> and look at those rough edges and see if
[10:18:00 CDT(-0500)] <colinclark> a) we just can't do it
[10:18:01 CDT(-0500)] <colinclark> or more likely
[10:18:08 CDT(-0500)] <colinclark> b) we need to take a slightly different approach
[10:18:29 CDT(-0500)] <colinclark> What I expect, at very least, is that there will be big chunks of shared semantics across all our applications
[10:18:37 CDT(-0500)] <colinclark> Obvious stuff like navigation, headers, foots
[10:18:44 CDT(-0500)] <colinclark> probably call-outs and highlighted material
[10:18:45 CDT(-0500)] <colinclark> etc.
[10:18:52 CDT(-0500)] <cindyli> Justin_o: removed the offscreen part and pushed up
[10:18:59 CDT(-0500)] <colinclark> We want to define some shared semantics for these things
[10:19:03 CDT(-0500)] <colinclark> so that our stuff will be more portable
[10:19:31 CDT(-0500)] <heidi_> there are subtler things going on too... like i've added code to page.php in our theme so that if a parent page has a submenu, load the first submenu content, cos that's how we want it to work for idi
[10:19:44 CDT(-0500)] <heidi_> wondering if that kind of thing needs to be separated out in a different way... it's tricky
[10:20:05 CDT(-0500)] <Justin_o> cindyli: thanks.. i'll try again
[10:20:16 CDT(-0500)] <heidi_> also need to start thinking about how we want fluid to live in wordpress... create a plugin for it, etc
[10:20:23 CDT(-0500)] <colinclark> right
[10:20:31 CDT(-0500)] <heidi_> right now i have /fss in my themes dir
[10:20:41 CDT(-0500)] <heidi_> but we want UIO as well
[10:20:48 CDT(-0500)] <colinclark> The more stuff we can accomplish without just sticking some app-specific PHP into the theme, the better, I think
[10:20:55 CDT(-0500)] <colinclark> As I say, this'll take some iterations
[10:21:10 CDT(-0500)] <colinclark> but you'll really need to keep in the back of your head...
[10:21:17 CDT(-0500)] <colinclark> "Can I do this in a way that isn't just for WordPress?"
[10:21:39 CDT(-0500)] <colinclark> I guess, if you think about it, this is our approach to programming in general
[10:21:42 CDT(-0500)] <colinclark> Making things accessible
[10:22:16 CDT(-0500)] <colinclark> Not hard wiring it to one way of working, one presentation, one modality
[10:22:16 CDT(-0500)] <colinclark> t
[10:22:19 CDT(-0500)] <colinclark> that kind of thing
[10:22:24 CDT(-0500)] <lahabana> michelled you're still here?
[10:23:39 CDT(-0500)] <lahabana> or anastasiac?
[10:23:58 CDT(-0500)] <anastasiac> lahabana, yes, I'm here
[10:24:16 CDT(-0500)] <lahabana> I'm still having issues to get started with the renderer
[10:24:27 CDT(-0500)] <jessm> heidi_: smells like up-front costs that will yield long term happiness. while WP is the choice we've made for this site we have a whole bunch of sites that aren't WP. Loosely coupled, reusable will win the day.
[10:24:53 CDT(-0500)] <lahabana> it says ASSERTION FAILED: empty template supplied to fluid.parseTemplate
[10:25:00 CDT(-0500)] <lahabana> and I don't relly understand why
[10:25:29 CDT(-0500)] <lahabana> I tried to stick to the online example : http://wiki.fluidproject.org/display/docs/Renderer-bearing+Components
[10:25:50 CDT(-0500)] <lahabana> In mine I get: http://pastie.org/2248983
[10:25:52 CDT(-0500)] <heidi_> jessm yes for sure
[10:26:03 CDT(-0500)] <lahabana> which is pretty much the same no?
[10:26:14 CDT(-0500)] <anastasiac> hm. lahabana, it's hard to debug without looking at it - are you able to push your code to github?
[10:26:23 CDT(-0500)] <lahabana> yes
[10:26:48 CDT(-0500)] <anastasiac> ok, we have our stand-up meeting now. Let me know the URL, and I'll have a look in about 15-20 minutes, lahabana
[10:27:00 CDT(-0500)] <lahabana> ho yes ok (wink)
[10:27:20 CDT(-0500)] <lahabana> https://github.com/lahabana/videoPlayer/commit/b0accd2fdb3abc0a3c13e43cafdc2afd6b4ffa1b
[10:28:04 CDT(-0500)] <lahabana> anastasiac : it's the controller only that tries to use it
[10:34:15 CDT(-0500)] <jessm> fluid-everyone: standup?
[10:38:46 CDT(-0500)] <mlam> jessm: are you still connected to stand-up?
[10:38:54 CDT(-0500)] <jessm> mlam: yes
[10:39:01 CDT(-0500)] <mlam> ack.
[10:41:54 CDT(-0500)] <mlam> fluid-everyone: I'm having troubles getting back into connect, so i'll give my stand-up here.
[10:42:21 CDT(-0500)] <mlam> I just returned from vacation. I spent the morning catching up with emails and today, I'll help cindyli out with some unit testing
[10:50:51 CDT(-0500)] <anastasiac> hey, lahabana, I've cloned your repo and I'm trying to reproduce your error. Is the code in your master, or in a repo? And if I open VideoPlayer.html, should I see the error?
[10:51:09 CDT(-0500)] <anastasiac> "in your master, or in a branch"
[10:54:16 CDT(-0500)] <lahabana> if u do u should anastasiac
[10:54:32 CDT(-0500)] <lahabana> have u been careful that it's not in the master
[10:54:50 CDT(-0500)] <anastasiac> which branch should I be looking at, lahabana?
[10:55:09 CDT(-0500)] <lahabana> FLUID-4297
[10:56:51 CDT(-0500)] <lahabana> and my path to the fluid framework is unusual you may have to change it
[10:57:19 CDT(-0500)] <lahabana> same for line 106 of videoPlayer_controllers.js
[10:58:12 CDT(-0500)] <anastasiac> ok, lahabana, I'm seeing the error you mentioned. looking in more detail now...
[10:58:22 CDT(-0500)] <lahabana> ok anastasiac thx (smile)
[11:10:08 CDT(-0500)] <lahabana> so any clues anastasiac ? it seems really weird to me
[11:13:53 CDT(-0500)] <lahabana> anastasiac gtg doesn't matter if you can't find it I'll try when I'll get back
[11:14:00 CDT(-0500)] <anastasiac> lahabana, yes.
[11:14:08 CDT(-0500)] <anastasiac> that error happens when the resource isn't ready yet
[11:14:23 CDT(-0500)] <lahabana> hmm
[11:14:29 CDT(-0500)] <anastasiac> you need to make sure that your controllers subcomponent doesn't instantiate until the resource has been fetched
[11:14:42 CDT(-0500)] <anastasiac> I'm just looking over your code to see what you do so far
[11:15:07 CDT(-0500)] <lahabana> ho ok
[11:15:21 CDT(-0500)] <lahabana> but right now they are commented no?
[11:15:44 CDT(-0500)] <anastasiac> what's commented, lahabana?
[11:15:58 CDT(-0500)] <lahabana> the controllers' subcomponent
[11:16:38 CDT(-0500)] <anastasiac> yes, but it's the controllers component itself that is a renderer component and has a resource: controller_template.html
[11:16:57 CDT(-0500)] <anastasiac> when fluid.videoPlayer.controllers instantiates, it will look for that html template
[11:17:04 CDT(-0500)] <lahabana> yes
[11:17:10 CDT(-0500)] <anastasiac> if it's not available, you'll see the error you saw
[11:17:20 CDT(-0500)] <lahabana> ok I see
[11:17:28 CDT(-0500)] <anastasiac> so one way to deal with this is this, lahabana:
[11:17:56 CDT(-0500)] <anastasiac> the controllers' parent component can load the resource and then fire an event when it's ready. controllers will wait for that event by using "createOnEvent"
[11:18:06 CDT(-0500)] * anastasiac is looking for docs to point you to
[11:18:30 CDT(-0500)] <lahabana> ho I see what you mean
[11:18:35 CDT(-0500)] <anastasiac> lahabana: info on "createOnEvent" : http://wiki.fluidproject.org/display/docs/Controlling+The+Timing+of+Subcomponent+Creation
[11:19:31 CDT(-0500)] <lahabana> this is done in UIOptions no
[11:19:42 CDT(-0500)] <anastasiac> lahabana, fluid.videoPlayer is the parent of fluid.videoPlayer.controllers, so fluid.videoPlayer could load the resources using fluid.fetchResources, and then fire an event
[11:19:44 CDT(-0500)] <lahabana> there's its own component to laod the templates
[11:19:47 CDT(-0500)] <anastasiac> yes, I think UIOptions does that
[11:19:56 CDT(-0500)] <lahabana> ho ok
[11:20:04 CDT(-0500)] <anastasiac> you don't necessarily need to create a whole separate component
[11:20:12 CDT(-0500)] <anastasiac> but UIOptions is a reasonable model to see how it's done
[11:20:45 CDT(-0500)] <lahabana> well I think I will in the end cause I'll have 3 different template in the end I think
[11:21:16 CDT(-0500)] <lahabana> 1 for the controllers 1 for the captionner and one for the whole videoPlayer
[11:21:20 CDT(-0500)] <lahabana> no?
[11:21:30 CDT(-0500)] <anastasiac> so the UI Options model might be the way to tgo
[11:21:32 CDT(-0500)] <anastasiac> to go
[11:21:37 CDT(-0500)] <lahabana> ok
[11:21:40 CDT(-0500)] <lahabana> thx (smile)
[11:21:59 CDT(-0500)] <lahabana> I really gtg now
[11:22:05 CDT(-0500)] <lahabana> thanks a lot for your help
[11:23:20 CDT(-0500)] <anastasiac> anytime, lahabana. Your questions are very helpful in identifying where our documentation is lacking, which is very useful for us
[13:00:43 CDT(-0500)] <Bosmon> Hi, cindyli - what's the "Mad Haps"?
[13:00:57 CDT(-0500)] <cindyli> Bosmon: still mad
[13:02:11 CDT(-0500)] <Bosmon> Did you manage to reorganise the components so that the component can load a 2nd time on Chrome?
[13:02:32 CDT(-0500)] <cindyli> Bosmon: reorganized but no luck
[13:02:39 CDT(-0500)] <cindyli> i'm trying a bit more. will let you know the result very soon
[13:02:45 CDT(-0500)] <Bosmon> Ok
[13:02:50 CDT(-0500)] <Bosmon> Do you want to show me what you've got so far?
[13:08:18 CDT(-0500)] <cindyli> sure, Bosmon. pushing into github. one sec
[13:10:37 CDT(-0500)] <cindyli> Bosmon: it's in - https://github.com/cindyli/infusion/tree/FLUID-4317
[13:11:38 CDT(-0500)] <cindyli> the loading issue at the 2nd round in chrome does get fixed in the latest commit. but it breaks the fat panel, which is what i'm working on
[13:16:43 CDT(-0500)] <Bosmon> ok, thanks
[13:17:20 CDT(-0500)] <cindyli> np
[13:20:40 CDT(-0500)] <Bosmon> cindyli - I notice that you still have the templateLoader registered as "first" in the tests
[13:21:28 CDT(-0500)] <Bosmon> And that the TemplateReady event is still held in the templateLoader
[13:21:29 CDT(-0500)] <cindyli> yes, Bosmon, i moved the fetchResources of all the templates from templateLoader into uiOptionsLoader
[13:21:36 CDT(-0500)] <Bosmon> I see
[13:22:18 CDT(-0500)] <cindyli> TemplateReady event in templateLoader can go. u will say it's not linked with TemplateReady event in uiOptionsLoader any more
[13:22:36 CDT(-0500)] <Bosmon> Hmm, I'm not seeing this in the branch....
[13:22:37 CDT(-0500)] <cindyli> see, not "say"
[13:23:00 CDT(-0500)] <cindyli> line 261: onUIOptionsTemplateReady: null,
[13:23:00 CDT(-0500)] <Bosmon> I am at b91167d
[13:23:28 CDT(-0500)] <cindyli> that's right. having a look
[13:25:10 CDT(-0500)] <cindyli> https://github.com/cindyli/infusion/blob/FLUID-4317/src/webapp/components/uiOptions/js/UIOptions.js#L264
[13:25:57 CDT(-0500)] <Bosmon> Yes, i see that.... on line 190, I still see templateLoader as fetching its own resources
[13:26:15 CDT(-0500)] <Bosmon> Ah, I see, it isn't
[13:26:21 CDT(-0500)] <Bosmon> It's just that the function still has its old name...
[13:26:47 CDT(-0500)] <cindyli> right. need a new name
[13:27:12 CDT(-0500)] <Bosmon> ok
[13:27:19 CDT(-0500)] <Bosmon> So I should just fire up the FatPanel tests?
[13:27:26 CDT(-0500)] <cindyli> no, fat panel demo
[13:27:28 CDT(-0500)] <Bosmon> Do they fail on FF too, or just on Chrome
[13:27:29 CDT(-0500)] <Bosmon> Ok
[13:27:35 CDT(-0500)] <cindyli> everywhere
[13:27:41 CDT(-0500)] <Bosmon> ah, good
[13:27:48 CDT(-0500)] <cindyli> yes, good (sad)
[13:28:07 CDT(-0500)] <Bosmon> Well, it's always easier to debug consistent issues (smile)
[13:28:16 CDT(-0500)] <cindyli> that's true
[13:30:25 CDT(-0500)]

<Bosmon> So, cindyli - what I get is an error, "Failed to resolve reference

Unknown macro: {uiOptionsLoader}

events.onUIOptionsComponentReady - could not match context with name uiOptionsLoader from component root of type fluid.staticEnvironment"


[13:30:28 CDT(-0500)] <Bosmon> Is this what you see too?
[13:30:37 CDT(-0500)] <cindyli> exactly
[13:30:50 CDT(-0500)] <Bosmon> Ok, so we see this from the evebt binder
[13:31:39 CDT(-0500)] <Bosmon> It's actually in the middle of instantiating eventBinder.binder
[13:31:44 CDT(-0500)] <Bosmon> And trying to resolve its events...
[13:32:30 CDT(-0500)] <Bosmon> I see that I need to fix this error message
[13:32:36 CDT(-0500)] <Bosmon> It makes it sound like there is no component tree, when there is
[13:33:33 CDT(-0500)] <Bosmon> But the error message seems pretty clear... there is indeed no uiOptionsLoader in the tree
[13:34:47 CDT(-0500)] <Bosmon> Hmm
[13:34:51 CDT(-0500)] <Bosmon> I'm sure we fixed this problem before
[13:34:56 CDT(-0500)] <Bosmon> It is just the same issue that we saw last week
[13:35:19 CDT(-0500)] <Bosmon> The component is trying to construct on "afterRender" which is too early
[13:35:25 CDT(-0500)] <Bosmon> This event fires immediately after the iframe has loaded
[13:35:32 CDT(-0500)] <Bosmon> But it does not wait for the uiOptions tree to construct
[13:35:48 CDT(-0500)] <Bosmon> cindyli ^ ?
[13:37:07 CDT(-0500)] <cindyli> the priority of "uiOptionsBridge" is first
[13:37:59 CDT(-0500)] <cindyli> so, uiOptionsBridge.uiOptionsLoader should be constructed as a first
[13:38:20 CDT(-0500)] <cindyli> ok, i might be wrong
[13:38:54 CDT(-0500)] <cindyli> since there are severall subcomponents of "fatPanelUIOptions" are created on afterRender
[13:38:58 CDT(-0500)] <Bosmon> No, you're right... I do see it constructed
[13:39:02 CDT(-0500)] <Bosmon> Let me check some more
[13:39:21 CDT(-0500)] <Bosmon> Problem is that finalInit of the bridge has not run
[13:39:37 CDT(-0500)] <Bosmon> Or at least, not been effective
[13:39:52 CDT(-0500)] <Bosmon> No, that's not right either, it has run
[13:48:53 CDT(-0500)] <Bosmon> Ok, cindyli
[13:48:58 CDT(-0500)] <Bosmon> I have found an awful, awful problem (tongue)
[13:49:40 CDT(-0500)] <Bosmon> You can relax, whilst we think what to do about it.....
[13:50:09 CDT(-0500)] <Bosmon> And interestingly it relates to harriswong's and Justin_o's work from yesterday....
[13:50:18 CDT(-0500)] <colinclark> eek
[13:50:19 CDT(-0500)] <colinclark> (smile)
[13:50:31 CDT(-0500)] <colinclark> I have a bit of an awful problem on the other side of UIO, too
[13:50:32 CDT(-0500)] <Bosmon> Or rather it relates to what we need to do about it (tongue)
[13:50:37 CDT(-0500)] <colinclark> one of those days (wink)
[13:50:46 CDT(-0500)] <Bosmon> The issue is that since we have TWO copies of fluid, one in the iframe, and one on the outside
[13:50:54 CDT(-0500)] <Bosmon> And they are sharing components, "across the void"
[13:51:10 CDT(-0500)] <Bosmon> Given we have such a ridiculous algorithm in "allocateSimpleId", it turns out that BOTH of them have issued a component with id number 12
[13:51:36 CDT(-0500)] <Justin_o> Bosmon: you mean for the IoC resolution?
[13:51:43 CDT(-0500)] <Bosmon> Justin_o - yes
[13:51:54 CDT(-0500)] <Bosmon> It's clear we need to make much better efforts to ensure that ids allocated by the framework are actually unique
[13:51:58 CDT(-0500)] <Bosmon> As Justin_o suggested some months ago
[13:52:28 CDT(-0500)] <Justin_o> Bosmon: other than for debugging is this causing any functional issues
[13:52:34 CDT(-0500)] <Justin_o> for IoC
[13:52:39 CDT(-0500)] <Bosmon> Justin_o - it causes FatPanelUIOptions to fail
[13:52:41 CDT(-0500)] <Justin_o> or UIO in general
[13:52:44 CDT(-0500)] <Bosmon> In cindy's current branch
[13:52:48 CDT(-0500)] <Justin_o> Bosmon: ah.. that's what the problem has been
[13:52:53 CDT(-0500)] <Bosmon> She tries to resolve a component, and IoC fails to find it
[13:53:03 CDT(-0500)] <Bosmon> Since it thinks it has ALREADY seen the component which it is looking for in its search
[13:53:54 CDT(-0500)] <Justin_o> Bosmon: okay.. do you have any thoughts on how to do this?
[13:53:59 CDT(-0500)] <Bosmon> Well, a few
[13:54:03 CDT(-0500)] <Bosmon> None of them totally satisfactory
[13:54:10 CDT(-0500)] <Bosmon> We could adopt the approach which jQuery do
[13:54:12 CDT(-0500)] <Justin_o> does the "fluid" object itself have any unique identifier to it
[13:54:24 CDT(-0500)] <Bosmon> Justin_o - nothing in JS has any unique identifier to it
[13:54:27 CDT(-0500)] <Bosmon> Unless you put one there (tongue)
[13:54:31 CDT(-0500)] <Justin_o> Bosmon: (sad)
[13:54:43 CDT(-0500)] <Bosmon> Which is the whole reason behind our assigning ids to all of our components in the first place
[13:54:45 CDT(-0500)] <Justin_o> Bosmon: okay.. so jquery uses some sort of timestamp or something?
[13:55:12 CDT(-0500)] <Bosmon> Not exactly (tongue)
[13:55:42 CDT(-0500)] <Bosmon> Here is the relevant line of jQuery code:
[13:55:44 CDT(-0500)] <Bosmon> expando: "jQuery" + ( jQuery.fn.jquery + Math.random() ).replace( /\D/g, "" ),
[13:56:55 CDT(-0500)] <Justin_o> Bosmon: i suppose this isn't guaranteed unique either though
[13:57:18 CDT(-0500)] <Bosmon> No, it isn't
[13:57:34 CDT(-0500)] <Bosmon> I guess it will fail about 1 time in 10^9 (tongue)
[13:57:54 CDT(-0500)] <Justin_o> Bosmon: (smile)
[13:57:59 CDT(-0500)] <Bosmon> Although it could be a lot worse, depending on how random generators are seeded in different frames
[13:58:11 CDT(-0500)] <Justin_o> Bosmon: ah, yes.. i guess so
[13:58:13 CDT(-0500)] <Bosmon> And it will also fill all of our ids with a lot of random crap...
[13:58:28 CDT(-0500)] <Justin_o> Bosmon: yes.. they'd be quite long
[13:58:38 CDT(-0500)] <Bosmon> Trouble is, it's hard to do very much better - since by definition you don't know when an iframe has started up, unless it comes to tell you
[13:58:45 CDT(-0500)] <Bosmon> By which time it is too late
[13:58:55 CDT(-0500)] <Bosmon> It has probably already started allocating ids to things long before this time (tongue)
[13:59:47 CDT(-0500)] <Justin_o> Bosmon: i suppose whatever we choose it should also work well in cases where we have more than one instance of "fluid" on the same page, even without the iframe
[13:59:55 CDT(-0500)] <Bosmon> Justin_o - exactly
[14:00:52 CDT(-0500)] <Justin_o> Bosmon: so i'd guess the jquery stile would get progressively worse the more instances of "fluid" there are.. so in a portal environment it could be several times more likely to fail
[14:01:16 CDT(-0500)] <Justin_o> than compared to this iframe case
[14:01:26 CDT(-0500)] <Justin_o> but still probably quite low
[14:01:31 CDT(-0500)] <Bosmon> Yes
[14:01:36 CDT(-0500)] <Justin_o> what were your other options?
[14:01:50 CDT(-0500)] <Bosmon> Well, there is the timestamp, as you mentioned
[14:02:11 CDT(-0500)] <Bosmon> But that relies that the creation time of the various fluids do not agree within 1 millisecond
[14:02:19 CDT(-0500)] <Bosmon> Or perhaps a nanosecond, on modern OSs
[14:04:02 CDT(-0500)] <Bosmon> It seems this is a hard problem to solve well... which is one reason we never made a strong attempt to solve it, before (tongue)
[14:04:12 CDT(-0500)] <Justin_o> Bosmon: (smile)
[14:04:29 CDT(-0500)] <Justin_o> Bosmon: what's the chance that they would actually be created that close together
[14:04:39 CDT(-0500)] <Bosmon> Justin_o - I guess it depends on a lot of things
[14:04:46 CDT(-0500)] <Bosmon> How fast the machine is, primarily
[14:04:51 CDT(-0500)] <Justin_o> Bosmon: right
[14:05:02 CDT(-0500)] <Bosmon> A big problem is that timer ticks on old versions of Windows are VERY slow
[14:05:10 CDT(-0500)] <Bosmon> And also the machines themselves are very slow
[14:05:26 CDT(-0500)] <Bosmon> Well, those two fight against each other somewhat (tongue)
[14:05:41 CDT(-0500)] <harriswong> Bosmon, justin_o: is it possible to store a hash table on all generated randomized unique-ids? and check the table before you use it?
[14:06:13 CDT(-0500)] <harriswong> Bosmon, justin_o: or is it possible to generate our own unique hash table file and simply pull from there in ascending order?
[14:06:15 CDT(-0500)] <Bosmon> But 32-bit windows only has 16ms resolution on ticks
[14:06:21 CDT(-0500)] <Bosmon> harriswong - there is nowhere to put the table
[14:10:16 CDT(-0500)] <harriswong> Bosmon, Justin_o: if timestamp is not a good idea because there might be chances that two timestamps would be used at the same time because they are called too closely together, then would it be possible to have a 'padding' attached to it to widen the gap, giving it a bit of a threshold to ensure there is no overlap?
[14:11:13 CDT(-0500)] <harriswong> like incremental (integer * timestamp)
[14:11:23 CDT(-0500)] <Bosmon> harriswong - this "padding" would be subject to exactly the same problems as the original random number solution
[14:11:36 CDT(-0500)] <Bosmon> If it was deterministic, it would continue to collide between different instances
[14:11:36 CDT(-0500)] <harriswong> bad bracket. (incremental-integer * timestamp)
[14:11:48 CDT(-0500)] <Bosmon> If it was not deterministic, there would be little value to using the timestamp (tongue)
[14:12:15 CDT(-0500)] <Bosmon> It seems that every solution to this problem in the JS community uses random numbers, so it looks like we will just have to bite the bullet
[14:13:14 CDT(-0500)] <Justin_o> Bosmon: okay.. at any rate it's an improvement over what we have so far
[14:14:01 CDT(-0500)] <harriswong> we need true random numbers (tongue)
[14:15:12 CDT(-0500)] <colinclark> Like using a lava lamp?
[14:15:30 CDT(-0500)] <colinclark> Does anyone remember the "truly random" generator SGI created
[14:15:41 CDT(-0500)] <colinclark> which I believe was powered by cameras pointed at an array of lava lamps?
[14:15:52 CDT(-0500)] <Justin_o> colinclark: is that for real?
[14:15:57 CDT(-0500)] <harriswong> no way..
[14:16:03 CDT(-0500)] <harriswong> interesting..
[14:16:05 CDT(-0500)] <colinclark> http://en.wikipedia.org/wiki/Lavarand
[14:16:25 CDT(-0500)] <colinclark> not to be confused with LavaRnd, which does not use Lava Lamps (tongue)
[14:18:06 CDT(-0500)] <Bosmon> Well, there are numerous web services that will provide us with highly random numbers
[14:18:17 CDT(-0500)] <Bosmon> But the economics of this will not help us all that much (tongue)
[14:18:24 CDT(-0500)] <colinclark> yeah, it would be terrible
[14:18:41 CDT(-0500)] <colinclark> Every time someone instantiated Infusion on a page, out we'd go to a Lava Lamp service
[14:18:51 CDT(-0500)] <colinclark> and then all our users would hate us
[14:19:01 CDT(-0500)] <Justin_o> colinclark: or they might think we're hip
[14:19:26 CDT(-0500)] <colinclark> yeah
[14:19:28 CDT(-0500)] <colinclark> super cool
[14:22:56 CDT(-0500)] <Bosmon> Ok, so here is my best shot so far (tongue)
[14:23:10 CDT(-0500)] <Bosmon> What do you say to ids prefixes like "9jz2p2kpib"
[14:23:19 CDT(-0500)] <Bosmon> This packs as much randomness into as short a space as possible (tongue)
[14:23:46 CDT(-0500)] <Bosmon> The following fairly compact impl will produce them: (Math.floor(Math.random() * 1e15)).toString(36)
[14:24:49 CDT(-0500)] <Justin_o> Bosmon: so is that as random as jquery's method, because i like the shortness..
[14:24:53 CDT(-0500)] <Bosmon> It's unslightly, but it's the shortest unsightly thing I can easilyi think of...
[14:25:10 CDT(-0500)] <Justin_o> Bosmon: i thought it would be as long as one of those git hashes
[14:25:19 CDT(-0500)] <Bosmon> Yes, this uses all of the roughly 15 decimal digits of randomness that we get from one shot of "random"
[14:25:20 CDT(-0500)] <Justin_o> which would have been awful to look at in code
[14:25:34 CDT(-0500)] <Bosmon> Well, we can continue making it longer... but it doesn't need to be THAT random (tongue)
[14:25:54 CDT(-0500)] <Bosmon> Although actually "birthday analysis" says that this method will cause a collision 1 time in about 100 million
[14:25:58 CDT(-0500)] <Justin_o> Bosmon: (smile) okay.. i'm happy with it.. i guess other people should weigh in on it too
[14:26:21 CDT(-0500)] <Bosmon> No wait, it's much better than that...
[14:26:33 CDT(-0500)] <Justin_o> Bosmon: well that's still pretty good.. i'll try not to refresh my browser during testing too much (smile)
[14:26:51 CDT(-0500)] <Bosmon> 100 million is the number of iframes or instances of fluid we would need to make in order for the chance of collision to reach 50% (tongue)
[14:27:08 CDT(-0500)] <colinclark> +1 for 100 million iFrames!
[14:27:10 CDT(-0500)] <colinclark> Wicked
[14:27:12 CDT(-0500)] <Bosmon> hahahaha
[14:27:40 CDT(-0500)] <Bosmon> Even with my 114 top-level Chrome windows, I'm some distance off making these (tongue)
[14:28:00 CDT(-0500)] <Bosmon> So, this would be a good improvement across the board... since it would also help with the id collsion problem we were talking about with harris yesterday
[14:28:29 CDT(-0500)] <Bosmon> It would be sufficiently good that we would no longer need to check the document for whether an id was in it
[14:28:37 CDT(-0500)] <Bosmon> Which I guess would actually speed things up a little
[14:28:49 CDT(-0500)] <Bosmon> Just the downside is that our ids become full of a fair amount of junk (tongue)
[14:32:01 CDT(-0500)] <Bosmon> Any other votes/opinions on this technique?
[14:32:31 CDT(-0500)] <Bosmon> athena, michelled, EricDalquist?
[14:34:03 CDT(-0500)] <EricDalquist> hi Bosmon
[14:34:22 CDT(-0500)] <Bosmon> EricDalquist - as a short summary, we are noticing that ids produced by Fluid are not terribly unique, and this is now punishing us
[14:34:30 CDT(-0500)] <EricDalquist> hah
[14:34:34 CDT(-0500)] <Bosmon> This is clearly even more relevant in a portlet environment (tongue)
[14:34:38 CDT(-0500)] <EricDalquist> yes
[14:34:56 CDT(-0500)] <Bosmon> A brief survey of the alternatives shows we don't have any other option in JS but to construct some kind of prefix using Math.random()
[14:35:06 CDT(-0500)] <Bosmon> There is no other reliable source of unique identification in the system
[14:35:14 CDT(-0500)] <EricDalquist> yeah
[14:35:42 CDT(-0500)] <Bosmon> I proposed the following prefix generator (Math.floor(Math.random() * 1e15)).toString(36)
[14:35:58 CDT(-0500)] <EricDalquist> how is Math.random() seeded?
[14:36:03 CDT(-0500)] <EricDalquist> just out of curiosity
[14:36:09 CDT(-0500)] <EricDalquist> and that seems reasonable
[14:36:36 CDT(-0500)] <Bosmon> http://www.trusteer.com/sites/default/files/Temporary_User_Tracking_in_Major_Browsers.pdf
[14:36:45 CDT(-0500)] <Bosmon> Not much info on that
[14:36:54 CDT(-0500)] <EricDalquist> yeah
[14:36:58 CDT(-0500)] <Bosmon> This paper says, "There is no complementary seeding function, so seeding strategy is implementation dependent"
[14:36:59 CDT(-0500)] <EricDalquist> I figured its probably browser specific
[14:37:25 CDT(-0500)] <EricDalquist> and I'd hope that it is seeded at browser start
[14:37:30 CDT(-0500)] <EricDalquist> and not like seeded per page render
[14:37:42 CDT(-0500)] <EricDalquist> also I think that gives you a sufficiently large address space
[14:37:56 CDT(-0500)] <Bosmon> It looks like the same generator is shared across all JS contexts in a browser
[14:38:07 CDT(-0500)] <EricDalquist> and since this is all client side stuff I'm assuming there is no security risk with collisions
[14:38:16 CDT(-0500)] <EricDalquist> just poor functionality in that case
[14:38:32 CDT(-0500)] <Bosmon> Well, the "poor functionality" is likely to be that the app will fail (tongue)
[14:38:44 CDT(-0500)] <EricDalquist> right
[14:38:51 CDT(-0500)] <Bosmon> Our entry point to this discussion was discovering a collision between two instances of fluid held in different iframes
[14:39:06 CDT(-0500)] <EricDalquist> but this isn't a case where I'd want a random number that's been passed through like SHA or some such
[14:39:09 CDT(-0500)] <Bosmon> We handed a component from one iframe to the other ....
[14:39:12 CDT(-0500)] <Bosmon> Right
[14:39:16 CDT(-0500)] <Bosmon> It doesn't need to be great
[14:39:20 CDT(-0500)] <EricDalquist> yeah
[14:39:24 CDT(-0500)] <EricDalquist> I think that solution is just fine that
[14:39:35 CDT(-0500)] <Bosmon> It just needs to be good enough to avoid liable collision within the same browser process
[14:39:39 CDT(-0500)] <EricDalquist> perhaps even overkill with the size of the value
[14:39:51 CDT(-0500)] <EricDalquist> but I'm sure it will work (smile)
[14:39:54 CDT(-0500)] <Bosmon> Yes, I was thinking about shortening it a touch (tongue)
[14:40:01 CDT(-0500)] <EricDalquist> Math.random() in JS returns a float?
[14:40:02 CDT(-0500)] <Bosmon> We could knock off a few "junk digits" (tongue)
[14:40:04 CDT(-0500)] <Bosmon> Yes, it does
[14:40:08 CDT(-0500)] <EricDalquist> from 0..1?
[14:40:11 CDT(-0500)] <Bosmon> yes
[14:40:26 CDT(-0500)] <colinclark> sorry, michelled and I have been distracted with our other crisis, the complete breakage of this CSS Parser
[14:40:27 CDT(-0500)] <EricDalquist> yeah
[14:40:29 CDT(-0500)] <EricDalquist> all looks good
[14:40:31 CDT(-0500)] <colinclark> should we be paying attention to anything?
[14:40:32 CDT(-0500)] <Bosmon> Around 15 digits are significant... from about 52 mantissa bits
[14:40:39 CDT(-0500)] <Bosmon> But only 41-41 bits might be truly random
[14:40:41 CDT(-0500)] <colinclark> I trust EricDalquist on these sorts of questions more than myself anyway (tongue)
[14:40:43 CDT(-0500)] <Bosmon> er 41-48
[14:40:48 CDT(-0500)] <EricDalquist> yeah
[14:40:53 CDT(-0500)] <EricDalquist> for your usage that's just fine
[14:40:59 CDT(-0500)] <Bosmon> Good-oh
[14:41:07 CDT(-0500)] <EricDalquist> nice that JS has an easy way to base36 encode something
[14:42:28 CDT(-0500)] <Bosmon> Yeah, I think we can slim it down to 12 decimal digits without really losing anything
[14:42:49 CDT(-0500)] <EricDalquist> yup
[14:42:54 CDT(-0500)] <Bosmon> For a saving of roughly 2 characters
[14:43:18 CDT(-0500)] <EricDalquist> 1e12 is in float range right?
[14:43:27 CDT(-0500)] <EricDalquist> so you can do float math and avoid double?
[14:43:36 CDT(-0500)] <EricDalquist> not sure if there is that much of a perf difference on moder machines
[14:43:52 CDT(-0500)] <Bosmon> EricDalquist - there are no numeric types in JS
[14:43:54 CDT(-0500)] <EricDalquist> but I'm also guessing you're not generating thousands of these IDs in rapid successon
[14:43:56 CDT(-0500)] <Bosmon> So you don't have any control
[14:44:02 CDT(-0500)] <EricDalquist> true
[14:44:04 CDT(-0500)] <Bosmon> EricDalquist - we'll just generate one ID on startup of fluid
[14:44:10 CDT(-0500)] <Bosmon> And then use that as a prefix subsequently
[14:44:40 CDT(-0500)] <EricDalquist> oh yeah
[14:44:59 CDT(-0500)] <Bosmon> Justin_o - am I ok to add this to bug parade and make up a pull request?
[14:46:42 CDT(-0500)] <EricDalquist> FYI the JVM uses a 128bit random value from a SecureRandom instance when generating random UUIDs
[14:47:14 CDT(-0500)] <EricDalquist> though its actually less than that
[14:47:16 CDT(-0500)] <Bosmon> EricDalquist - well, that's very nice of it (smile)
[14:47:22 CDT(-0500)] <EricDalquist> because they set a bunch of bits to known values
[14:47:25 CDT(-0500)] <EricDalquist> so more like 116 bits
[14:47:29 CDT(-0500)] <EricDalquist> just as a comparison
[14:49:09 CDT(-0500)] <EricDalquist> ok ... back to video recording
[15:05:12 CDT(-0500)] <Bosmon> cindyli - are you there?
[15:05:18 CDT(-0500)] <Bosmon> I have pushed a FLUID-4350 branch to my repo
[15:05:30 CDT(-0500)] <Bosmon> Do try to merge it in to your branch and see if your problem goes away
[15:07:00 CDT(-0500)] <cindyli> ya Bosmon
[15:07:06 CDT(-0500)] <cindyli> sure
[15:11:46 CDT(-0500)] <cindyli> Bosmon: the last commit in ur 4350 was from 3 days ago, a project repo merge
[15:12:03 CDT(-0500)] <Bosmon> !
[15:12:24 CDT(-0500)] <Bosmon> Oh dear
[15:12:26 CDT(-0500)] <cindyli> Bosmon: is this ur github: https://github.com/amb26/
[15:12:31 CDT(-0500)] <Bosmon> I have misused git once again (sad)
[15:13:10 CDT(-0500)] <Bosmon> Ok, I pushed it properly now, sorry
[15:13:17 CDT(-0500)] <cindyli> np thanks
[15:14:35 CDT(-0500)] <cindyli> hi, genius, problem solved
[15:16:24 CDT(-0500)] <Bosmon> Sorry to hold up your work...
[15:16:35 CDT(-0500)] <Bosmon> What remaining failures are there now?
[15:17:51 CDT(-0500)] <cindyli> Bosmon: sigh... everything passes in firefox but fat panel demo fails in chrome
[15:18:01 CDT(-0500)] <Bosmon> cindyli - that's fine
[15:18:06 CDT(-0500)] <Bosmon> Not entirely unexpected (smile)
[15:18:34 CDT(-0500)] <Bosmon> So, what's the situation now - do all test cases pass for all configurations in all browsers except fat panel?
[15:18:43 CDT(-0500)] <colinclark> https://github.com/FGRibreau/JSCSSP
[15:18:47 CDT(-0500)] <colinclark> This one may have saved the day
[15:19:17 CDT(-0500)] <cindyli> Bosmon: ui options tests pass in chrome, haven't tried other unit tests
[15:19:35 CDT(-0500)] <cindyli> and other browsers
[15:19:35 CDT(-0500)] <Bosmon> cindyli - Ok - can you push again?
[15:19:40 CDT(-0500)] <Bosmon> And I will investigate the chrome problem
[15:19:44 CDT(-0500)] <cindyli> sure
[15:19:44 CDT(-0500)] <Bosmon> And you can try to look for other failures
[15:19:45 CDT(-0500)] <cindyli> thanks.
[15:19:52 CDT(-0500)] <cindyli> ok
[15:20:14 CDT(-0500)] <cindyli> Bosmon: pushed
[15:23:28 CDT(-0500)] <Bosmon> cindyli - FatPanel works for me in Chrome (sad)
[15:23:33 CDT(-0500)] <Bosmon> What effect do you see?
[15:24:15 CDT(-0500)] <cindyli> Bosmon: if u adjust the settings, is the main panel enhanced automatically?
[15:24:28 CDT(-0500)] <Bosmon> cindyli - yes
[15:24:48 CDT(-0500)] <cindyli> interesting, doesn't happen on me
[15:24:57 CDT(-0500)] <cindyli> let me re-start chrome
[15:25:26 CDT(-0500)] <cindyli> false alarm (smile)
[15:25:30 CDT(-0500)] <Bosmon> yay (smile)
[15:25:31 CDT(-0500)] <cindyli> it's working
[15:25:43 CDT(-0500)] <Bosmon> Have you found any other failures yet?
[15:25:49 CDT(-0500)] <cindyli> no
[15:25:51 CDT(-0500)] <Bosmon> (smile)
[15:26:03 CDT(-0500)] <cindyli> cool
[15:26:24 CDT(-0500)] <Bosmon> I notice that TOC doesn't do anything in this demo
[15:26:31 CDT(-0500)] <Bosmon> Is that because there is nothing to summarise?
[15:26:36 CDT(-0500)] <Bosmon> Or is it not merged into your branch yet?
[15:26:42 CDT(-0500)] <cindyli> no, not merged
[15:26:57 CDT(-0500)] <cindyli> the new toc is not in project repo yet
[15:27:20 CDT(-0500)] <cindyli> the new toc may break uio, as i rmb
[15:27:34 CDT(-0500)] <Bosmon> ok
[15:27:38 CDT(-0500)] <cindyli> i am finishing up the testing across the browsers (on windows) and let u know
[15:27:47 CDT(-0500)] <Bosmon> Assuming you find no further failures, perhaps the next step is to try to merge toc into your branch?
[15:28:18 CDT(-0500)] <Bosmon> Perhaps tomorrow then we can get a "basically working" UIO into trunk and then start to finally turn to the configuration issues
[15:28:49 CDT(-0500)] <Bosmon> You should try to remove pageEnhancer from FatPanel first though
[15:30:30 CDT(-0500)] <cindyli> i'm trying removing pageEnhancer from fat panel in another branch - 4348
[15:30:56 CDT(-0500)] <Bosmon> ok, cool
[15:30:56 CDT(-0500)] <cindyli> Bosmon: with the project repo master tho
[15:31:06 CDT(-0500)] <Bosmon> cindyli - why not with your branch?
[15:31:17 CDT(-0500)] <Bosmon> You will certainly have to undo any work you do in the main master, since it has diverged so far
[15:31:29 CDT(-0500)] <Bosmon> We should be considering your branch as the authoritative "trunk" for UIO for now, I think
[15:31:33 CDT(-0500)] <Bosmon> Since it is so different to all the other branches
[15:31:54 CDT(-0500)] <cindyli> ok, migrating ...
[15:32:05 CDT(-0500)] <Bosmon> you essentially have the "frog" now (tongue)
[15:32:11 CDT(-0500)] <Bosmon> I forgot to bring FROGG when I visited....
[15:32:38 CDT(-0500)] <cindyli> (smile)
[15:38:49 CDT(-0500)] <cindyli> Bosmon: tested on all 4 browsers, a total pass!
[15:39:44 CDT(-0500)] <Bosmon> cindyli - that's awesome
[15:40:03 CDT(-0500)] <cindyli> so, next is toc, then removing pageEnhancer from fat panel
[15:40:14 CDT(-0500)] <Bosmon> Excellent
[15:40:19 CDT(-0500)] <Bosmon> I will take a shower (tongue)
[15:40:28 CDT(-0500)] <cindyli> shower, in the middle of a day?
[15:41:11 CDT(-0500)] <harriswong> Bosmon: did you happen to have some time to look at the #4209 pull request again? https://github.com/fluid-project/infusion/pull/111
[15:43:01 CDT(-0500)] <Bosmon> harriswong - yes, it looks good now
[15:43:09 CDT(-0500)] <harriswong> Bosmon: sweet thanks
[15:43:15 CDT(-0500)] <Bosmon> I will merge it up shortly - although it will probably be best to use cindy's merge rather than mine
[15:43:24 CDT(-0500)] <Bosmon> I guess it doesn't really matter in git which order you do things in (tongue)
[15:44:01 CDT(-0500)] <harriswong> Bosmon: i don't really know either, but i think justin_o might have a preference
[15:44:04 CDT(-0500)] <Bosmon> But we can't actually use the branch until cindyli can merge it in, so ...
[15:44:13 CDT(-0500)] <Bosmon> Yes, we can wait for him tomorrow
[15:44:22 CDT(-0500)] <harriswong> thanks!
[15:44:33 CDT(-0500)] <Bosmon> I think the best idea might be to just have cindyli do "one giant merge" once everything is basically working in her branch
[16:00:07 CDT(-0500)] <jessm> who knew that browser support was such a mercurial space?!
[16:00:09 CDT(-0500)] <jessm> fascinating