I really like this tutorial, it should definitely be linked from the
qooxdoo-pages !
Some (minor) suggestions:
- as people are very visual, I'd embed an image of your app at the
beginning to give people a clou where you are going
- there is a short sentence about initializing your members in th
>> I'm not sure since I don't have much experience with Selenium
>> assertions. But your approach seems quite cumbersome. Have you
>> considered to e.g. use the 'waitForVisible()' assertion?
Yes - this might be working ... but I had to do it all the time with
different assertions. 'waitForIdle
Hi there,
as there seems to be some qooxdoo-related selenium knowledge available
here, I hope someone might give some useful hints.
Currently I'm trying to write some Selenium tests with Selenium IDE for a
RAP-application and I have my first testcases working (thanks to the
selenium-qooxdoo-e
>> In this experiment I think that no deallocations should be taking
place,
>> as I am just creating a bunch of widgets.
>> The results show that the memory consumption of my application in IE is
>> a factor of 7 compared to Firefox. Based on your experience would you
>> blame IE guilty for t
IE uses more memory than all other browsers.
For a typical application I'd expect around 50-150MB on IE (but not
rising).
Just open some of the qooxdoo-demo-apps and compare them in different
browsers.
You won't fall below that with RAP - but you won't fall below that with
any other sophistic
>> Do you know if qooxdoo developers are currently working to quickly
>> finish the 0.7.4 release?
How should I know ? I'm sure someone from the qooxdoo guys will answer
soon.
We are eagerly waiting for it as well.
>> improvements make their way to a RAP build by the end of this year
>> (coul
Alex,
The following todo still needs to be done on the qooxdoo 0.7.x branch,
before it doesn't leak anymore (though also in the current
0.7.x-branch-head huge improvements on memory-consumptions were done
already):
http://bugzilla.qooxdoo.org/show_bug.cgi?id=1382
On the RAP side you can hav
>> so you would say that the quickstart we have offered for 0.7.x will be
a
>> good thing for 0.8.x as well?
Yep - I think without the quickstart a didn't get into qooxdoo as I did
(ok - the toolchain was more complicated in 0.7.x). The quickstart is so
easy to use when you are not being forc
You can say what you want, but in our company there is a saying, that
winning an argument is always loosing a customer.
Fact is, that new people don't want to spent 30minutes, just to figure
out, if qooxdoo is right for them.
So in my opinion a pre-built package is a totally right thing to do.
verified, thanks for fixing.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Ope
I'm afraid this last question was overseen.
I might be able to work a bit on this in the next three weeks and provide
a patch.
Of course I only want to start if I'm on the right way ;-) ...
>> So supposing there exists a new destroy-method - then this would be
solved
>> in deferring the dispo
>We could add a check to class define and show warnings for this. Would
>you open a bug report for this?
#1353
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based ap
>> BTW there is a small problem in your code:
>>/* current call-stack */
>>__recursionInfo: *new* Array(), // <-- this array will be shared
As a poor defense I could argue that after one run the array is empty
again and JS is not multithreaded so far ;-)
Anyway thanks for this hint - I r
If the function that Timer.once() starts takes longer than the intervall
it is kicked off multiple times.
Problem is, that the Timer-object gets disposed only after the function
was called.
As I don't know whether it is allowed to dispose a Timer while it fires an
event, this can be solved lik
>> I wrote a small class for finding the missing leaks. Actually it just
scans the qx-namespace and
>> prints all living object (and the first found reference-path to this
>> object).
Here it is for your usage (see below), simply called by:
var leakSearcher=new JSLeakSearcher();
leakSea
>> This is interesting. I have dome something similar: I have added a unit
>> test class, which asserts for each widget that it leaks no objects and
>> no event listeners.
Unfortunataly I won't be able to do any more work on this this week, but I
think the 'Leakfinder' could just be added to t
>>Have you any article about this issue found? I googled some hours but do
>>not find anything relevant. In the source code of jquery and dojo I also
>>do not find that they have seen such an issue.
No - I don't have any article nor searched for it.
I just realized it when doing all the tests
Some thoughts about the ObjectRegistry, now that this is the last source
of memory leaks (at least in my small examples):
As a reminder: maps written like the following:
registry[hash] = obj
with an ever-changing hash-value leak at least on IE7, even after correct
deletion of key/value pairs.
(
> will it be easy to find widgets for which it has been forgotten to
> delete/dispose them?
> When I make a new qooxdoo-0.8-app I want to be sure that all objects,
> widgets... are destroyed correctly.
Unfortunataly I can't think of any way that qooxdoo can provide a way to
automatically 'test' w
>> It got worse (using trunk rev 15905).
>> After 3000 qx.ui.core.Widgets I stopped. Leaked already >50MB.
As nothing seems to have further improved so far, I wrote a small class
for finding the missing leaks. Actually it just scans the qx-namespace and
prints all living object (and the first fo
>> Mhh, sure, this method is executed. But the problem is in another
>> place. When you call dispose the DOM element reference of each widget
>> is removed. This way the removeChild call of the parent cannot work
>> anymore.
I see.
So supposing there exists a new destroy-method - then this wou
>>> If you call setParent(null) the DOM-node is correctly removed.
Circular
>>> references between widget and DOM are reset in the destructor of
Widget.
>>This is not the case in my opinion. The node is only removed after the
>>layout queues etc. have been flushed which never happens for widge
Good that it is known to the developers ;-) ... this should definitely be
documented!
Introducing a destroy method would be a good idea - and also a good place
to document the differences to a simple dispose.
I think that 'interims-disposes' as you call it are quite common, when
creating 'sing
Sorry to disturb you with 0.7.x stuff, but as I wrote, also 0.7.3 (and
0.7.x_branch) has a huge memory leak (measured in IE 7).
After some investigation, I realized that after disposal widgets still are
referenced by their parent-widget (though invisble then) in the
_children-array.
Thats why
>> Again, I was under the impression that you have some (semi-) automatic
>> test application that you could just re-run after an SVN update
(comparing
>> files sounds more like analysis). Maybe we could run this application
on
>> our side as well?!
I posted this 'application' add the end of th
>> Until this mail the colloboration was quite friendly and your feedback
>> was really helpful.
So then sorry for overreacting a bit. After a long working day it was just
too depressing to see the numbers drop so bad.
To start collaboration again: your last checkin (15910) on ui.core.Widget
co
>> Maybe you can re-run your tests again :) Most core disposer issues,
>> especially LayoutItem, Widget, etc. were fixed. Would be interesting if
>> this results in any improvements for your test.
It got worse (using trunk rev 15905).
After 3000 qx.ui.core.Widgets I stopped. Leaked already >50M
>> Yes, but the question I guess was: Is there a leak in 0.7?!
O yes - at least as big as it was in 0.8 yesterday ... I only focused
now on 0.8 because it was easier to debug/understand due to the new
DOM-handling stuff.
I just quote from my first posting:
>> After 3000 Labels the IE7 memor
Have some great and some 'bad' news:
great: the big memory problems of labels are gone
'bad': My claim that ui.core.Widgets have no memory-problem from the last
post was wrong.
This was from a test, where widgets were created and destroyed instantly,
without adding them to the root.
My current
Pleas: if you change any script that handles pathes, test this
scripts (under windows) !
Currently the generated 'custom.js' has the following line:
uris : [["..\..\..\framework\source\class\qx\Bootstrap.js",
slashes are the wrong way, thus these are illegal strings, thus th
>> Two days ago that mini-fix described here, didn't help, there was
another
>> failure later on which I couldn't resolve because I never worked with
>> python before.
>>
>So you are saying you applied that patch 2 days ago, but then ran into
>another problem?! Is this other problem gone now?
To reproduce (using windows):
- check out trunk to 'C:\temp\qooxdoo trunk' (<- one space in path)
- go to dir 'C:\temp\qooxdoo trunk\tool\bin'
- call 'create-application.py --name TEST' (<- works)
- switch to dir 'C:\TEMP\qooxdoo trunk\tool\bin\TEST'
- call 'generate.py source' (<- nothing I c
>> Anyway, we'll have to take a very close look at the memory problems you
have reported.
Maybe to safe some time for further investigations:
- For current tests I just use destroy- and no dispose-calls.
- Using one class above Labels (i.e. Widgets) the memory consumption is
not as drastic (tes
>> If this hints at a general problem we'd like to hear about it.
When trying out the trunk (yesterday) I had the same problem.
I can't remember whether this involved 'create-application.py', but
'generate.py' definitely had problems (on windows) when the current
working folder has spaces in it
>> No, 0.7.3 has no such option. There is no equivalent.
Since I'm still hoping that there is an easy solution for RAP and qooxdoo
0.7.3:
How do I correctly get rid of a widget in 0.7.3 if not calling
disconnect() (or setParent(null) ) and then dispose() ?
>> I would not be surprised if the base line memory consumption of the
qooxdoo app
>> is above GWT and dojo as qooxdoo widgets are probably more complex than
those.
No problem with that.
>> BTW to my knowledge the RAP guys at Innoopract are working to add
widget
>> pooling in the next 0.8
If was asked to provide GWT-code as well, since it's not much I'll post
the source here.
To create a webapp, you'll have to download GWT 1.5, and do the following
as described in the getting started guide (
http://code.google.com/webtoolkit/gettingstarted.html)
1) call 'projectCreator de.tolina
At least the sourcecode for the qooxdoo app ... if wanted I'll provide dojo +
gwt source-code as well.
qx.Class.define("Application",
{
extend : qx.application.Standalone,
members :
{
map : new Array(),
offset : 0,
refresh: function(e) {
for ( var int = 0; int <
in
this case is just hiding the fact that there is a memory problem.
I planned to provide my qooxdoo-(0.8)-script, as well as GWT and Dojo examples
of the same scenario as a comparison.
Unfortunataly the newsgroup doesn't accept this - any idea how i can provide
this ?
Y
39 matches
Mail list logo
