Nabble - MochiKit

JSON.parse & MochiKit.Base.evalJSON

2009-11-28T14:18:38Z

I just tried to modify MochiKit.Base.evalJSON() to use the new
JSON.parse() function when available. This would give us the following
advantages:

1. Speed (but, well... eval() is probably fast enough already)
2. Security

Unfortunately we would also get a nasty regression issue due to the
stricter syntax enforcement in JSON.parse() vs. eval(). It seems that
at least the Firefox parser doesn't accept constructs like these:

{ a: 1 }

since the correct JSON syntax would be:

{ "a": 1 }

Hmm... So what to do? Just skip this altogether? And add a note in the
docs that people should use JSON.parse() themselves if worried about
security or speed?

Any thoughts are welcome.

Cheers,

/Per

--

You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@....
To unsubscribe from this group, send email to mochikit+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.

Google Closure includes MochiKit

2009-11-05T15:54:32Z

Hi,

Google recently announced their core javascript library - Closure.
http://code.google.com/closure/library/

When browsing the code I noticed it uses parts of MochiKit:
http://code.google.com/p/closure-library/source/browse/trunk/closure/goog/dom/dom.js
http://code.google.com/p/closure-library/source/browse/#svn/trunk/third_party/closure/goog/mochikit/async
There's also very similar bind, partial, array utils, an iter module
etc.

Overall the style is similar, i.e functional, Python.
Apparently they've got good taste in Mountain View :)

Regards
// Fredrik Blomqvist
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: MochiKit.DOM.getElementsByTagAndClassName performance

2009-11-05T13:42:41Z

On Nov 5, 2009, at 1:32 AM, Fredrik wrote:

>
> I created a getElementsByClassName based on this code:
> http://robertnyman.com/2008/05/27/the-ultimate-getelementsbyclassname-anno-2008/
> http://code.google.com/p/getelementsbyclassname/
>
> Pending a full selector integration something like this should be an
> easy drop-in
> solution to optimize getElementsByTagAndClassName.
> (IE really needs some speedup here..)
>
> // Fredrik Blomqvist
>
> On Nov 5, 7:45 am, Amit Mendapara <mendapara.a...@...> wrote:
>> Look at my mochikit-ext project athttps://launchpad.net/mochikit-ext.
>> I have implemented a jQuery style API in MochiKit.Query module
>> (http://
>> bazaar.launchpad.net/~amit-mendapara/mochikit-ext/trunk/files) which
>> is based on Sizzle.js (http://github.com/jeresig/sizzle).
>>
>> MochiKit.DOM.getElementsByTagAndClassName("div", "some-class")
>>
>> can be replaced with
>>
>> MochiKit.Query("div.some-class").get()
>>
>> The Sizzle.js is the fastest selector engine out there. Seehttp://www.hvergi.net/arnar/public/sizzle/speed/#for
>> the speed tests.

Actually, it's not. The Acme engine in Dojo beats it by a fair bit on
most real-world selectors. It's stand-alone and can be easily imported
(like Sizzle).

Regards

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: MochiKit.DOM.getElementsByTagAndClassName performance

2009-11-05T01:32:21Z

I created a getElementsByClassName based on this code:
http://robertnyman.com/2008/05/27/the-ultimate-getelementsbyclassname-anno-2008/
http://code.google.com/p/getelementsbyclassname/

Pending a full selector integration something like this should be an
easy drop-in
solution to optimize getElementsByTagAndClassName.
(IE really needs some speedup here..)

// Fredrik Blomqvist

On Nov 5, 7:45 am, Amit Mendapara <mendapara.a...@...> wrote:

> Look at my mochikit-ext project athttps://launchpad.net/mochikit-ext.
> I have implemented a jQuery style API in MochiKit.Query module (http://
> bazaar.launchpad.net/~amit-mendapara/mochikit-ext/trunk/files) which
> is based on Sizzle.js (http://github.com/jeresig/sizzle).
>
> MochiKit.DOM.getElementsByTagAndClassName("div", "some-class")
>
> can be replaced with
>
> MochiKit.Query("div.some-class").get()
>
> The Sizzle.js is the fastest selector engine out there. Seehttp://www.hvergi.net/arnar/public/sizzle/speed/#for the speed tests.
>
> Regards
> --
> Amit Mendapara
>
> On Nov 4, 9:22 pm, Bob Ippolito <b...@...> wrote:
>
> > At least with recent browsers there are better ways to speed this up,
> > e.g. by leveraging more native code (getElementsByClassName and/or
> > XPath). None of them did this when the code was written in 2005 but I
> > think all of them do now (except maybe IE).
>
> > On Tue, Nov 3, 2009 at 11:14 PM, Per Cederberg <cederb...@...> wrote:
>
> > > Generally, I think some of these optimizations make sense. Like using
> > > "===" instead of "==" in code like this:
>
> > > typeof(x) === "string"
>
> > > But I think the optimizations where variables are moved outside code
> > > blocks and where array lengths are stored to variables should be used
> > > with extreme caution. These are the type of things that people used to
> > > recommend for Java code, but nowadays the virtual machines optimize
> > > these things better by themselves. And what used to be a speedup
> > > actually often leads to decreased performance.
>
> > > For JavaScript, the VM:s are much more immature. But they are rapidly
> > > becoming faster and more advanced. So low-level code optimizations
> > > that result in a speedup today, might not do so just a year or two
> > > down the road.
>
> > > I think our focus here should be on clarity of intention. If some
> > > critical-path function is extremely slow, we might want to have a look
> > > at optimizing that specific function. But in general I think we should
> > > refrain from low-level code optimizations that doesn't also improve
> > > code readabilty and reduce the frequency of bugs.
>
> > > Also, if speed is a problem, most serious speedups come from changes
> > > to the algorithms and data structures involved. In this case for
> > > instance, it might be faster to first find elements by class and then
> > > filter out the ones with the correct tag. Or by using an
> > > indexOf("class") on the className field before splitting it up. These
> > > kind of optimizations will probably result in higher gains with less
> > > reduction to the code readability.
>
> > > Just my 2 cents.
>
> > > Cheers,
>
> > > /Per
>
> > > On Tue, Nov 3, 2009 at 23:23, takashi mizohata <bea...@...> wrote:
> > >> Hi All,
>
> > >> Forgive me, if this is a recurring argument.
>
> > >> Today I was looking at Firebug profiler and I realize that
> > >> getElementsByTagAndClassName takes certain percentages of processing
> > >> time. And I took a look at the code, and I did a little bit of hand
> > >> optimization. It doesn't change any semantics of code, but just
> > >> organizing code. It does pass the tests of course. And i got around
> > >> 6% better performance.
>
> > >> Well the down side of this tweak may be the decrease of readability.
> > >> Since you need to carefully type comma between local variables. I
> > >> usually check it with jslint before commit in order to find those
> > >> potential mistakes. And obviously I don't much about coding
> > >> convention of MochiKit and I might need to edit the style of it.
>
> > >> Here I attached .patch file for this issue. Please try it and let me
> > >> know what you think. if somebody's interested in, I can contribute
> > >> some more performance tweaks in MochiKit.
>
> > >> Thanks,
>
> > >> --
> > >> Takashi M
>
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: MochiKit.DOM.getElementsByTagAndClassName performance

2009-11-04T22:45:39Z

Look at my mochikit-ext project at https://launchpad.net/mochikit-ext.
I have implemented a jQuery style API in MochiKit.Query module (http://
bazaar.launchpad.net/~amit-mendapara/mochikit-ext/trunk/files) which
is based on Sizzle.js (http://github.com/jeresig/sizzle).

MochiKit.DOM.getElementsByTagAndClassName("div", "some-class")

can be replaced with

MochiKit.Query("div.some-class").get()

The Sizzle.js is the fastest selector engine out there. See
http://www.hvergi.net/arnar/public/sizzle/speed/# for the speed tests.

Regards
--
Amit Mendapara

On Nov 4, 9:22 pm, Bob Ippolito <b...@...> wrote:

> At least with recent browsers there are better ways to speed this up,
> e.g. by leveraging more native code (getElementsByClassName and/or
> XPath). None of them did this when the code was written in 2005 but I
> think all of them do now (except maybe IE).
>
> On Tue, Nov 3, 2009 at 11:14 PM, Per Cederberg <cederb...@...> wrote:
>
> > Generally, I think some of these optimizations make sense. Like using
> > "===" instead of "==" in code like this:
>
> > typeof(x) === "string"
>
> > But I think the optimizations where variables are moved outside code
> > blocks and where array lengths are stored to variables should be used
> > with extreme caution. These are the type of things that people used to
> > recommend for Java code, but nowadays the virtual machines optimize
> > these things better by themselves. And what used to be a speedup
> > actually often leads to decreased performance.
>
> > For JavaScript, the VM:s are much more immature. But they are rapidly
> > becoming faster and more advanced. So low-level code optimizations
> > that result in a speedup today, might not do so just a year or two
> > down the road.
>
> > I think our focus here should be on clarity of intention. If some
> > critical-path function is extremely slow, we might want to have a look
> > at optimizing that specific function. But in general I think we should
> > refrain from low-level code optimizations that doesn't also improve
> > code readabilty and reduce the frequency of bugs.
>
> > Also, if speed is a problem, most serious speedups come from changes
> > to the algorithms and data structures involved. In this case for
> > instance, it might be faster to first find elements by class and then
> > filter out the ones with the correct tag. Or by using an
> > indexOf("class") on the className field before splitting it up. These
> > kind of optimizations will probably result in higher gains with less
> > reduction to the code readability.
>
> > Just my 2 cents.
>
> > Cheers,
>
> > /Per
>
> > On Tue, Nov 3, 2009 at 23:23, takashi mizohata <bea...@...> wrote:
> >> Hi All,
>
> >> Forgive me, if this is a recurring argument.
>
> >> Today I was looking at Firebug profiler and I realize that
> >> getElementsByTagAndClassName takes certain percentages of processing
> >> time. And I took a look at the code, and I did a little bit of hand
> >> optimization. It doesn't change any semantics of code, but just
> >> organizing code. It does pass the tests of course. And i got around
> >> 6% better performance.
>
> >> Well the down side of this tweak may be the decrease of readability.
> >> Since you need to carefully type comma between local variables. I
> >> usually check it with jslint before commit in order to find those
> >> potential mistakes. And obviously I don't much about coding
> >> convention of MochiKit and I might need to edit the style of it.
>
> >> Here I attached .patch file for this issue. Please try it and let me
> >> know what you think. if somebody's interested in, I can contribute
> >> some more performance tweaks in MochiKit.
>
> >> Thanks,
>
> >> --
> >> Takashi M

Re: MochiKit.DOM.getElementsByTagAndClassName performance

2009-11-04T08:22:12Z

At least with recent browsers there are better ways to speed this up,
e.g. by leveraging more native code (getElementsByClassName and/or
XPath). None of them did this when the code was written in 2005 but I
think all of them do now (except maybe IE).

On Tue, Nov 3, 2009 at 11:14 PM, Per Cederberg <cederberg@...> wrote:

>
> Generally, I think some of these optimizations make sense. Like using
> "===" instead of "==" in code like this:
>
> typeof(x) === "string"
>
> But I think the optimizations where variables are moved outside code
> blocks and where array lengths are stored to variables should be used
> with extreme caution. These are the type of things that people used to
> recommend for Java code, but nowadays the virtual machines optimize
> these things better by themselves. And what used to be a speedup
> actually often leads to decreased performance.
>
> For JavaScript, the VM:s are much more immature. But they are rapidly
> becoming faster and more advanced. So low-level code optimizations
> that result in a speedup today, might not do so just a year or two
> down the road.
>
> I think our focus here should be on clarity of intention. If some
> critical-path function is extremely slow, we might want to have a look
> at optimizing that specific function. But in general I think we should
> refrain from low-level code optimizations that doesn't also improve
> code readabilty and reduce the frequency of bugs.
>
> Also, if speed is a problem, most serious speedups come from changes
> to the algorithms and data structures involved. In this case for
> instance, it might be faster to first find elements by class and then
> filter out the ones with the correct tag. Or by using an
> indexOf("class") on the className field before splitting it up. These
> kind of optimizations will probably result in higher gains with less
> reduction to the code readability.
>
> Just my 2 cents.
>
> Cheers,
>
> /Per
>
> On Tue, Nov 3, 2009 at 23:23, takashi mizohata <beatak@...> wrote:
>> Hi All,
>>
>> Forgive me, if this is a recurring argument.
>>
>> Today I was looking at Firebug profiler and I realize that
>> getElementsByTagAndClassName takes certain percentages of processing
>> time. And I took a look at the code, and I did a little bit of hand
>> optimization. It doesn't change any semantics of code, but just
>> organizing code. It does pass the tests of course. And i got around
>> 6% better performance.
>>
>> Well the down side of this tweak may be the decrease of readability.
>> Since you need to carefully type comma between local variables. I
>> usually check it with jslint before commit in order to find those
>> potential mistakes. And obviously I don't much about coding
>> convention of MochiKit and I might need to edit the style of it.
>>
>> Here I attached .patch file for this issue. Please try it and let me
>> know what you think. if somebody's interested in, I can contribute
>> some more performance tweaks in MochiKit.
>>
>> Thanks,
>>
>> --
>> Takashi M
>>
>> >
>>
>
> >
>

Re: MochiKit.DOM.getElementsByTagAndClassName performance

2009-11-03T23:14:04Z

Generally, I think some of these optimizations make sense. Like using
"===" instead of "==" in code like this:

typeof(x) === "string"

But I think the optimizations where variables are moved outside code
blocks and where array lengths are stored to variables should be used
with extreme caution. These are the type of things that people used to
recommend for Java code, but nowadays the virtual machines optimize
these things better by themselves. And what used to be a speedup
actually often leads to decreased performance.

For JavaScript, the VM:s are much more immature. But they are rapidly
becoming faster and more advanced. So low-level code optimizations
that result in a speedup today, might not do so just a year or two
down the road.

I think our focus here should be on clarity of intention. If some
critical-path function is extremely slow, we might want to have a look
at optimizing that specific function. But in general I think we should
refrain from low-level code optimizations that doesn't also improve
code readabilty and reduce the frequency of bugs.

Also, if speed is a problem, most serious speedups come from changes
to the algorithms and data structures involved. In this case for
instance, it might be faster to first find elements by class and then
filter out the ones with the correct tag. Or by using an
indexOf("class") on the className field before splitting it up. These
kind of optimizations will probably result in higher gains with less
reduction to the code readability.

Just my 2 cents.

Cheers,

/Per

On Tue, Nov 3, 2009 at 23:23, takashi mizohata <beatak@...> wrote:

> Hi All,
>
> Forgive me, if this is a recurring argument.
>
> Today I was looking at Firebug profiler and I realize that
> getElementsByTagAndClassName takes certain percentages of processing
> time. And I took a look at the code, and I did a little bit of hand
> optimization. It doesn't change any semantics of code, but just
> organizing code. It does pass the tests of course. And i got around
> 6% better performance.
>
> Well the down side of this tweak may be the decrease of readability.
> Since you need to carefully type comma between local variables. I
> usually check it with jslint before commit in order to find those
> potential mistakes. And obviously I don't much about coding
> convention of MochiKit and I might need to edit the style of it.
>
> Here I attached .patch file for this issue. Please try it and let me
> know what you think. if somebody's interested in, I can contribute
> some more performance tweaks in MochiKit.
>
> Thanks,
>
> --
> Takashi M
>
> >
>

MochiKit.DOM.getElementsByTagAndClassName performance

2009-11-03T14:23:09Z

Hi All,

Forgive me, if this is a recurring argument.

Today I was looking at Firebug profiler and I realize that
getElementsByTagAndClassName takes certain percentages of processing
time. And I took a look at the code, and I did a little bit of hand
optimization. It doesn't change any semantics of code, but just
organizing code. It does pass the tests of course. And i got around
6% better performance.

Well the down side of this tweak may be the decrease of readability.
Since you need to carefully type comma between local variables. I
usually check it with jslint before commit in order to find those
potential mistakes. And obviously I don't much about coding
convention of MochiKit and I might need to edit the style of it.

Here I attached .patch file for this issue. Please try it and let me
know what you think. if somebody's interested in, I can contribute
some more performance tweaks in MochiKit.

Thanks,

--
Takashi M

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

getElementsByTagAndClassName.patch (2K) Download Attachment

Lets flirt or...

2009-09-25T00:16:49Z

Hello to this group, Im newbie here.
Life is boring and uninteresting, entertain me :)

Lets flirt or maybe something more?
Im here:
http://camelliaelfr.150m.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: MochiTAL

2009-08-01T12:22:15Z

I can't answer the question directly about MochiTAL, but when I saw
MochiTAL more than a year ago I decided to write a more complete
implementation of TAL in javascript called jstal.

I have combined jstal with an XSLT implementation (tal2xslt) into a
single package ATALi (Alternate TAL Implementations) which you can
find at https://launchpad.net/atali

(apache license)

Hmm, there's no docs and no examples, so this post is probably wasting
your time.

I use both jstal and tal2xslt every day in production. I really need
to finish this project up.

Is anyone interested?

The one thing that is holding me up is lack of tests. I need a good
xml diff tool so I can write tests for tal2xslt, and I would need
something similar for jstal in javascript. (rhino?)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

MochiTAL

2009-07-30T08:55:31Z

Hi,

I am new to JavaScript and to Mochikit, but I've seen enough of it
(Mochikit) to get very much interested about it. I am currently
looking into the Ajax Tables example from the Mochikit web site, and I
have to confess that I am a little bit confused about the MochiTAL
processing. So, I thought I'd drop a line to check if anyone is kind
enough to help understand what happens behind the scenes.
I'm particularly confused about the valueForKeyPath processing
which take as parameter the 'domains' string from mochi:repeat
property, if I got it right... So, "name" will receive the value
'item' but I can't get what values will be returned to 'lst' in the
example.
I am sorry if this sounds basic, and do appreciate any support.

Cheers,
ss.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Defered.setFinal

2009-07-25T15:51:59Z

Hello all,

On Tue, Feb 10, 2009 at 6:48 PM, Bob Ippolito<bob@...> wrote:
>
> Finalizing a Deferred should ensure that no further callback/errbacks
> are registered and it should attach a default error handler (success
> should be no-op). The most common problem I've seen with Deferreds is
> that an error occurs but nobody attached an error handler that far
> down the stack. [...]

In order to handle this case, we have overwrote the 'callback' method
in our subclass of the Deferred class, to add a default Errback that
at least logs the error.

A similar solution could be probably used also in MochiKit, allowing
the user to optionally specify a specific error handler / finalizer.
This will allow any further check, as once the Deferred is triggered
it is already impossible to add further callback/errback.

I will check anyway the fix added to the repository to see how to
improve our current extension with the committed fix.

Giulio Cesare

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Ticket #352: Adding MochiKit.DateTime.toISOTime arguments to the API

2009-07-21T00:41:22Z

In ticket #352 the realISO parameter in the
MochiKit.DateTime.toISOTime() function is discussed:

http://trac.mochikit.com/ticket/352

It was introduced by Bob in r377 (some 4 years ago), but never added
to the documentation or the official API:

http://trac.mochikit.com/changeset/377

Is it time that we now add it? Or is it just one of those hacks that
we should just hide away? Opinons?

Cheers,

/Per

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Defered.setFinal

2009-07-20T03:03:55Z

Hi Per,

I have just tested the changes with the Ajax extension module and it
works as expected. Thanks for considering adding this feature. This
would help me creating jQuery compatible Ajax module for Mochikit
extensions project.

Currently, I'm quite busy with some another work but supposed to come
back on MochiKit Extensions soon...

Regards
--
Amit Mendapara

On Jul 20, 2:26 pm, Per Cederberg <cederb...@...> wrote:

> Slow response here, but I finally got around to committing this to
> Subversion (r1533):
>
> http://trac.mochikit.com/changeset/1533
>
> Modified the patch a bit further to account for some additional cases.
> Also added tests and documentation.
>
> @Bob: Can you please review this change? I have the feeling that I've
> still missed one or two corner cases... Also, the mochikit.com and
> trac.mochikit.com site seems slow from here... High server load
> recently?
>
> @Amit: Please check that my additional controls doesn't break you use case.
>
> Cheers,
>
> /Per
>
> On Wed, Feb 11, 2009 at 14:52, Amit Mendapara<mendapara.a...@...> wrote:
>
> > Even better...
>
> > if (this.chain.length == 0 && this._finalizer) {
> > this._finalized = this._finalizer(res);
> > }
>
> > This will allow us to finalize the deferred based on some
> > conditions...
>
> > - Amit
>
> > On Feb 11, 12:52 am, Per Cederberg <cederb...@...> wrote:
> >> You mean like this?
>
> >> setFinalizer: function(cb) {
> >> this._finalizer = cb;
> >> }
>
> >> ...
>
> >> if (this.chain.length == 0 && this._finalizer) {
> >> this.finalized = true;
> >> if (res instanceof Error) {
> >> this._finalizer(res);
> >> }
> >> }
>
> >> Would that be acceptable to Amit as well? In that case we would add a
> >> default error handler (called a "finalizer"), which would also be what
> >> I'm planning to use this for.
>
> >> Other opinions?
>
> >> /Per
>
> >> On Tue, Feb 10, 2009 at 5:48 PM, Bob Ippolito <b...@...> wrote:
> >> > Finalizing a Deferred should ensure that no further callback/errbacks
> >> > are registered and it should attach a default error handler (success
> >> > should be no-op). The most common problem I've seen with Deferreds is
> >> > that an error occurs but nobody attached an error handler that far
> >> > down the stack. In Python they work around this by having a finalizer
> >> > so that you see the error when the object gets GC'ed, but that's not
> >> > really possible in JS since you don't have finalizers or weak
> >> > references.
>
> >> > On Tue, Feb 10, 2009 at 8:04 AM, Per Cederberg <cederb...@...> wrote:
>
> >> >> I think this is a good idea. I needed something similar too, so I
> >> >> ended up writing an ugly hack that worked most of the time...
>
> >> >> d.addBoth(function (res) {d.addBoth(finalFunc); return res; });
>
> >> >> It adds new callback once the first deferred result drops in,
> >> >> hopefully after all the other callbacks have been added...
>
> >> >> But a more formally correct solution would probably be a good idea.
>
> >> >> Cheers,
>
> >> >> /Per
>
> >> >> On Tue, Feb 10, 2009 at 2:30 PM, Amit Mendapara
> >> >> <mendapara.a...@...> wrote:
> >> >>> Hi Per,
>
> >> >>> I have just started again improving the MochiKit Extensions. While
> >> >>> creating tests for the Ajax module, I found one problem (not bug, but
> >> >>> specific to the feature I'm trying to implement). I registered a
> >> >>> callback which should be fired at the end of all registered callbacks.
>
> >> >>> I achieved by modifying Async.js with a new method `setFinal` (not
> >> >>> addFinal as there should be only one finalizer) which gets fired when
> >> >>> `chain.length == 0`. It's simple. I would we happy if you add one such
> >> >>> function in MochiKit.Async.Defered...
>
> >> >>> Regards
> >> >>> --
> >> >>> Amit

Re: Defered.setFinal

2009-07-20T02:26:12Z

Slow response here, but I finally got around to committing this to
Subversion (r1533):

http://trac.mochikit.com/changeset/1533

Modified the patch a bit further to account for some additional cases.
Also added tests and documentation.

@Bob: Can you please review this change? I have the feeling that I've
still missed one or two corner cases... Also, the mochikit.com and
trac.mochikit.com site seems slow from here... High server load
recently?

@Amit: Please check that my additional controls doesn't break you use case.

Cheers,

/Per

On Wed, Feb 11, 2009 at 14:52, Amit Mendapara<mendapara.amit@...> wrote:

>
> Even better...
>
> if (this.chain.length == 0 && this._finalizer) {
> this._finalized = this._finalizer(res);
> }
>
> This will allow us to finalize the deferred based on some
> conditions...
>
> - Amit
>
> On Feb 11, 12:52 am, Per Cederberg <cederb...@...> wrote:
>> You mean like this?
>>
>> setFinalizer: function(cb) {
>> this._finalizer = cb;
>> }
>>
>> ...
>>
>> if (this.chain.length == 0 && this._finalizer) {
>> this.finalized = true;
>> if (res instanceof Error) {
>> this._finalizer(res);
>> }
>> }
>>
>> Would that be acceptable to Amit as well? In that case we would add a
>> default error handler (called a "finalizer"), which would also be what
>> I'm planning to use this for.
>>
>> Other opinions?
>>
>> /Per
>>
>> On Tue, Feb 10, 2009 at 5:48 PM, Bob Ippolito <b...@...> wrote:
>> > Finalizing a Deferred should ensure that no further callback/errbacks
>> > are registered and it should attach a default error handler (success
>> > should be no-op). The most common problem I've seen with Deferreds is
>> > that an error occurs but nobody attached an error handler that far
>> > down the stack. In Python they work around this by having a finalizer
>> > so that you see the error when the object gets GC'ed, but that's not
>> > really possible in JS since you don't have finalizers or weak
>> > references.
>>
>> > On Tue, Feb 10, 2009 at 8:04 AM, Per Cederberg <cederb...@...> wrote:
>>
>> >> I think this is a good idea. I needed something similar too, so I
>> >> ended up writing an ugly hack that worked most of the time...
>>
>> >> d.addBoth(function (res) {d.addBoth(finalFunc); return res; });
>>
>> >> It adds new callback once the first deferred result drops in,
>> >> hopefully after all the other callbacks have been added...
>>
>> >> But a more formally correct solution would probably be a good idea.
>>
>> >> Cheers,
>>
>> >> /Per
>>
>> >> On Tue, Feb 10, 2009 at 2:30 PM, Amit Mendapara
>> >> <mendapara.a...@...> wrote:
>> >>> Hi Per,
>>
>> >>> I have just started again improving the MochiKit Extensions. While
>> >>> creating tests for the Ajax module, I found one problem (not bug, but
>> >>> specific to the feature I'm trying to implement). I registered a
>> >>> callback which should be fired at the end of all registered callbacks.
>>
>> >>> I achieved by modifying Async.js with a new method `setFinal` (not
>> >>> addFinal as there should be only one finalizer) which gets fired when
>> >>> `chain.length == 0`. It's simple. I would we happy if you add one such
>> >>> function in MochiKit.Async.Defered...
>>
>> >>> Regards
>> >>> --
>> >>> Amit
> >
>

Re: Base.js unescape reassignment and intrusion protection systems

2009-07-19T18:59:27Z

Thanks Per for your analysis. I think your suggestion will work. Who
will try it? I am not a MochiKit user directly. I'm a MarkMail user
who investigated why he can't view articles at work.

At work I am getting an exception made to allow JavaScript from
markmail.org. But that doesn't help anyone else wanting to use a site
using MochiKit inside a similarly-protected environment.

The IDS information I have is that a Proventia device scans JavaScript
files. It truncates any that contain a reassignment of the unescape()
function to a variable because that is considered a vulnerability. I
have tested at work with a minimal JavaScript file and found that
Per's suggested modification is not blocked.

—Michael

On Jul 17, 4:07 pm, Per Cederberg <cederb...@...> wrote:

> Now that I'm awake, it strikes me that this might be the obvious solution:
>
> function decode(text) {
> if (typeof(decodeURIComponent) != "undefined") {
> return decodeURIComponent(text);
> } else {
> return unescape(text);
> }
> }
>
> Try to patch it in a repackage the source code and let us know how it
> works. It's slightly less efficient code, but we might optimize some
> of that away if it works.
>
> Cheers,
>
> /Per
>
>
>
> On Fri, Jul 17, 2009 at 05:19, Bob Ippolito<b...@...> wrote:
>
> > There are various ways it could be rewritten, but without knowing
> > exactly how stupid the IPS is it's hard to say which permutation would
> > pass its test. Someone who can reproduce this issue should spend some
> > time with it and produce a patch.
>
> > On Thu, Jul 16, 2009 at 6:34 PM, Michael<mstras...@...> wrote:
>
> >> I have found a problem with MochiKit Base.js and the intrusion
> >> protection system at work. The IPS truncates Base.js because it
> >> assigns the unescape() function to a variable (in parseQueryString(),
> >> line 1225 in version 1.4.2 of Base.js). The IPS response is documented
> >> here:
>
> >>http://www.iss.net/security_center/reference/vuln/JavaScript_Unescape...
>
> >> Has anybody else seen this behaviour? Could the code be re-written to
> >> not use that reassignment?
>
> >> (I discovered this because MarkMail does not work, and it uses a
> >> compressed version of MochiKit 1.4.)

Re: Base.js unescape reassignment and intrusion protection systems

2009-07-16T23:07:12Z

Now that I'm awake, it strikes me that this might be the obvious solution:

function decode(text) {
if (typeof(decodeURIComponent) != "undefined") {
return decodeURIComponent(text);
} else {
return unescape(text);
}
}

Try to patch it in a repackage the source code and let us know how it
works. It's slightly less efficient code, but we might optimize some
of that away if it works.

Cheers,

/Per

On Fri, Jul 17, 2009 at 05:19, Bob Ippolito<bob@...> wrote:

>
> There are various ways it could be rewritten, but without knowing
> exactly how stupid the IPS is it's hard to say which permutation would
> pass its test. Someone who can reproduce this issue should spend some
> time with it and produce a patch.
>
> On Thu, Jul 16, 2009 at 6:34 PM, Michael<mstrasser@...> wrote:
>>
>> I have found a problem with MochiKit Base.js and the intrusion
>> protection system at work. The IPS truncates Base.js because it
>> assigns the unescape() function to a variable (in parseQueryString(),
>> line 1225 in version 1.4.2 of Base.js). The IPS response is documented
>> here:
>>
>> http://www.iss.net/security_center/reference/vuln/JavaScript_Unescape_Obfuscation.htm
>>
>> Has anybody else seen this behaviour? Could the code be re-written to
>> not use that reassignment?
>>
>>
>> (I discovered this because MarkMail does not work, and it uses a
>> compressed version of MochiKit 1.4.)
>>
>>
>> >
>>
>
> >
>

Re: Base.js unescape reassignment and intrusion protection systems

2009-07-16T20:19:26Z

There are various ways it could be rewritten, but without knowing
exactly how stupid the IPS is it's hard to say which permutation would
pass its test. Someone who can reproduce this issue should spend some
time with it and produce a patch.

On Thu, Jul 16, 2009 at 6:34 PM, Michael<mstrasser@...> wrote:

>
> I have found a problem with MochiKit Base.js and the intrusion
> protection system at work. The IPS truncates Base.js because it
> assigns the unescape() function to a variable (in parseQueryString(),
> line 1225 in version 1.4.2 of Base.js). The IPS response is documented
> here:
>
> http://www.iss.net/security_center/reference/vuln/JavaScript_Unescape_Obfuscation.htm
>
> Has anybody else seen this behaviour? Could the code be re-written to
> not use that reassignment?
>
>
> (I discovered this because MarkMail does not work, and it uses a
> compressed version of MochiKit 1.4.)
>
>
> >
>

Re: Base.js unescape reassignment and intrusion protection systems

2009-07-16T20:18:35Z

The reassignment is for backwards compability if I understand it correctly:

if (typeof(decodeURIComponent) != "undefined") {
decode = decodeURIComponent;
} else {
decode = unescape;
}

From the JavaScript 1.5 guide at Mozilla:

The escape and unescape functions do not work properly for non-ASCII
characters and have been deprecated. In JavaScript 1.5 and later, use
encodeURI, decodeURI, encodeURIComponent, and decodeURIComponent.

https://developer.mozilla.org/En/Core_JavaScript_1.5_Guide/Predefined_Functions/Escape_and_unescape_Functions

I don't see any good alternative solutions here. Perhaps the IDS
should be forced to allow a few exceptions?

Cheers,

/Per

On Fri, Jul 17, 2009 at 03:34, Michael<mstrasser@...> wrote:

Base.js unescape reassignment and intrusion protection systems

2009-07-16T18:34:17Z

I have found a problem with MochiKit Base.js and the intrusion
protection system at work. The IPS truncates Base.js because it
assigns the unescape() function to a variable (in parseQueryString(),
line 1225 in version 1.4.2 of Base.js). The IPS response is documented
here:

http://www.iss.net/security_center/reference/vuln/JavaScript_Unescape_Obfuscation.htm

Has anybody else seen this behaviour? Could the code be re-written to
not use that reassignment?

(I discovered this because MarkMail does not work, and it uses a
compressed version of MochiKit 1.4.)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Error running tests with Opera 10

2009-07-11T12:30:07Z

Hello Per,

I agree with you about trying to avoid work-arounds; but I haven't
found any way to report a 'simple' Javascript issue to Opera itself.

I have investigated if the problem is caused by a different toString()
implementation, but I don't think so, as the extra stack info is
appended to the 'name' and 'message' extension property also.

Giulio Cesare

On Sat, Jul 11, 2009 at 8:57 PM, Per Cederberg<cederberg@...> wrote:

>
> This is the type of stuff one would rather not add to work-arounds in
> the JavaScript code. Don't understand why Opera can't add stacktraces
> as separate properties to their exception objects instead? Or is it
> just that they've modified the toString() implementation?
>
> Cheers,
>
> /Per
>
> On Sat, Jul 11, 2009 at 18:57, Giulio Cesare
> Solaroli<giulio.cesare@...> wrote:
>>
>> Hello,
>>
>> I was having some issues running Clipperz test suite with Opera 10.
>>
>> Looking closer at the failed tests, I have find out that Opera 10 is
>> returning a messed up name and description for Exceptions.
>>
>> This problem is triggered also running the default MochiKit tests; in
>> MochiKit.Async test actually.
>> The test expects an error with message "foo"
>> (test_MochiKit-Async.html, line 300; trunk version 1525), but the
>> actual value is "foo\r\nstacktrace: n/a; see
>> opera:config#UserPrefs|Exceptions Have Stacktrace".
>>
>> Opera 10 is appending some extra values to the exception message,
>> screwing up the test; in my case, it alters the behaviour of the whole
>> application, as some execution paths are based on the value of the
>> returned error name.
>>
>> Any idea on how to fix this problem? or just report it to Opera so
>> that they can fix it for the next release?
>>
>> Regards,
>>
>> Giulio Cesare
>>
>> >
>>
>
> >
>

Re: Error running tests with Opera 10

2009-07-11T11:57:30Z

This is the type of stuff one would rather not add to work-arounds in
the JavaScript code. Don't understand why Opera can't add stacktraces
as separate properties to their exception objects instead? Or is it
just that they've modified the toString() implementation?

Cheers,

/Per

On Sat, Jul 11, 2009 at 18:57, Giulio Cesare
Solaroli<giulio.cesare@...> wrote:

>
> Hello,
>
> I was having some issues running Clipperz test suite with Opera 10.
>
> Looking closer at the failed tests, I have find out that Opera 10 is
> returning a messed up name and description for Exceptions.
>
> This problem is triggered also running the default MochiKit tests; in
> MochiKit.Async test actually.
> The test expects an error with message "foo"
> (test_MochiKit-Async.html, line 300; trunk version 1525), but the
> actual value is "foo\r\nstacktrace: n/a; see
> opera:config#UserPrefs|Exceptions Have Stacktrace".
>
> Opera 10 is appending some extra values to the exception message,
> screwing up the test; in my case, it alters the behaviour of the whole
> application, as some execution paths are based on the value of the
> returned error name.
>
> Any idea on how to fix this problem? or just report it to Opera so
> that they can fix it for the next release?
>
> Regards,
>
> Giulio Cesare
>
> >
>

Error running tests with Opera 10

2009-07-11T09:57:52Z

Hello,

I was having some issues running Clipperz test suite with Opera 10.

Looking closer at the failed tests, I have find out that Opera 10 is
returning a messed up name and description for Exceptions.

This problem is triggered also running the default MochiKit tests; in
MochiKit.Async test actually.
The test expects an error with message "foo"
(test_MochiKit-Async.html, line 300; trunk version 1525), but the
actual value is "foo\r\nstacktrace: n/a; see
opera:config#UserPrefs|Exceptions Have Stacktrace".

Opera 10 is appending some extra values to the exception message,
screwing up the test; in my case, it alters the behaviour of the whole
application, as some execution paths are based on the value of the
returned error name.

Any idea on how to fix this problem? or just report it to Opera so
that they can fix it for the next release?

Regards,

Giulio Cesare

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Firefox 3.5 and XmlHttpRequest

2009-07-08T10:10:40Z

Thanks for reproducing :)

I've originally encountered the bug with a packed version of MochiKit;
in that case, Signal.connect firing implies that the rest of MochiKit
is available including logging.

I've also tested it with connect(window, 'onload', ... ) where it
occurs less frequently.

I've quite a number of images on the page, and it seems to occur more
frequently if I do a full cache reload of the page.

Here it is 'in the wild': http://gs.statcounter.com/
(MochiKit.Logging is not enabled; if the bug occurs the flash graph
will not load)

Eoghan

On Jul 8, 5:11 pm, Karl Norby <Karl.No...@...> wrote:

> I ran your test in FF3.5, and I ended up seeing no log entry in about
> 1 of every 10 trials, although I saw the request every time in
> firebug. I changed your test around to use body onload instead, and it
> works fine every time I test it. Since the requests seem to be going
> through, signal.js is loading every time before signal is called, but
> logging probably is not (loaded much later than signal). If I change
> 'log' to 'alert' in your example, the problem doesn't persist.
> So, even if FF loads all of the scripts in head in the correct order,
> script tags in body can be loaded at any point of that process, thus
> creating the race condition. That's probably a bug in firefox then, as
> I can't think of why that behavior would be desirable.
>
> Cheers!
>
> -Karl
>
> On Jul 8, 9:59 am, Eoghan <eoghanomur...@...> wrote:
>
> > I'm noticing a problem using a deferred with firefox 3.5.
>
> > I have a bit of javascript at the bottom of the html to synthesize a
> > domload event (but I have also reproduced this behaviour with a plain
> > window.onload event) and fire off an AJAX request :
>
> > ....
> > <script type="text/javascript">signal(window, 'onDOMload');</
> > script>
> > </body></html>
>
> > file.js :
>
> > connect(window, 'onDOMload', function(e){
> > var loadc = loadJSONDoc("/test");
> > loadc.addCallback(function(r){ log('success'); });
> > loadc.addErrback(function(r){ log('error'); });
> > });
>
> > Most of the time in firefox 3.5 nothing at all gets logged ... you can
> > see that the JSON response was returned correctly in firebug, but
> > neither the callback or errback fires. The status of 'loadc' is
> > 'success'.
>
> > It appears to work correctly in both Chrome and IE8.
> > When I downgrade firefox to 3.0.11 it also runs as expected.
>
> > Anyone else seeing anything similar?
>
> > I have a feeling that it has something to do with that I'm firing off
> > the request early, while the rest of the page is loading... I've used
> > callLater to delay the request, and see the same behaviour but much
> > less freequently.
>
> > Eoghan

Re: Firefox 3.5 and XmlHttpRequest

2009-07-08T09:11:34Z

I ran your test in FF3.5, and I ended up seeing no log entry in about
1 of every 10 trials, although I saw the request every time in
firebug. I changed your test around to use body onload instead, and it
works fine every time I test it. Since the requests seem to be going
through, signal.js is loading every time before signal is called, but
logging probably is not (loaded much later than signal). If I change
'log' to 'alert' in your example, the problem doesn't persist.
So, even if FF loads all of the scripts in head in the correct order,
script tags in body can be loaded at any point of that process, thus
creating the race condition. That's probably a bug in firefox then, as
I can't think of why that behavior would be desirable.

Cheers!

-Karl

On Jul 8, 9:59 am, Eoghan <eoghanomur...@...> wrote:

> I'm noticing a problem using a deferred with firefox 3.5.
>
> I have a bit of javascript at the bottom of the html to synthesize a
> domload event (but I have also reproduced this behaviour with a plain
> window.onload event) and fire off an AJAX request :
>
> ....
> <script type="text/javascript">signal(window, 'onDOMload');</
> script>
> </body></html>
>
> file.js :
>
> connect(window, 'onDOMload', function(e){
> var loadc = loadJSONDoc("/test");
> loadc.addCallback(function(r){ log('success'); });
> loadc.addErrback(function(r){ log('error'); });
> });
>
> Most of the time in firefox 3.5 nothing at all gets logged ... you can
> see that the JSON response was returned correctly in firebug, but
> neither the callback or errback fires. The status of 'loadc' is
> 'success'.
>
> It appears to work correctly in both Chrome and IE8.
> When I downgrade firefox to 3.0.11 it also runs as expected.
>
> Anyone else seeing anything similar?
>
> I have a feeling that it has something to do with that I'm firing off
> the request early, while the rest of the page is loading... I've used
> callLater to delay the request, and see the same behaviour but much
> less freequently.
>
> Eoghan

Firefox 3.5 and XmlHttpRequest

2009-07-08T07:59:17Z

I'm noticing a problem using a deferred with firefox 3.5.

I have a bit of javascript at the bottom of the html to synthesize a
domload event (but I have also reproduced this behaviour with a plain
window.onload event) and fire off an AJAX request :

....
<script type="text/javascript">signal(window, 'onDOMload');</
script>
</body></html>

file.js :

connect(window, 'onDOMload', function(e){
var loadc = loadJSONDoc("/test");
loadc.addCallback(function(r){ log('success'); });
loadc.addErrback(function(r){ log('error'); });
});

Most of the time in firefox 3.5 nothing at all gets logged ... you can
see that the JSON response was returned correctly in firebug, but
neither the callback or errback fires. The status of 'loadc' is
'success'.

It appears to work correctly in both Chrome and IE8.
When I downgrade firefox to 3.0.11 it also runs as expected.

Anyone else seeing anything similar?

I have a feeling that it has something to do with that I'm firing off
the request early, while the rest of the page is loading... I've used
callLater to delay the request, and see the same behaviour but much
less freequently.

Eoghan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Ajax post request, not finding correct url - 404

2009-07-02T12:13:58Z

I'm in the process of putting my site into production state on Apache
2.2.11 with mod_wsgi 2.5 (using TG1.1). The Ajax request works fine
in the development server, but it doesn't for Apache. Keeps looking
to the document root '/var/www/html' for the server-side script '/
login_json' as seen in Apache the error_log.

[Thu Jul 02 11:17:52 2009] [error] [client 192.168.1.164] File does
not exist: /var/www/html/login_json, referer: http://192.168.1.164/interview/

Here is my javascript and server-side script http://dpaste.com/hold/62591/

Other standard http requests to different pages are working
correctly. How do I get my javascript to look to the correct URL?
I've tried replacing '/login_json' with 'http://192.168.1.164/
interview/login_json' (also used 127.0.0.1) but no change.

Thanks,
Adam

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: bind() / memory leak?

2009-06-29T06:33:32Z

Thanks for the insight. I solved part of the problem by changing how
MochiKit.Base.bind stores the bound object (im_self); instead of
returning a function with the bound object as a direct property of the
function, it stores a numeric index to a table of objects instead.
When binding, if your target object has already been bound before, bind
() just reuses the existing index. It's significantly reduced the
amount of memory being used, although long-term usage of the app still
builds a large table of objects which needs pruned from time to time.
Our app has a state manager built in so I use it to prune the bound
objects list of things that got set up in a given state, upon exiting
that state.

Anyways, here's the updated MochiKit.Base.bind() if anybody is
interested:

window.onunload = function () {

delete MochiKit.Base.bindings;
delete MochiKit.Base.bound_objects;

};

MochiKit.Base.bindings = [];
MochiKit.Base.bound_objects = [];

/** @id MochiKit.Base.bind */
MochiKit.Base.bind = function (func, self/* args... */) {
if (typeof(func) == "string") {
func = self[func];
}
var im_func = func.im_func;
var im_preargs = func.im_preargs;
var im_self = func.im_self;
var m = MochiKit.Base;
if (typeof(func) == "function" && typeof(func.apply) ==
"undefined") {
// this is for cases where JavaScript sucks ass and
gives you a
// really dumb built-in function like alert() that
doesn't have
// an apply
func = m._wrapDumbFunction(func);
}
if (typeof(im_func) != 'function') {
im_func = func;
}
if (typeof(self) != 'undefined') {
im_self = self;
}

im_self_index = null;

for (var i = 0; i < MochiKit.Base.bound_objects.length; i
++) {

if (MochiKit.Base.bound_objects[i] === im_self) {

im_self_index = i;

} // end if

} // end for

if (im_self_index == null) {

MochiKit.Base.bound_objects.push(im_self);

im_self_index = MochiKit.Base.bound_objects.length -
1;

} // end if

im_self = MochiKit.Base.bound_objects[im_self_index];

if (typeof(im_preargs) == 'undefined') {
im_preargs = [];
} else {
im_preargs = im_preargs.slice();
}
m.extend(im_preargs, arguments, 2);
var newfunc = function () {
var args = arguments;
var me = arguments.callee;
if (MochiKit.Base.bindings
[me.index].im_preargs.length > 0) {
args = m.concat(MochiKit.Base.bindings
[me.index].im_preargs, args);
}
var self = MochiKit.Base.bindings[me.index].im_self;
if (!self) {
self = this;
}
return MochiKit.Base.bindings[me.index].im_func.apply
(self, args);
};

newfunc.index = MochiKit.Base.bindings.length;

MochiKit.Base.bindings.push({"im_self" : im_self,
"im_func" : im_func,
"im_preargs" :
im_preargs});

return newfunc;
};
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: bind() / memory leak?

2009-06-19T23:39:14Z

Mostly, these issues are caused by lingering references to the removed
DOM nodes (lookup tables, etc). In this case, since you use MochiKit,
you might want to look at the MochKit.Signal.disconnectAll().
It might also be helpful for some older browsers to tear down the DOM tree.

Here's a helper function that I've used to achieve these two aims:

/**
* Destroys a widget or a DOM node. This function will remove the DOM
* node from the tree, disconnect all signals and call all widget
* destructor functions. The same procedure will also be applied
* recursively to all child nodes. Once destroyed, all references to
* the widget object should be cleared in order for the browser to
* be able to reclaim the memory used.
*
* @param {Widget/Node/Array} node the (widget) DOM node or list
*
* @static
*/
MochiKit.Widget.destroyWidget = function (node) {
    if (node.nodeType != null) {
        if (typeof(node.destroy) == "function") {
            node.destroy();
        }
        if (node.parentNode != null) {
            MochiKit.DOM.removeElement(node);
        }
        MochiKit.Signal.disconnectAll(node);
        while (node.firstChild != null) {
            MochiKit.Widget.destroyWidget(node.firstChild);
        }
    } else if (MochiKit.Base.isArrayLike(node)) {
        for (var i = node.length - 1; i >= 0; i--) {
            MochiKit.Widget.destroyWidget(node[i]);
        }
    }
}

Cheers,

/Per

On Fri, Jun 19, 2009 at 17:34, Kevin Kaiser <kevinsync@...> wrote:

>
> I've built a rather complicated web app that makes heavy use of
> MochiKit.Base.bind() and partial(). There are no page refreshes in the
> app and the majority of the page content between areas of the UI is
> dynamically created / removed via DOM methods. A user might spend
> considerable time inside the app and it leaks memory like I've never
> seen.
>
> I suspect it has a lot to do with the fact that the majority of the
> data in browser memory is inside of a single, potentially-large
> object / data structure, and most bind() or partial() calls pass along
> this object as a parameter, which ends up set as the im_self attribute
> on the resulting bound function.
>
> A lot of my bound functions end up set as event handlers and things
> like that, so when the app tears down part of the screen to display
> new stuff, those functions just get popped out of the DOM but aren't
> garbage collected by the browser since the page never reloads.
>
> Is there any way to force garbage collection while a page is still
> loaded in any of the browsers?
>
> I may need to build some kind of explicit cleanup functions that
> attach to an element and clean these references upon the element's
> removal from the DOM, except I fear it being really slow due to the
> fact that if you remove a parent element that has a huge amount of
> [great-great][grand]child nodes, I'll have to walk the whole tree and
> clean each individual node..
>
> Anyhow, any ideas would be wonderful.
>
> Thanks!
> >

Re: bind() / memory leak?

2009-06-19T17:24:50Z

Isn't jProbe specifically for profiling Java code? I don't understand how that would help. Or is Java just the implementation language?

David

On Fri, Jun 19, 2009 at 12:10 PM, Jeryl Cook <twoencore@...> wrote:

Have you tried jProbe? it will help you figure out where the memory
leak is..it could be anywhere not necessarily MochiKit.

http://www.quest.com/jprobe/
its commercial but there is a trial.

On Fri, Jun 19, 2009 at 11:34 AM, Kevin Kaiser<kevinsync@...> wrote:
>
> I've built a rather complicated web app that makes heavy use of
> MochiKit.Base.bind() and partial(). There are no page refreshes in the
> app and the majority of the page content between areas of the UI is
> dynamically created / removed via DOM methods. A user might spend
> considerable time inside the app and it leaks memory like I've never
> seen.
>
> I suspect it has a lot to do with the fact that the majority of the
> data in browser memory is inside of a single, potentially-large
> object / data structure, and most bind() or partial() calls pass along
> this object as a parameter, which ends up set as the im_self attribute
> on the resulting bound function.
>
> A lot of my bound functions end up set as event handlers and things
> like that, so when the app tears down part of the screen to display
> new stuff, those functions just get popped out of the DOM but aren't
> garbage collected by the browser since the page never reloads.
>
> Is there any way to force garbage collection while a page is still
> loaded in any of the browsers?
>
> I may need to build some kind of explicit cleanup functions that
> attach to an element and clean these references upon the element's
> removal from the DOM, except I fear it being really slow due to the
> fact that if you remove a parent element that has a huge amount of
> [great-great][grand]child nodes, I'll have to walk the whole tree and
> clean each individual node..
>
> Anyhow, any ideas would be wonderful.
>
> Thanks!
> >
>

--

Jeryl Cook
/^\ Pharaoh /^\
http://pharaohofkush.blogspot.com/
I have long since come to believe that people never mean half of what
they say, and that it is best to disregard their talk and judge only
their actions.
-Dorothy Day

Re: bind() / memory leak?

2009-06-19T09:10:09Z

Have you tried jProbe? it will help you figure out where the memory
leak is..it could be anywhere not necessarily MochiKit.

http://www.quest.com/jprobe/
its commercial but there is a trial.

On Fri, Jun 19, 2009 at 11:34 AM, Kevin Kaiser<kevinsync@...> wrote:

--
Jeryl Cook
/^\ Pharaoh /^\
http://pharaohofkush.blogspot.com/
I have long since come to believe that people never mean half of what
they say, and that it is best to disregard their talk and judge only
their actions.
-Dorothy Day

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

bind() / memory leak?

2009-06-19T08:34:14Z

I've built a rather complicated web app that makes heavy use of
MochiKit.Base.bind() and partial(). There are no page refreshes in the
app and the majority of the page content between areas of the UI is
dynamically created / removed via DOM methods. A user might spend
considerable time inside the app and it leaks memory like I've never
seen.

I suspect it has a lot to do with the fact that the majority of the
data in browser memory is inside of a single, potentially-large
object / data structure, and most bind() or partial() calls pass along
this object as a parameter, which ends up set as the im_self attribute
on the resulting bound function.

A lot of my bound functions end up set as event handlers and things
like that, so when the app tears down part of the screen to display
new stuff, those functions just get popped out of the DOM but aren't
garbage collected by the browser since the page never reloads.

Is there any way to force garbage collection while a page is still
loaded in any of the browsers?

I may need to build some kind of explicit cleanup functions that
attach to an element and clean these references upon the element's
removal from the DOM, except I fear it being really slow due to the
fact that if you remove a parent element that has a huge amount of
[great-great][grand]child nodes, I'll have to walk the whole tree and
clean each individual node..

Anyhow, any ideas would be wonderful.

Thanks!
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Async help, loadJSONdoc and evalJSONrequest

2009-06-18T05:44:24Z

Hi
Try to do the connect after the page has loaded. Use addLoadEvent for that.
So your code will look something like that:

function bla() {
connect(...);
}

addLoadEvent(bla);

Some other issues:
If you are using ajax, you don't really need form actions, the clicking submit will do a regular (non-ajax) POST.
I usually connect to onclick if I want ajax.

It seems that you are using turbogears 2. I'm using turbogears1, so take my advice with a grain of salt, but in tg1 you can do expose("json"), and return a regular dict.

If you need further help with that, I'll be glad to help you off-list.

Cheers,
Imri

On Thu, Jun 18, 2009 at 12:48 AM, Adam Yee <adamjyee@...> wrote:

Hi all, I'm a newbie to MochiKit and JS, so bare with me if there are
syntax errors or design flaws.

I'm trying to achieve simple AJAX functionality (using JSON) by
submitting a single form input and displaying the input asynchronously
with .innerHTML.

My code (testpage.html and controllers.py):
http://dpaste.com/hold/56577/

The connect('form', 'onsubmit', submitClicked) doesn't seem to be
doing anything. The json.dumps(d) is doing its job - when submit is
clicked, the page refreshes with only {"insert": "whatever text
here"}. I can't figure out how to json.loads properly, but if I can't
get the JS to work, the the server side script won't receive any
json. So my struggle is in sending the xmlhttprequest.

Thank you for helping,
Adam

--
Imri Goldberg
--------------------------------------
www.algorithm.co.il/blogs/
--------------------------------------
-- insert signature here ----

Async help, loadJSONdoc and evalJSONrequest

2009-06-17T14:48:40Z

Hi all, I'm a newbie to MochiKit and JS, so bare with me if there are
syntax errors or design flaws.

I'm trying to achieve simple AJAX functionality (using JSON) by
submitting a single form input and displaying the input asynchronously
with .innerHTML.

My code (testpage.html and controllers.py):
http://dpaste.com/hold/56577/

The connect('form', 'onsubmit', submitClicked) doesn't seem to be
doing anything. The json.dumps(d) is doing its job - when submit is
clicked, the page refreshes with only {"insert": "whatever text
here"}. I can't figure out how to json.loads properly, but if I can't
get the JS to work, the the server side script won't receive any
json. So my struggle is in sending the xmlhttprequest.

Thank you for helping,
Adam

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to mochikit@...
To unsubscribe from this group, send email to mochikit+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Widgets in mochikit-patches

2009-05-31T15:23:26Z

I think the current location is quite fine, if not in the MochiKit
repo itself. Should perhaps add a link from the Wiki pages, though...

If you'd like to contribute new widgets, I'd love to include them!
Just fork the git repo and send me a pull request when done.

Regarding other widget solutions, my personal motivations for
implementing yet-another-JavaScript-widget-library are:

1. Using a mix-in approach instead of wrapper objects, the code
becomes more light-weight.
2. Creating a UI from XML instead of code makes for easier maintenance.
3. With a nice default look and simple API:s, the widgets become easy to use.
4. Unlimited open source license to avoid legal and commercial hassles.

All of the above can be argued back and forth, of course. I see #1
above as the main point with this effort, since both the others could
equally well be patched into some other widget library. And I see no
point in doing something that isn't sufficiently different from other
efforts in this area. I know lots of you just want to avoid using
another JS library for your widgets, but is that really such a big
problem? In fact, YUI is pretty configurable in that way if I recall
correctly.

Which kind of resonates with my reasons for staying with MochiKit in
spite of the jQuery popularity surge (and actually using it a bit at
work from time to time). That it does things differently from other JS
libraries. For good or bad.

Anyway. These are just my ramblings on the JS widget topic. Feel free
to disagree.

Cheers,

/Per

On Sun, May 31, 2009 at 23:23, Ryan Wilcox <ryanwilcox@...> wrote:

> Per,
>
> If not in the standard MochiKit package, maybe in a centralized place/
> repo "blessed" by the MochiKit team as the "Widgets 4 MochiKit"
> project, for example??
>
> I'd be willing to contribute a few controls (a multi-select/shuffle
> take-options-from-this-select-and-put-in-that-one widget, for example.
> Available at <http://bitbucket.org/rwilcox/
> mochikit_multiselecttransfer/>).
>
> Usually I'll use YUI framework for the big-gun widgets, but yes a
> MochiKit widgets package would be _excellent_. It feels annoying, for
> example, when I see a widget that's just perfect for what I need,
> except it requires JQuery (and I don't want to pull in a second or
> third JS library into the mix...)
>
> So, +1 from me,
> _Ryan Wilcox