Yes it does, its just a toggle switch in the top menu, Aptana is
compiled against Eclipse 3.1 although it works in 3.2 i recommend
having a standalone copy of Aptana instead of trying to mix all the
different perspectives into one as there are some known conflicts.
While yes in this case it was trial and error i was using the memory
validator to help me isolate where the fault was, its a great tool and
can quickly help not only profile the application but spot where the
most resources are being spent from a memory stand point.
On 2/14/07, Colin Mollenhour <[EMAIL PROTECTED]> wrote:
>
> So the short answer is trial and error + process of elimination. Damn, I
> was hoping there was a magical solution. :)
> I might look into switching to Aptana if it has JSLint built in. I used
> Eclipse exclusively when doing Java but haven't tried it on PHP and
> Javascript for a long time, I guess the tools have matured quite a bit by
> now.
>
> Are the Prototype and SAU devs interested in making these libraries JSLint
> validated? I know it would take a lot of work on the front end and it
> doesn't like some of the uber-cool code shortcuts that we all like to use,
> but once they're validated, I think it can help to avoid these types of
> issues in the future and keeping it validated would be very easy. I made
> all of my own libraries JSLint validated and it took only a few hours using
> the extremely tedious online validator copy/paste method...
>
> Does Aptana highlight JSLint problems real-time like Eclipse does for Java
> compiler warnings/errors? That would make the process quite painless.
>
> Thanks,
> Colin
>
>
> Malard wrote:
> I used a combination of things to isolate it, first i tried using a
> tool from Software Verify. That really did'nt help much. Although it
> did track down an issue with prototype which i'm still looking into.
>
> Basically my code did something like this
>
> create a div element, apply some style (including a width)
>
> div element.morph({width: n%}); where n is the new value i wanted.
>
> Had an ajax request getting the new width from the server and then
> calling this routine every 200ms
>
> Let this run for a while and found it was gaining memory.
>
> Then tried all of the above, except instead of div element.morph, i
> used setStyle, no memory loss.
>
> This gave me the evidence i needed to blame the morph function. Once i
> had that i started looking into what the function was doing, breaking
> down the various aspects of the function. Somewhat trial and error, i
> looked at what the setup function was doing and quickly realised what
> each bit was doing, i knew i was modifying the width of values so i
> looked at how that was working. I develop in the Aptana IDE and turned
> on warnings mode, which uses JSLint to find possible issues. The first
> thing it mentioned was that var was missing a preceding { for the
> function, then it mentioned that value and unit had already been
> defined.
>
> I think by chance i caught it, when i changed the code and ran it, the
> memory leak was gone.
>
> I wrote a small test case which is here:
> http://pastebin.mozilla.org/3901
> to replicate the problem in the future, i think its a bug with
> firefox, but really dont have time to persue it, i cant imagine EVER
> writing a function that compressed ;)
>
> One bit of advice i could offer, is try and isolate which bits are
> causing the problem, so if you know you've got a leak, comment out all
> of your code and run the page again, if the leak is still happening
> then look further afield, if its not, then introduce a small portion
> of the code back in, and retry until you eventually isolate which bits
> of the code are causing it, then isolate these and run them on their
> own and just keep working like that until you can track it down. Thats
> all i do :)
>
>
> On Feb 14, 6:49 pm, Colin Mollenhour <[EMAIL PROTECTED]>
> wrote:
>
>
> Good work, I am *very* curious as to how you were able to track this
> down as a memory leak? My Firefox will creep up to >250Mb memory rather
> quickly and although I am pretty sure I don't redeclare variables as is
> the problem in this case, I'd like to learn more about tracking down
> these obscure memory leaks nonetheless.
>
> Thanks,
> Colin
>
> Malard wrote:
>
>
> Hi all,
>
>
> I have noticed that the new morph functions of script.aculo.us are
> causing a severe memory leak in firefox if used for a sustained
> period, f.ex my application of it was using it to dynamically change
> the length of a div and the colour of that div, for a web based
> overview of load balancing on several computers.
>
>
> What was happening that after about a day, firefox would consume
> around 2gb of memory. After some careful investigation it seems that
> the morph effects were leaking the memory.
>
>
> In the 'setup' function in Effects.Morph starting line 981
>
>
> } else if(Element.CSS_LENGTH.test(value))
> var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/),
> value = parseFloat(components[1]), unit = (components.length
> == 3) ? components[2] : null;
>
>
> This function already is already declaring value and unit on line 972,
> it seems there is either a bug in the Javascript engine in gecko or
> the garbage collection as the values being reassigned on the
> concatonated var statement on line 982 are the only cause of the
> memory leak.
>
>
> Modifying these lines to the following:
>
>
> } else if(Element.CSS_LENGTH.test(value)) {
> var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/);
> value = parseFloat(components[1]);
> unit = (components.length == 3) ? components[2] : null;
> }
>
>
> Resolves the issue entirely. Can other people verify and possibly
> direct me to how i can add this to the library proper.
>
>
>
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Spinoffs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
