| bac | hi frankban | 12:01 |
|---|---|---|
| frankban | hi bac | 12:01 |
| bac | frankban, i see your sprite branch is now on staging. | 12:01 |
| frankban | bac: I am seeing the behavior you described there | 12:01 |
| bac | frankban, oh, it seems to work for me! | 12:02 |
| frankban | bac: lol | 12:02 |
| bac | frankban, but i now see that the up/down chevrons have a white background, not transparency, so they look funny on the grey background. have you seen that? | 12:02 |
| frankban | that's crazy bac, I also see the problem you described in the review (the chevron in the menu bar is still the old one) | 12:03 |
| frankban | bac: it seems that the old index.html is being served by staging | 12:04 |
| bac | hmm | 12:04 |
| bac | browser cache? | 12:04 |
| frankban | bac: cleaned, mabybe the html cache manifest? | 12:06 |
| frankban | bac: could you please try to run "make appcache-force" in staging, and then restart the server? | 12:06 |
| bac | frankban, i did a make clean, is that sufficient? | 12:09 |
| bac | check it out now | 12:10 |
| bac | frankban, i did appcache-force/restart | 12:13 |
| frankban | bac: now it works, thanks, and you are right, the chevrons are not transparent | 12:13 |
| bac | i think clean should wipe out the appcache manifest but it does not | 12:13 |
| bac | frankban, glad we're all seeing the same thing now | 12:14 |
| frankban | bac: maybe we should run appcache-force each time we update staging. We can clean the cache and the app data each time, but not our users. | 12:15 |
| bac | frankban, yes, i think it should be part of the clean target and we should just run make clean | 12:15 |
| frankban | bac: re the chevrons, they are transparent in the assets and in the sprite :-/ | 12:17 |
| bac | oh | 12:21 |
| bac | frankban, will you also follow up with the designers regarding chevron up and down? | 12:22 |
| frankban | bac: you mean, the reversed directions? | 12:23 |
| frankban | bac: re the chevrons, locally I have the sprite with a transparent backgorund, in staging the sprite is not transparent | 12:24 |
| frankban | bac: white background in staging :-/ it seems we should fix how we deploy staging. | 12:25 |
| frankban | tveronezi: any idea on why the sprite's background in staging is not transparent? | 12:28 |
| tveronezi | frankban: I am trying to see what is the problem... just a sec. :) | 12:29 |
| frankban | tveronezi: cool thanks | 12:30 |
| tveronezi | frankban: I didn't get the problem. Is it something related to the header? It does not use the "sprite". It uses a regular image. I found this trick to make transparent backgrounds, but I dont see it in our code. http://css-tricks.com/snippets/css/transparent-background-images/ | 12:46 |
| frankban | tveronezi: it is related to the chevrons_(up|down) in the charm panel. they have a white background in staging, they are transparent locally. they use the sprite. Inspecting the code, it seems that the sprite in staging is not transparent | 12:48 |
| frankban | tveronezi: to see those, you might want to clear your browser cache | 12:49 |
| tveronezi | frankban: hmmm... they look the same to me... http://ubuntuone.com/3ukBtOlhcydsB8VtlZtKha http://ubuntuone.com/1QpOBke8x9ah5A9BkTj0CZ | 12:57 |
| frankban | tveronezi: I am referring to the charm description view. Open the charm panel, select a charm, you should see chevrons on each section of the description. | 13:00 |
| gary_poster | hey all | 13:07 |
| tveronezi | frankban... hmmm. I see the problem in both local and staging. I need to check the sprite generation. | 13:07 |
| frankban | tveronezi: cool | 13:07 |
| gary_poster | teknico, hey. how go charm tests? You about ready with a branch? or would it be good to have someone to pair with? | 13:07 |
| * gary_poster reviews | 13:10 | |
| gary_poster | I am reviewing Makyo's bug 1077006 branch | 13:10 |
| _mup_ | Bug #1077006: Charm panel left border should be 2px as per UX design <juju-ui:Triaged> < https://launchpad.net/bugs/1077006 > | 13:10 |
| benji | IRC works better when you turn on your client. | 13:10 |
| gary_poster | words to live by | 13:11 |
| hazmat | g'morning | 13:27 |
| bac | gary_poster, matt's branch has two reviews. both frankban and i tagged the card before starting. | 13:29 |
| bac | morning hazmat. i had to poke uistage a bit yesterday and today. i think we need to update the cronscript to 'make appcache-force' before restarting the gui | 13:32 |
| hazmat | bac, k, i'll take care of it | 13:33 |
| bac | hazmat, i also changed the cron to run every fifteen minutes as that is what most people thought was happening. it was actually only run every 30 minutes. | 13:33 |
| hazmat | bac, where is the cron now? | 13:34 |
| hazmat | i don't see it in crontab for ubuntu or root? | 13:34 |
| hazmat | just added make appcache-force to cron script | 13:35 |
| bac | hazmat, 'crontab -l' and 'crontab -e' is what i used | 13:35 |
| hazmat | ah.. ic | 13:35 |
| bac | as ubuntu | 13:35 |
| hazmat | bac are you sure re 30m? | 13:36 |
| bac | hazmat, previously it was 15,30 | 13:36 |
| * hazmat discards some faulty gray matter | 13:37 | |
| bac | oh, sorry, it was 15,45 | 13:37 |
| gary_poster | bac cool thx. Forgot about that. In somewhat related issue, I am seeing problems in my local instance having to do with some images that are being rendered below where they are supposed to: http://ubuntuone.com/6wirTIHiK40RGV3ahJ3a7G | 13:38 |
| gary_poster | I have done make appcache-force | 13:38 |
| gary_poster | and cleared cache | 13:38 |
| gary_poster | I saw some discussion of problems in log from yesterday | 13:38 |
| gary_poster | but no resolution | 13:38 |
| gary_poster | I also see "Waiting for yui.yahooapis.com" | 13:39 |
| gary_poster | Looks like we are getting css and that is taking awhile | 13:40 |
| gary_poster | bac, frankban, tveronezi you all were talking about this yesterday I think ^^^ . any hints? | 13:41 |
| gary_poster | This link is taking 15 seconds: http://yui.yahooapis.com/combo?3.7.3/build/widget-modality/assets/skins/sam/widget-modality.css&3.7.3/build/widget-stack/assets/skins/sam/widget-stack.css&3.7.3/build/panel/assets/skins/sam/panel.css&3.7.3/build/overlay/assets/skins/sam/overlay.css | 13:44 |
| gary_poster | heh, for a 304 | 13:44 |
| tveronezi | gary_poster: The quick resolution was to use the debug mode in the demo server; The css stuff will be fixed by my next branch; 'gallery-markdown' and 'gallery-ellipsis' are not available in our static yui files, so we still need to download those from yuilibs. | 13:45 |
| bac | gary_poster, we had that problem on staging yesterday | 13:45 |
| bac | use of gallery-ellipsis is not in trunk yet | 13:45 |
| bac | tveronezi, i still cannot get it to download | 13:45 |
| gary_poster | bac, ack thanks. tveronezi thanks. how did this get in trunk--what did we miss? | 13:46 |
| bac | gary_poster, if you'd like to pair i'd appreciate it | 13:46 |
| gary_poster | bac ok cool, fire up a hangout | 13:46 |
| bac | gary_poster, one issue is the combined file has 'use strict' at the top. GlobalConfig is not defined with 'var' and that causes a failure. | 13:46 |
| bac | easy fix is to add 'var' in two modules.js and modules-debug.js | 13:47 |
| bac | s/two// | 13:47 |
| gary_poster | bac oh ok cool | 13:47 |
| bac | our story for grabbing everything so we serve it up ourselves is not fully done i think | 13:47 |
| bac | making hangout | 13:47 |
| * bac installing plugin | 13:48 | |
| * bac getting tea | 13:48 | |
| tveronezi | bac: I can download those css files. http://ubuntuone.com/6vHKb78Lq8MFTQEAuWqxkf . If I add galery-ellipsis to the charm-panel.js, it adds the ellipsis to the yuilib url... http://yui.yahooapis.com/combo?gallery-2012.10.31-20-00/build/gallery-markdown/gallery-markdown-min.js&gallery-2012.10.31-20-00/build/gallery-ellipsis/gallery-ellipsis-min.js | 13:57 |
| * teknico is back from lunch | 14:01 | |
| teknico | gary_poster, nope, still struggling with it, would very much like to pair | 14:01 |
| teknico | gary_poster, I already got some help from frankban, but am open to pair with anyone | 14:01 |
| gary_poster | teknico, ack. benji or frankban ^^^ ? | 14:02 |
| teknico | ("it" being setting up charm tests) | 14:03 |
| benji | gary_poster/teknico: I certainly can. I have started a card already this morning, however. | 14:03 |
| gary_poster | benji, how far along are you on that one, then? and/or will it be done soon? :-) | 14:04 |
| benji | gary_poster: probably not "soon", I was trying to figure out the roll in/out transitions for the charm panel; if we switch to ripping out the fade and making it just disappear, that would be quicker | 14:05 |
| gary_poster | benji, suggestion open to your veto: just make it disappear, make a low priority bug for the roll-in/roll-out, and move to helping Nicola. wdyt? | 14:06 |
| benji | gary_poster: that's fine | 14:07 |
| gary_poster | cool thank you. teknico ^^^ benji will join you soon | 14:07 |
| teknico | gary_poster, great, thanks | 14:07 |
| benji | wait, wait, wait... did we completely break our development story? | 14:48 |
| benji | do I have to run make every time I change a JS file now? | 14:48 |
| frankban | benji: are you using "make debug"? | 14:49 |
| benji | frankban: no, should I? | 14:49 |
| frankban | benji: it seems so. | 14:49 |
| benji | hmm | 14:50 |
| benji | I am displeased. | 14:51 |
| * teknico on school run, back in half an hour | 14:56 | |
| benji | gary_poster: the charm panel fade removal is very simple, but I figured that at least you should take a glance: https://codereview.appspot.com/6854043 | 14:58 |
| benji | it took much longer than it should because I was sabataged by the new default of minimizing JS | 14:58 |
| benji | (we should revisit that, it is stupid) | 14:58 |
| gary_poster | benji approved | 14:59 |
| benji | cool, landing | 15:00 |
| benji | re. review approval message: lol | 15:01 |
| benji | teknico: what's up? how can I help? | 15:01 |
| tveronezi | benji: it seems the rev 239 breaks the charm search panel. | 15:13 |
| benji | tveronezi: is rev 239 the branch I just laned? | 15:14 |
| tveronezi | Yes. I cant see the panel now. | 15:14 |
| * benji answers his own question: "yes" | 15:15 | |
| benji | tveronezi: in what way does it break? | 15:16 |
| frankban | benji, tveronezi: confirmed, also in staging, the panel doesn't show up | 15:16 |
| tveronezi | benji: I click in the icon and nothing happens. If I revert one revision, it works again. | 15:16 |
| benji | tveronezi: which icon? | 15:16 |
| tveronezi | benji: charm search. http://ubuntuone.com/4nn1DSpQsT2GW7U45hHOmf | 15:17 |
| benji | hmm, I wonder why it worked in my branch; reverting | 15:18 |
| benji | I wonder what the best way to reviert is given lbox | 15:19 |
| * benji settles on "uncommit" | 15:19 | |
| * benji realized that it doesn't do what he thought it would do. | 15:19 | |
| benji | tveronezi and frankban: fix comitted; thanks for the heads-up | 15:31 |
| * teknico is back | 15:31 | |
| frankban | benji: was it the opacity? | 15:32 |
| teknico | benji, sorry, was afk | 15:32 |
| benji | frankban: here is the fix: http://paste.ubuntu.com/1355684/ | 15:32 |
| benji | teknico: so, what can I do to help? | 15:35 |
| teknico | benji, hangout? | 15:35 |
| benji | teknico: sure, yours or mine? | 15:36 |
| teknico | benji, emily's: https://tinyurl.com/see-emily-code | 15:36 |
| benji | ?? | 15:36 |
| teknico | :-) | 15:36 |
| teknico | benji, frankban set that up for pairings | 15:37 |
| gary_poster | bac bcsaller benji frankban hazmat jovan2 Makyo mattuk1972 teknico tveronezi call in 2 | 15:58 |
| tveronezi | gary_poster: i need to restart... I will back in a sec. | 16:00 |
| gary_poster | ok | 16:00 |
| Makyo | benji, lp:~makyo/juju-gui/remove-sub-rels - https://codereview.appspot.com/6782063/ | 16:10 |
| benji | Makyo: thanks; I'll take a look right away | 16:11 |
| gary_poster | early lunch biab | 16:25 |
| Makyo | mattuk1972, ping | 16:28 |
| mattuk1972 | hey | 16:28 |
| mattuk1972 | makyo, hey | 16:28 |
| Makyo | mattuk1972, bug #1077006 is in staging - it's the inset left border on the charm panel. Have a second to take a look at it and see if it meets design? | 16:29 |
| _mup_ | Bug #1077006: Charm panel left border should be 2px as per UX design <juju-ui:Fix Released by makyo> < https://launchpad.net/bugs/1077006 > | 16:29 |
| mattuk1972 | makyo, its almost there - its kind of odd how if it appears on a dark colour its lighter than the dark | 16:31 |
| mattuk1972 | it cuts off a px where it ends too | 16:32 |
| mattuk1972 | might have to rethink the colour i sent you | 16:32 |
| Makyo | mattuk1972, dark colour as in the header where it says 'precise', or when you click deploy and it shows the charm name? | 16:33 |
| Makyo | And end as in down at the bottom? | 16:33 |
| mattuk1972 | yes to all of that | 16:33 |
| frankban | tveronezi: I see the old friend "Uncaught ReferenceError: GlobalConfig is not defined " when I run "make server" in your branch | 16:33 |
| mattuk1972 | maybe ill have to rethink that | 16:34 |
| mattuk1972 | graphic device | 16:34 |
| frankban | tveronezi: "make debug" works well... | 16:34 |
| mattuk1972 | it really works on this light grey spaces but mess up on dark | 16:34 |
| tveronezi | frankban: whats your browser? | 16:35 |
| frankban | chromium | 16:35 |
| frankban | tveronezi: cache cleaned, appcache forced. | 16:35 |
| tveronezi | precise? | 16:35 |
| frankban | quantal | 16:35 |
| tveronezi | ok... let me check that... | 16:36 |
| frankban | tveronezi: sure | 16:36 |
| Makyo | mattuk1972, Alright. I'll look into the dark space borders. It's currently just an internal drop-shadow on the panel border, but that can be covered up, I suppose. | 16:36 |
| Makyo | tveronezi, ditto here, Chrome and FF on Quantal | 16:36 |
| mattuk1972 | makyo, can it just be a bit darker? or more opaque? or multiply the colour underneath? | 16:37 |
| frankban | tveronezi: I think bac solved that issue in staging addign a "var" before GlobalConfig somewhere (maybe in module.js) | 16:37 |
| Makyo | mattuk1972, Yeah, that's what I'll be looking into. | 16:37 |
| mattuk1972 | makyo, are they the new simpler svg assets I'm seeing in staging? because they are rendering way nicer for me | 16:39 |
| Makyo | mattuk1972, Yep, plus some FF specific improvements. | 16:39 |
| tveronezi | Makyo, frankban: I simply cannot reproduce it here. I've tried everything: chrome, chromium and ff in precise and quantal. It works fine. Actually, it could never fail because the resulting combined file creates declaration like... var juju_config = {...}, GlobalConfig={...}, ... | 16:44 |
| tveronezi | Makyo, frankban: I dont know what is going on. | 16:45 |
| benji | teknico: I am done with my code review. How can I help you on the charm? | 16:45 |
| tveronezi | Makyo, frankban: I will commit the var chang bac did... | 16:45 |
| tveronezi | Makyo, frankban: can you pull and try it again, please? | 16:47 |
| Makyo | tveronezi, I'm seeing it request things from /assets/... rather than /juju-ui/assets/... which was a change we made a while back for the horizon integration. Might be something to talk to frankban / teknico about | 16:47 |
| teknico | benji, I'll push on some more, and pester you again once I hit the next roadblock :-) | 16:48 |
| frankban | Makyo, tveronezi: yes, the 'juju-ui' prefix must be restored. I already added a note to my review. | 16:48 |
| tveronezi | Makyo, frankban: This is something related to the server.js. There is a comment about this change. | 16:48 |
| benji | teknico: ok; I'll look for something else to work on then | 16:48 |
| Makyo | tveronezi, ah, alright. | 16:50 |
| Makyo | tveronezi, This is what I'm seeing in the minified JS: var juju_config={consoleEnabled:!0,serverRouting:!1,html5:!0,container:"#main",viewContainer:"#main",transitions:!1,charm_store_url:"http://jujucharms.com/",socket_url:"ws://localhost:8081/ws"};GlobalConfig= | 16:50 |
| Makyo | Getting a semicolon rather than a comma. | 16:50 |
| tveronezi | Mayko: oh! | 16:51 |
| tveronezi | Mayko: I still dont get why this thing is working for me. | 16:51 |
| tveronezi | Mayko: Did you pull it again? | 16:54 |
| frankban | tveronezi: I didn't get the reason why the prefix cannot be preserved | 16:54 |
| frankban | tveronezi: now make server works for me | 16:55 |
| tveronezi | frankban: I need a diferent prefix, otherwise I cant get the "lib/server.js" line 77 to work. | 16:55 |
| Makyo | Pulled, but it was cached. Works now, tveronezi | 16:57 |
| frankban | tveronezi: ok, but why that cannot be 'server.get('/juju-ui/assets/stylesheets/:file' ... or something? | 16:58 |
| tveronezi | frankban: because if I do this, a request to "/juju-ui/assets/stylesheets/:file" goes to the line 46 instead of the line 77. | 17:01 |
| jovan2 | bcsaller: hi, what's the opposite of Expose? Unexpose? i.e. the action to undo an Expose. | 17:09 |
| bcsaller | jovan2: yes, unexpose | 17:09 |
| tveronezi | frankban: forget what I just said. It is working with the link you proposed. | 17:09 |
| bcsaller | but it can also be though of as "exposed: true||false" | 17:09 |
| frankban | tveronezi: isn't it possible to make the server parse '/juju-ui/assets/stylesheets/:file' and '/juju-ui/assets/all-third.js' before '/juju-ui/'? I know that your solution is easier, but it could generate troubles when integrating juju-gui in other projects, e.g. jaas | 17:10 |
| frankban | tveronezi: oh, cool | 17:10 |
| tveronezi | frankban: so, we should start the urls with "juju-ui" right? | 17:11 |
| frankban | tveronezi: exactly | 17:11 |
| frankban | the static urls | 17:11 |
| tveronezi | frankban: do you see the same problem in the lines 70-71-72? It is from another branch. | 17:12 |
| frankban | tveronezi: do you mean " server.get('/assets/all-third.js'"? | 17:12 |
| tveronezi | frankban, yeap. | 17:13 |
| tveronezi | I will try to change those in a sec. | 17:13 |
| tveronezi | frankban ^ | 17:13 |
| frankban | tveronezi: yes, that should be fixed as well, feel free to do that in your current branch or to make another card | 17:13 |
| frankban | tveronezi: so, to fully understand the problem: express tries to match all urls in order, if the first doesn't match, it proceeds to the second and so on. at the end, it raises a 404. Am I right? | 17:15 |
| tveronezi | Makyo, frankban: thanks for this nice catch. | 17:15 |
| tveronezi | frankban: yeap. | 17:16 |
| frankban | tveronezi: cool. | 17:17 |
| tveronezi | bcsaller: It would be nice if you could check this solution. https://codereview.appspot.com/6853044/diff/1/lib/server.js It is part of the css stuff. frankban and Makyo are already reviewing it, but It would be nice to see if you approve what I did for this particular file, or if you have another alternative. | 17:18 |
| bcsaller | tveronezi: I can take a look soon | 17:19 |
| jovan2 | bcsaller: the number of subordinates is shown on a service block in the graph view - is this number of subordinate services or units? | 17:19 |
| bcsaller | jovan2: I believe its the number of services that subordinate is related to, I can check | 17:23 |
| jovan2 | bcsaller: a related question - how many subordinates might be typical? and maximum? | 17:24 |
| bcsaller | jovan2: 0 is quite common, if they are using them in their deployment 1-3 would be in the normally expected range, there isn't a hard max, but you'll quickly tax your machines if you use too many | 17:25 |
| bcsaller | jovan2: It looks like that number is the count of services related to that subordinate, which makes sense | 17:26 |
| bcsaller | for example "how many things are related to this monitoring service" | 17:26 |
| jovan2 | bcsaller: I guess you are looking at the subordinate block? I'm looking at the little chart icon on the left-hand side of a normal service block. | 17:27 |
| bcsaller | the little 'chart' (and why is that a chart looking thing anyway?) is on the subordinate | 17:28 |
| bcsaller | normal services don't have them | 17:28 |
| jovan2 | bcsaller: see slide 2: https://docs.google.com/a/canonical.com/file/d/0BwhxhFfxY6uqY0FGaDh5RHFMUzA/edit | 17:29 |
| jovan2 | bcsaller: I believe the chart-like thingy is supposed to indicate monitoring | 17:30 |
| bcsaller | jovan2: we don't have any monitoring, also these wireframe you linked seem to predate the visual design work, that chart widget is the block hanging off a subordinate service now | 17:31 |
| bcsaller | jovan2: I put one up at http://uistage.jujucharms.com:8080/ | 17:32 |
| bcsaller | puppet | 17:32 |
| bcsaller | the sparkline is some sort of aspirational element that makes no sense here | 17:32 |
| jovan2 | bcsaller: Ok I see what you've done, but see the second to last slide in the wireframes. | 17:34 |
| bcsaller | jovan2: Ahh, you're saying that normal services should show a count if/when they have subordinates running as well | 17:35 |
| jovan2 | bcsaller: right | 17:35 |
| bcsaller | still shouldn't be a sparkline ;) | 17:35 |
| bcsaller | but yeah, I don't know if there is a card for that yet | 17:35 |
| jovan2 | bcsaller: I think Nick thought subordinates could only be for monitoring purposes. If this is not so, can you give more examples please? | 17:38 |
| jovan2 | bcsaller: if you could email me that would be great, I have to go soon. | 17:38 |
| bcsaller | puppet is a good example, but they can be used in many ways. Sometimes with framework charms they represent the application itself, so for example, if its a django or rails charm, the users application might be the subordinate | 17:39 |
| bcsaller | depending on how the charm was authored it might be the app is a custom charm and the web framework is the subordinate, we don't require it to be any one way. And we don't know about how that is structured | 17:39 |
| bcsaller | jovan2: do you need more? | 17:40 |
| jovan2 | bcsaller: thanks, that's good for now. I might some more questions tomorrow :) | 17:41 |
| bcsaller | np, have a good one | 17:41 |
| bac | Makyo, i looked at staging with firefox and dragging lines around had no perceptible lag. moving service boxes is pretty laggy, though. acceptable, i'd think, but noticeable. | 17:56 |
| Makyo | bac, Yeah. It's still just a speed increase, not a fix. Accessing node attributes in FF is very slow. | 17:59 |
| gary_poster | Makyo, big +1 on your fix for bug 1076413 that you asked for review on. | 18:05 |
| _mup_ | Bug #1076413: Intermittently, svg content div is too wide by 1 pix <juju-ui:Fix Released> < https://launchpad.net/bugs/1076413 > | 18:05 |
| Makyo | \o/ | 18:06 |
| tveronezi | Makyo: The application seems normal in ff. I see no difference from the chromium version. | 18:46 |
| * tveronezi lunch brb | 18:46 | |
| Makyo | tveronezi, Alright, thanks. | 18:46 |
| * tveronezi back | 19:00 | |
| gary_poster | hazmat, in juju-ui. no rush | 19:00 |
| gary_poster | bcsaller, including yours, their are five remaining environment view refactoring cards, right? | 20:25 |
| gary_poster | there | 20:25 |
| bcsaller | sounds right | 20:25 |
| gary_poster | cool bcsaller thanks. I'm sending out a note highlighting them to everyone. They are not specced in the bugs, so I will ask everyone to contact you. If the Europeans can start one, it might be nice to spec one out with writing, or confer with me on a hangout and see if I can do it after a discussion. Per discussion with Kapil, I'm also going to say that (1) we have through next week to get these landed and (2) ea | 20:29 |
| gary_poster | ch one should be landed with tests. I'd like to verify with you if any of the cards are blocked; and if any of them are arguably optional from one perspective or another, without causing significant ugliness/pain. | 20:29 |
| gary_poster | I'd be happy to do that here or in a hangout | 20:29 |
| bcsaller | still might be premature, there are no examples yet, still working on that | 20:29 |
| gary_poster | oh ok | 20:29 |
| gary_poster | can anyone help accelerate that with you bcsaller? I don't know about your experience with pair programming, but with a good combination it really can be a big benefit. | 20:31 |
| bcsaller | makyo and I did ok during the sprint, not sure though | 20:32 |
| gary_poster | ok, leave it up to you bcsaller, though am worried about timeline and the ability of others to help swarm. | 20:33 |
| * gary_poster needs to get children from school | 20:34 | |
| gary_poster | biab | 20:34 |
| bcsaller | gary_poster: I still have the prototype from the sprint which I'm porting to the new framework, so that could possible be a starting point, but I'd rather finish what I have | 20:34 |
| bcsaller | ok, ttyl | 20:34 |
| Makyo | Anyone experienced YUI node.simulate(event) saying "Uncaught TypeError: Cannot read property 'sourceEvent' of null" before? | 20:38 |
| Makyo | This merge didn't even touch that line, and it's breaking. | 20:38 |
| bcsaller | Makyo: Haven't seen that one but I often have unrelated changes break tests | 20:54 |
| gary_poster | no | 20:59 |
| Makyo | Oops, was a d3 thing. d3.mouse was expecting d3.event to be defined. Easy to get around for testing by saying d3.event = {}; | 21:19 |
| * tveronezi brb | 21:42 | |
| * tveronezi back | 21:54 | |
| * Makyo dogwalks | 22:34 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!