fluid-work IRC Logs-2008-08-07

Owned by Fluid IRC Log Bot
Last updated: Aug 07, 2008Version comment
5 min read

[07:18:39 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[07:35:33 EDT(-0400)] * apetro-_ (n=apetro@adsl-75-32-40-98.dsl.chcgil.sbcglobal.net) has joined #fluid-work
[08:38:30 EDT(-0400)] * anastasiac (n=stasia@142.150.154.160) has joined #fluid-work
[08:45:56 EDT(-0400)] * jhung (n=Administ@H25.C206.cci.switchworks.net) has joined #fluid-work
[08:46:19 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:35:48 EDT(-0400)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[09:45:27 EDT(-0400)] * Bosmon (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[09:45:37 EDT(-0400)] <Bosmon> ping
[09:50:03 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[09:52:14 EDT(-0400)] * jhung1 (n=Administ@H25.C206.cci.switchworks.net) has joined #fluid-work
[09:53:21 EDT(-0400)] * jhung2 (n=Administ@H25.C206.cci.switchworks.net) has joined #fluid-work
[10:07:41 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[10:18:44 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:21:25 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[10:50:43 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[10:53:37 EDT(-0400)] <Bosmon> Notes for posterity: DOM binder has been upgraded to accept an optional "container" argument when finding
[10:53:47 EDT(-0400)] <Bosmon> Which means it can accommodate the use case that we previously had "ad hoc" for "grabHandle"
[10:54:05 EDT(-0400)] <Bosmon> Currently debating whether this container should be forced to be either a dom node or a jQuery, by the time it reaches the user
[10:57:05 EDT(-0400)] <Bosmon> We have decided with Colin that this should really be a node
[10:57:33 EDT(-0400)] <Bosmon> (15:55:33) Clark Kent: Which is consistent with jQuery's general approach.
[10:57:34 EDT(-0400)] <Bosmon> (15:55:37) Antranig: Is it...
[10:57:34 EDT(-0400)] <Bosmon> (15:55:52) Clark Kent: Yes. Event handlers, for example, get unwrapped elements as argumets.
[10:57:34 EDT(-0400)] <Bosmon> (15:55:55) Clark Kent: arguments
[10:57:34 EDT(-0400)] <Bosmon> (15:55:56) Antranig: ok
[10:57:34 EDT(-0400)] <Bosmon> (15:56:00) Antranig: I wonder why that is...
[10:57:36 EDT(-0400)] <Bosmon> (15:56:11) Antranig: Perhaps, to avoid running the risk of "corrupting" jQueries...
[11:04:44 EDT(-0400)] <colinclark> So here is the convention which I will add to the API style guide...
[11:05:02 EDT(-0400)] <colinclark> 1. Inbound, via use of the DOM Binder, we expect people to specify things using selectors.
[11:05:19 EDT(-0400)] <colinclark> 2. Within our own code, jQueries are the standard currency.
[11:05:37 EDT(-0400)] <colinclark> 3. Outbound, in callbacks and events, we should pass back plain old DOM elements.
[11:06:17 EDT(-0400)] <colinclark> This provides us with the stability of jQuery within our own world, but means we don't required our users to consume jQueries everywhere in their own code.
[11:06:27 EDT(-0400)] <colinclark> And it keeps us basically consistent with the approach jQuery uses.
[11:41:09 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[11:41:39 EDT(-0400)] * davidb (n=davidb@bas4-toronto06-1279310522.dsl.bell.ca) has joined #fluid-work
[11:41:49 EDT(-0400)] <michelled> anastasiac: Bosmon just committed and the Reorderer seems to be running well again. Can you take another look to see if the errors you were seeing are fixed?
[11:42:08 EDT(-0400)] <anastasiac> I just saw the commit email, and was about to do an update and check (smile)
[11:43:43 EDT(-0400)] <anastasiac> michelled, Bosmon - it looks good. Everything seems to work with the manual tests. I'll update the build server
[11:46:15 EDT(-0400)] <davidb> standup
[11:52:17 EDT(-0400)] <davidb> seems breeze barfed
[11:52:39 EDT(-0400)] * davidb (n=davidb@bas4-toronto06-1279310522.dsl.bell.ca) has left #fluid-work
[11:56:11 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-104.LIPS.Berkeley.EDU) has joined #fluid-work
[12:01:41 EDT(-0400)] <Bosmon> OK
[12:01:44 EDT(-0400)] <Bosmon> I have managed to restart breeze
[12:01:48 EDT(-0400)] <Bosmon> Unfortunately everyone is gone (tongue)
[12:03:40 EDT(-0400)] <ecochran> seems a little lonely here too
[12:18:40 EDT(-0400)] <anastasiac> Hm... I think I have to qualify my comment that it's all working now, michelled and Bosmon
[12:19:36 EDT(-0400)] <anastasiac> the lightbox doesn't seem to be working in FF3 on Mac...
[12:19:39 EDT(-0400)] <anastasiac> checking
[12:20:30 EDT(-0400)] <anastasiac> ok - all fine, sorry. I restarted FF, and it's fine
[12:46:07 EDT(-0400)] <Bosmon> Now doing some work on profiling
[12:46:53 EDT(-0400)] <Bosmon> It is hard to trace the exact cause yet, but it seems that our callbacks are most likely gigantically inefficient
[12:47:10 EDT(-0400)] <Bosmon> It would help if we could lay our hands on a profiler which showed the functions which call others...
[12:47:43 EDT(-0400)] <Bosmon> Right now 50% of CPU time is spent within jQuery "curCSS" but it is not yet completely clear why it is
[12:47:58 EDT(-0400)] <Bosmon> Although I suspect a lot of it could be due to our love of DOM-based rather than model-based state detection (tongue)
[12:48:34 EDT(-0400)] <Bosmon> During my "sample drag" there are 830 calls to "droppablePredicate"
[12:49:09 EDT(-0400)] <Bosmon> And 23869 calls to "curCSS" and "color", but it hard to see what (if any) the path is between these two
[12:49:26 EDT(-0400)] <Bosmon> I mean, between the predicate and the base jQuery functions...
[12:52:11 EDT(-0400)] <Bosmon> Hmm.... it may really all be just inside jQuery (sad)
[12:53:58 EDT(-0400)] <Bosmon> OK
[12:54:34 EDT(-0400)] <Bosmon> Yes, there is a loop inside ui.droppable prepareOffsets that consumes CPU proportional to the total number of "droppables" on the page (sad)
[12:54:40 EDT(-0400)] <Bosmon> it issues a jQuery "is" call for wach one
[12:54:48 EDT(-0400)] <Bosmon> For a start telling if it is visible
[12:55:09 EDT(-0400)] <Bosmon> The "is" call by itself consumes 20% of the total CPU
[13:00:19 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[13:01:05 EDT(-0400)] <Bosmon> I think I may have tracked down a configuration option that might make it stop....
[13:01:14 EDT(-0400)] <Bosmon> //If you have a highly dynamic page, you might try this option. It renders positions every time you move the mouse.
[13:01:14 EDT(-0400)] <Bosmon> if(draggable.options.refreshPositions) $.ui.ddmanager.prepareOffsets(draggable, e);
[13:01:14 EDT(-0400)] <Bosmon>
[13:01:26 EDT(-0400)] <Bosmon> At least, might make the 25% of it I have identified so far to stop....
[13:24:10 EDT(-0400)] <Bosmon> OK
[13:24:18 EDT(-0400)] <Bosmon> It seems we are manually setting this to true by ourselves (tongue)
[13:24:50 EDT(-0400)] <Bosmon> Turning it off makes performance unreasonably better
[13:32:47 EDT(-0400)] <ecochran> I have a question... just for my own edification... why are we storing a components defaults in the fluid namespace and not in the components namespace?
[13:33:07 EDT(-0400)] <anastasiac> I actually wondered that myself, ecochran
[13:33:24 EDT(-0400)] <colinclark> ecochran: There's no namespace for a component. They are created through plain old functions living in the fluid namespace.
[13:33:41 EDT(-0400)] <colinclark> It's unfortunately not safe to drop extra methods on a Function.
[13:33:47 EDT(-0400)] <colinclark> So we store them centrally by name.
[13:34:13 EDT(-0400)] <ecochran> what do you mean by "drop extra methods"?
[13:34:49 EDT(-0400)] <colinclark> Sorry, I meant "drop extra objects" into a Function.
[13:36:03 EDT(-0400)] <colinclark> It's risky to do this:
[13:36:06 EDT(-0400)] <colinclark> function foo() {
[13:36:06 EDT(-0400)] <colinclark> // create the foo component
[13:36:06 EDT(-0400)] <colinclark> };
[13:36:06 EDT(-0400)] <colinclark> foo.defaults = {
[13:36:07 EDT(-0400)] <colinclark> // foo's defaults.
[13:36:07 EDT(-0400)] <colinclark> };
[13:36:19 EDT(-0400)] <colinclark> So we store defaults centrally in the fluid object.
[13:36:31 EDT(-0400)] <michelled> Bosmon: I can't remember why we turned on refreshPositions but I know it was because of a bug.
[13:37:02 EDT(-0400)] <michelled> I hope Justin's test plans will catch it if we regress - oh how I want automated tests for drag and drop.
[13:38:59 EDT(-0400)] <ecochran> colinclark: makes sense...
[14:30:23 EDT(-0400)] <Bosmon> OK
[14:30:50 EDT(-0400)] <Bosmon> So I am thinking this "fake drop indicators" phenomenon is really because our policy inside dndFunctions.findTarget cannot be right
[14:31:12 EDT(-0400)] <Bosmon> It always considers that the drop target is the "last target" if the event is for the avatar
[14:31:33 EDT(-0400)] <Bosmon> Which really means it is pretty brainless in the case where the mouse moves beyond the region where there are any drop targets
[14:35:32 EDT(-0400)] * jhung (n=Administ@H25.C206.cci.switchworks.net) has joined #fluid-work
[14:36:53 EDT(-0400)] * jhung (n=Administ@H25.C206.cci.switchworks.net) has joined #fluid-work
[15:10:00 EDT(-0400)] * theclown_ (n=theclown@142.150.154.101) has joined #fluid-work
[15:10:48 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[16:00:00 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[16:47:07 EDT(-0400)] * michelled (n=team@142.150.154.197) has left #fluid-work