Solid.
On Thu, Dec 31, 2009 at 4:56 PM, Brandon Aaron wrote:
> I'm on board with this.
>
> --
> Brandon Aaron
>
> On Thu, Dec 31, 2009 at 2:19 PM, John Resig wrote:
> > I added in jQuery.proxy( obj, name ) support as well (I like this - I
> > also showed how to do it in Secrets of the JavaScript
I'm on board with this.
--
Brandon Aaron
On Thu, Dec 31, 2009 at 2:19 PM, John Resig wrote:
> I added in jQuery.proxy( obj, name ) support as well (I like this - I
> also showed how to do it in Secrets of the JavaScript Ninja:
> http://github.com/jquery/jquery/commit/1d2b1a57dae0b73b3d99197f73f4
I encountered the same problem with 1.3.2 in Safari (latest version,
on OS X 10.6). It seemed to wait to redraw until I moved the mouse
over the element whose class had changed (though I was not
using :hover in any selectors). Everything worked as expected in
Firefox.
Nathan
On Dec 30, 11:48 am,
I added in jQuery.proxy( obj, name ) support as well (I like this - I
also showed how to do it in Secrets of the JavaScript Ninja:
http://github.com/jquery/jquery/commit/1d2b1a57dae0b73b3d99197f73f4edb623b5574a
Any major concerns before I push this through? Will this meet the
needs of everyone in
> Do you have a test page that repeatedly makes ajax calls to exploit
> the memory leak issue?
Yes.
> A .7% increase in memory use doesn't raise any red flags to me, it
> could just be how IE handles the new code differently. You'd have to
> repeat the test many times and watch Drip to see if the
Sounds good.
On Dec 31, 10:01 am, John Resig wrote:
> > Is there any reason you are keeping jQuery.event.proxy around? I
> > didn't see it used anywhere.
>
> Internally it's not used anymore - but considering that we were using
> it in a bunch of places in core, it's very likely that there are a
On Dec 31, 8:53 am, John Resig wrote:
> Looking at the new numbers I see:
> Without patch: 19763200
> With patch: 19910656
> So still about a 1/5MB increase in memory usage.
Do you have a test page that repeatedly makes ajax calls to exploit
the memory leak issue?
A .7% increase in memory use doe
On Dec 31, 2:59 pm, John Resig wrote:
> Both reasonable requests - landed the
> changes:http://github.com/jquery/jquery/commit/6cf981eea20695987b4f7341f80442...
Working fine here. Thank you!
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" grou
> Is there any reason you are keeping jQuery.event.proxy around? I
> didn't see it used anywhere.
Internally it's not used anymore - but considering that we were using
it in a bunch of places in core, it's very likely that there are a
bunch of plugins using it as well. No reason to cause unnecessa
Both reasonable requests - landed the changes:
http://github.com/jquery/jquery/commit/6cf981eea20695987b4f7341f80442a7cf8271eb
Thanks!
--John
On Thu, Dec 31, 2009 at 4:39 AM, candlerb wrote:
> On Dec 31, 3:29 am, John Resig wrote:
>> Umm, hmm - &> is perfectly valid shell - used for redirect
Thanks for the suggestion Matt. Landed it here:
http://github.com/jquery/jquery/commit/6cb2945837ccca55204191a8e7a70b2b2486c28e
Looking at the new numbers I see:
Without patch: 19763200
With patch: 19910656
So still about a 1/5MB increase in memory usage.
--John
On Thu, Dec 31, 2009 at 8:53 A
Is there any reason you are keeping jQuery.event.proxy around? I
didn't see it used anywhere.
On Dec 31, 12:39 am, John Resig wrote:
> So I definitely agree that having a single, one-off, API addition (to
> bind and live) is kind of lame - especially when it conflicts with the
> jQuery way of def
On Dec 30, 10:58 pm, John Resig wrote:
> Interesting, I've, also, seen the = null; proposal before, but not the
> = function(){}; one. Doing some poking around I found mention of it
> here:http://www.ilinsky.com/articles/XMLHttpRequest/#bugs-ie-leak
I haven't inspected the jQuery ajax code much,
I have got a really nasty workaround: the following seems to be
sufficient to 'touch' the affected parts of the DOM. (I used
toggleClass originally, but just removeClass seems sufficient)
--- selection.html 2009-12-30 16:46:12.0 +
+++ selection2.html 2009-12-31 10:23:14.00
At first glance this looks good. I'll switch to this branch and play
around a bit as soon as I get a chance.
On Dec 31, 12:39 am, John Resig wrote:
> So I definitely agree that having a single, one-off, API addition (to
> bind and live) is kind of lame - especially when it conflicts with the
> jQ
On Dec 31, 9:39 am, candlerb wrote:
> The default shell in Ubuntu is dash
More specifically: /bin/sh is a symlink to /bin/dash. So even though
my login shell in /etc/passwd is /bin/bash, it appears that 'make' is
invoking /bin/sh which is actually the more POSIX-like shell.
--
You received this
On Dec 31, 3:29 am, John Resig wrote:
> Umm, hmm - &> is perfectly valid shell - used for redirecting both
> stdout and stderr
> simultaneously:http://www.gnu.org/software/bash/manual/bashref.html#Redirectionshttp://dsl.org/cookbook/cookbook_5.html#SEC57
Yes, but not all shells are bash, and bas
17 matches
Mail list logo
