dynapi-dev — List related to the current DynAPI Core development

Re: [Dynapi-Dev] Continuing Freeing memory

[Raymond S. <dst...@or...>]

More morning mind food (at least where I am)...


The new operator allocates memory for objects. How is this memory
deallocated?

If you have ever programmed in C++, you might wonder why JavaScript does not
have a delete operator to match the new operator. The reason for this is
simple: It's not necessary!
In JavaScript, memory for objects is automatically reclaimed whenever there
is no longer need for the object. The JavaScript interpreter tracks
references to objects and deletes them when variables no longer refer to
them.

For example, consider the following JavaScript code:

d = new Array (50);
d = null;

The first statement allocates memory for an Array object large enough to
hold 50 elements, and then records the fact that the new object is
referenced by a variable named d.
The next statement, however, changes d so that instead of referring to the
Array object, it instead contains the special value null. Since there is no
longer any way to access the Array object, the JavaScript interpreter
destroys it by reclaiming the memory that was allocated to it.

Reclaiming memory allocated for objects which can no longer be accessed is
called garbage collection. Allocated objects which are no longer accessible
by variables are called orphan objects.

This next example shows how to modify the above code to prevent the
destruction of the Array object:

d = new Array (50);
e = d; // make e refer to the same object as d
d = null; // disassociate d from the Array object
Since the Array object is referenced by e at the moment it is abandoned by
d, the Array object remains intact.
In conclusion, there is no need to worry about destroying objects in
JavaScript. Garbage collection is performed automatically by the interpreter
whenever objects are no longer useful or documents are unloaded. If you want
to explicitly destroy an object, you can do so by abandoning it -- that is,
by making sure there are no variables that refer to it. (Setting the
variables to null works pretty well for this.)

Re: [Dynapi-Dev] Continuing Freeing memory

[Jared N. <ja...@aa...>]

BTW, last post is speculation, but I'm fairly sure...also I said get, when I
meant delete :)

Re: [Dynapi-Dev] Continuing Freeing memory

[Jared N. <ja...@aa...>]

Just so you know, removeChild also works in IE5.5, in case you're
interested.

To get at all the children's children you could just recursively call the
memFree() method (or whatever you choose to call it). Also, while the
intrerpreter does rely on automatic garbage collection, this delete idea
will at least 'tag' it for collection immediately.

Re: [Dynapi-Dev] Continuing Freeing memory

[Raymond S. <dst...@or...>]

Sounds like we need a "null cycle killer".  Damn sure circular references a
playing a big roll in our leak...

>

This problem with cycles is the price that must be paid for a simple,
lightweight, portable garbage collection scheme. The only way to prevent
this problem is by manual intervention. If you create code in which A refers
to B, B refers to C, and C refers to A, then you must be able to recognize
that you've created a cycle, and take steps to force the cycle to be garbage
collected when it is no longer needed.

When you know that the objects in your cycle are no longer in use, you can
force them to be garbage collected by breaking the cycle. You can do this by
picking one of the objects in the cycle and setting the property of it that
refers to the next object to null. For example, suppose that A, B, and C are
objects that each have a next property, and the value of this property is
set so that these objects refer to each other and form a cycle. When these
objects are no longer in use, you can break the cycle by setting A.next to
null. This means that object B no longer has a reference from A, so its
reference count can drop to zero and it can be garbage collected. Once it
has been garbage collected, then it will no longer refer to C, so its
reference count can drop to zero and it can be garbage collected. Once C is
garbage collected, A can be garbage collected.

Note, of course, that none of this can happen if A, B, and C are stored in
global variables in a window that is still open, because those variables A,
B, and C still refer to the objects. If these were local variables in a
function, and you broke their cycle before the function returned, then they
could be garbage collected. But if they are stored in global variables, they
will remain referenced until the window that contains them closes. In this
case, if you want to force them to be garbage collected you must break the
cycle and set the variables to null:


A.next = null;      // break the cycle
A = B = C = null;   // remove the last remaining external references

Re: [Dynapi-Dev] Continuing Freeing memory

[Raymond S. <dst...@or...>]

Something I found...

11.7 Garbage Collection
In any programming language in which you can dynamically create new objects
(such as with the new operator in JavaScript) there must be some form of
"garbage collection"--a way of reclaiming the memory occupied by objects
that are no longer in use. In C and C++, garbage collection is manual--the
programmer explicitly decides when to free memory for reuse. In Java, on the
other hand, garbage collection is handled automatically--the system can
detect when objects are no longer in use and free them appropriately.

JavaScript also supports automatic garbage collection. In Internet Explorer
3.0, garbage collection is implemented in a technically sound way and you
don't have to understand any of its details--it is enough to know that when
your objects are no longer in use, the memory they occupy will automatically
be reclaimed by the system. Navigator 4.0 will also have a perfectly
transparent garbage collection scheme like this. Unfortunately, garbage
collection in earlier versions of Navigator is less than perfect. In
Navigator 3.0, it is pretty good, but requires you to be aware of a couple
of issues. In Navigator 2.0, garbage collection is seriously flawed, and you
must take a number of steps to avoid crashing the browser! The following
subsections provide the details.

Reference Counting in Navigator 3.0
In Navigator 3.0, garbage collection is performed by reference counting.
This means that every object (whether a user object created by JavaScript
code, or a built-in HTML object created by the browser) keeps track of the
number of references there are to it. Recall that objects are assigned by
reference in JavaScript, rather than having their complete value copied.

When an object is created and a reference to it is stored in a variable, the
object's reference count is 1. When the reference to the object is copied
and stored in another variable, the reference count is incremented to 2.
When one of the two variables that holds these references is overwritten
with some new value, the object's reference count is decremented back to 1.
If the reference count reaches zero, then there are no more references to
the object, and since there are no references to copy, there can never again
be a reference to the object in the program. Therefore, JavaScript knows
that it is safe to destroy the object and "garbage collect" the memory
associated with it.

This reference-counting scheme has some important implications. (These
implications are also true of the Internet Explorer garbage collector, but,
as we'll see, they are not true of the garbage collection scheme in
Navigator 2.0.) If JavaScript code running in a window creates an object,
and a reference to that object is stored in a variable of another window,
then that object will continue to exist even after the window that created
it is closed, or loads in a different page. The original reference to the
object is lost, but since a reference still exists from another window, the
object will not be garbage collected.

Perhaps a more surprising implication is that a top-level browser window may
be closed by the user or by JavaScript code, but the Window object
associated with it may continue to exist. This occurs when a variable in one
window contains a reference to the window that is closed. Since there is
still a reference to the Window object, that object cannot be garbage
collected. Note, however, that many of the methods and properties of a
Window object that is closed cannot be meaningfully used. In Navigator 3.0,
you should be sure to check the closed property (a Boolean value) of any
Window object before using its properties or methods, if there is any chance
that it could have been closed.

Shortcomings of Garbage Collection by Reference Counting
As you may already be aware, there are some shortcomings to using reference
counting as a garbage collection scheme. In fact, some people don't even
consider reference counting to be true garbage collection, and reserve that
term for algorithms such as "mark-and-sweep" garbage collection. The
computer science literature on garbage collection is large and technical,
and we won't get into it here. For our purposes it is enough to know that
reference counting is a very simple form of garbage collection to implement,
and it works fine in many situations. There are situations, however, in
which reference counting cannot correctly detect and collect all "garbage",
and you need to be aware of these.

The basic flaw with reference counting has to do with cyclical references.
If object A contains a reference to object B and object B contains a
reference to object A, then a cycle of references exists. A cycle would also
exist, for example, if A referred to B, B referred to C, and C referred back
to A. In cycles such as these, there is always a reference from within the
cycle to every element in the cycle. Thus, even if none of the elements of
the cycle has any remaining references, their reference count will never
drop below one, and they can never be garbage collected. The entire cycle
may be garbage, because there is no way to refer to any of these objects
from a program, but because they all refer to each other, a
reference-counting garbage collector will not be able to detect and free
this unused memory.

This problem with cycles is the price that must be paid for a simple,
lightweight, portable garbage collection scheme. The only way to prevent
this problem is by manual intervention. If you create code in which A refers
to B, B refers to C, and C refers to A, then you must be able to recognize
that you've created a cycle, and take steps to force the cycle to be garbage
collected when it is no longer needed.

When you know that the objects in your cycle are no longer in use, you can
force them to be garbage collected by breaking the cycle. You can do this by
picking one of the objects in the cycle and setting the property of it that
refers to the next object to null. For example, suppose that A, B, and C are
objects that each have a next property, and the value of this property is
set so that these objects refer to each other and form a cycle. When these
objects are no longer in use, you can break the cycle by setting A.next to
null. This means that object B no longer has a reference from A, so its
reference count can drop to zero and it can be garbage collected. Once it
has been garbage collected, then it will no longer refer to C, so its
reference count can drop to zero and it can be garbage collected. Once C is
garbage collected, A can be garbage collected.

Note, of course, that none of this can happen if A, B, and C are stored in
global variables in a window that is still open, because those variables A,
B, and C still refer to the objects. If these were local variables in a
function, and you broke their cycle before the function returned, then they
could be garbage collected. But if they are stored in global variables, they
will remain referenced until the window that contains them closes. In this
case, if you want to force them to be garbage collected you must break the
cycle and set the variables to null:


A.next = null;      // break the cycle
A = B = C = null;   // remove the last remaining external references

Per-Page Memory Management in Navigator 2.0
The garbage collection scheme in Navigator 2.0 is much simpler than that in
Navigator 3.0, and, unfortunately, it is inadequate for the needs of
JavaScript programs that use multiple windows and frames. In Navigator 2.0,
all objects created by JavaScript code running in any particular window
allocate memory from a pool of memory owned by the window. Then, when the
window is destroyed, or when the document (containing the JavaScript
program) displayed in the window is unloaded, the entire pool of memory is
freed at once. No memory is freed until then.

With this garbage collection scheme, all memory allocated by the JavaScript
running in a window can be freed in a single stroke. It is a simple and
efficient scheme to implement. Unfortunately, it suffers from two major
drawbacks.

First, if an object is created in one window, and then a reference to that
object is stored in a variable in a second window, that object will be
destroyed when the first window moves on to a new page, despite the fact
that there is still an active reference to it from the other window. If this
other window attempts to use this reference to the destroyed object, an
error will result, possibly crashing the browser! This is an especially
pernicious problem, because doing something as simple as assigning a string
can cause this problem. Consider the following code:


newwin = window.open("", "temp_window");
newwin.defaultStatus = "temporary browser window".

The defaultStatus property is set to a string "owned" by the original
window. If that window is closed, the string will be destroyed and the next
reference to defaultStatus will go looking for a non-existing string.

The second problem with this scheme is that if a window never unloads, the
memory associated with it will never be freed. For a page that runs some
JavaScript once and then is static, this is not a problem. But consider a
page that performs a status-bar animation, for example. If it updates the
status bar several times a second for a long time, the memory consumed by
that page will grow and grow. Another example occurs with the use of frames.
One frame might serve as a navigation window, with controls that allow a
user to easily browse a large site in other frames or other windows. These
other frames and windows may load and unload pages frequently, freeing
memory. But the navigation frame itself remains the same, and the memory
associated with it is not freed. Depending on how the event handlers are
written, there is a good chance that each time the user interacts with the
navigation controls some new string or object will be created, and no memory
will ever be freed. Eventually, the browser will run out of memory, and may
well crash.

Workarounds for Navigator 2.0
It is possible to compensate, somewhat, for these memory management problems
in Navigator 2.0. For the problem of memory not being released until the
page is unloaded, the solution is simply to be careful about how much memory
your scripts consume. If your page loops a lot or does a repetitive
animation, look very carefully at the code that is executed over and over,
and minimize the number of objects created on each iteration. Similarly, if
you write a script that the user may use frequently without ever unloading,
be sure to keep careful tabs on your memory usage.

Note that string manipulation is a big memory sink--each time you call a
method on a string object, a new string object is generally created for the
result. The same is true for string concatenation with the + operator.

For the problem of dangling references from one window to destroyed objects
that were owned by another, one solution is to avoid programs that rely on
inter-window references. Another solution is to be sure to make copies of
all strings and other objects that are passed from one window to another.
Suppose that in window 1, you want to set the defaultStatus property of
window 2, as we saw earlier. If you do this directly with code in window 1,
then window 2 will contain a reference to an object owned by window 1. But,
if you call a function in window 2 to do the assignment, and make sure that
the function makes a copy of the object, then the object assigned in window
2 will be owned by window 2. You could, for example, ensure that window 2
contains a definition of the following function:


function set_string_property(name, value)
{
    // Assign a property to this window, using associative array notation.
    // We add the empty string to the value to force JavaScript to make
    // a copy. If this function is called from another window, we won't
    // own the value string, but by making a copy, we do own the result.
    self[name] = value + "";
}

With this function defined, you could then set the property from window 1
with a line like the following:


window2.set_string_property("defaultStatus", "temporary browser window");

RE: [Dynapi-Dev] Continuing Freeing memory

[Pascal <pb...@oi...>]

One of the main changes to DynAPI would then be making the DynDocument's
child objects of the DynAPI.. then you can destroy the complete DynAPI tree
using:

 destroy(DynAPI)

add that to the onunload handler  (can it be all that easy!?)


Pascal Bestebroer (pb...@oi...)
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Jordi -
> IlMaestro
> - Ministral
> Verzonden: woensdag 21 februari 2001 16:15
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] Continuing Freeing memory
>
>
> We could easily have a destroy function
>
> function destroy(object) {
> for(var i in object) destroy(i)
> delete object
> }
>
> This would appy to any object, not only DynLayers. Maybe
> DynAPI.destroy() or even
> destroy(window) and see what happens.
>
> Richard Emberson wrote:
>
> > ECMAScript Language Specification
> > http://www.ecma.ch/ecma1/stand/ecma-262.htm
> >
> > ECMAScript Components Specification
> > http://www.ecma.ch/ecma1/stand/ecma-290.htm
> >
> > >From the spec for javascript (Ecma-262):
> >
> > 8.6.2.5 [[Delete]] (P)
> > When the [[Delete]] method of O is called with property
> name P, the following
> > steps are taken: 1. If O doesn t have a property with name
> P, return true.
> > 2. If the property has the DontDelete attribute, return false.
> > 3. Remove the property with name P from O.
> > 4. Return true.
> >
> > 11.4.1 The delete Operator
> > The production UnaryExpression : delete UnaryExpression is
> evaluated as
> > follows:
> > 1. Evaluate UnaryExpression.
> > 2. If Type(Result(1)) is not Reference, return true.
> > 3. Call GetBase(Result(1)).
> > 4. Call GetPropertyName(Result(1)).
> > 5. Call the [[Delete]] method on Result(3), providing
> Result(4) as the property
> > name to delete.
> > 6. Return Result(5).
> >
> > Implimentations of course can vary.
> >
> > When I wrote my javascript interpreter/compiler 4 years ago
> I helped (in a very
> > small way)
> > in debugging the spec.
> >
> > Richard Emberson
> >
> > Pascal wrote:
> >
> > > so:
> > >
> > > myLayer = new DynLayer
> > >
> > > delete myLayer
> > >
> > > destroys it completely? (or do we have to delete every
> object created within
> > > the dynlayer object ?)
> > >
> > > Pascal Bestebroer (pb...@oi...)
> > > Software ontwikkelaar
> > > Oberon Informatiesystemen b.v.
> > > http://www.oibv.com
> > >
> > > > -----Oorspronkelijk bericht-----
> > > > Van: dyn...@li...
> > > > [mailto:dyn...@li...]Namens Eytan
> > > > Heidingsfeld
> > > > Verzonden: woensdag 21 februari 2001 14:20
> > > > Aan: Dynapi-Dev
> > > > Onderwerp: [Dynapi-Dev] Continuing Freeing memory
> > > >
> > > >
> > > > Amazing news flash:
> > > > Thanx to Bradford Maness and the delete command in JS I found
> > > > that if you
> > > > delete objects(repeating objects not elements) in IE
> memory is freed.
> > > >
> > > > 8an
> > > >
> > > >
> > > > _______________________________________________
> > > > Dynapi-Dev mailing list
> > > > Dyn...@li...
> > > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> > > >
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] Continuing Freeing memory

[Raymond S. <dst...@or...>]

Maybe deleting it marks it for garbage collection.  You would think there is
some definitive guide as to what "flag" an item for "gc"...

----- Original Message -----
From: "Eytan Heidingsfeld" <ey...@tr...>
To: <dyn...@li...>
Sent: Wednesday, February 21, 2001 6:58 AM
Subject: RE: [Dynapi-Dev] Continuing Freeing memory


> The problem is not mainly with that but with freeing memory of the
element.
> BTW
> Why don't we use removeChild for removing layers in NN6?
> 8an
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] Continuing Freeing memory

[Jordi - I. - M. <jmi...@or...>]

We could easily have a destroy function

function destroy(object) {
for(var i in object) destroy(i)
delete object
}

This would appy to any object, not only DynLayers. Maybe DynAPI.destroy() or even
destroy(window) and see what happens.

Richard Emberson wrote:

> ECMAScript Language Specification
> http://www.ecma.ch/ecma1/stand/ecma-262.htm
>
> ECMAScript Components Specification
> http://www.ecma.ch/ecma1/stand/ecma-290.htm
>
> >From the spec for javascript (Ecma-262):
>
> 8.6.2.5 [[Delete]] (P)
> When the [[Delete]] method of O is called with property name P, the following
> steps are taken: 1. If O doesn t have a property with name P, return true.
> 2. If the property has the DontDelete attribute, return false.
> 3. Remove the property with name P from O.
> 4. Return true.
>
> 11.4.1 The delete Operator
> The production UnaryExpression : delete UnaryExpression is evaluated as
> follows:
> 1. Evaluate UnaryExpression.
> 2. If Type(Result(1)) is not Reference, return true.
> 3. Call GetBase(Result(1)).
> 4. Call GetPropertyName(Result(1)).
> 5. Call the [[Delete]] method on Result(3), providing Result(4) as the property
> name to delete.
> 6. Return Result(5).
>
> Implimentations of course can vary.
>
> When I wrote my javascript interpreter/compiler 4 years ago I helped (in a very
> small way)
> in debugging the spec.
>
> Richard Emberson
>
> Pascal wrote:
>
> > so:
> >
> > myLayer = new DynLayer
> >
> > delete myLayer
> >
> > destroys it completely? (or do we have to delete every object created within
> > the dynlayer object ?)
> >
> > Pascal Bestebroer (pb...@oi...)
> > Software ontwikkelaar
> > Oberon Informatiesystemen b.v.
> > http://www.oibv.com
> >
> > > -----Oorspronkelijk bericht-----
> > > Van: dyn...@li...
> > > [mailto:dyn...@li...]Namens Eytan
> > > Heidingsfeld
> > > Verzonden: woensdag 21 februari 2001 14:20
> > > Aan: Dynapi-Dev
> > > Onderwerp: [Dynapi-Dev] Continuing Freeing memory
> > >
> > >
> > > Amazing news flash:
> > > Thanx to Bradford Maness and the delete command in JS I found
> > > that if you
> > > delete objects(repeating objects not elements) in IE memory is freed.
> > >
> > > 8an
> > >
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> > >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

Re: [Dynapi-Dev] Continuing Freeing memory

[Richard E. <emb...@co...>]

ECMAScript Language Specification
http://www.ecma.ch/ecma1/stand/ecma-262.htm

ECMAScript Components Specification
http://www.ecma.ch/ecma1/stand/ecma-290.htm


From the spec for javascript (Ecma-262):

8.6.2.5 [[Delete]] (P)
When the [[Delete]] method of O is called with property name P, the following
steps are taken: 1. If O doesn t have a property with name P, return true.
2. If the property has the DontDelete attribute, return false.
3. Remove the property with name P from O.
4. Return true.


11.4.1 The delete Operator
The production UnaryExpression : delete UnaryExpression is evaluated as
follows:
1. Evaluate UnaryExpression.
2. If Type(Result(1)) is not Reference, return true.
3. Call GetBase(Result(1)).
4. Call GetPropertyName(Result(1)).
5. Call the [[Delete]] method on Result(3), providing Result(4) as the property
name to delete.
6. Return Result(5).

Implimentations of course can vary.

When I wrote my javascript interpreter/compiler 4 years ago I helped (in a very
small way)
in debugging the spec.

Richard Emberson


Pascal wrote:

> so:
>
> myLayer = new DynLayer
>
> delete myLayer
>
> destroys it completely? (or do we have to delete every object created within
> the dynlayer object ?)
>
> Pascal Bestebroer (pb...@oi...)
> Software ontwikkelaar
> Oberon Informatiesystemen b.v.
> http://www.oibv.com
>
> > -----Oorspronkelijk bericht-----
> > Van: dyn...@li...
> > [mailto:dyn...@li...]Namens Eytan
> > Heidingsfeld
> > Verzonden: woensdag 21 februari 2001 14:20
> > Aan: Dynapi-Dev
> > Onderwerp: [Dynapi-Dev] Continuing Freeing memory
> >
> >
> > Amazing news flash:
> > Thanx to Bradford Maness and the delete command in JS I found
> > that if you
> > delete objects(repeating objects not elements) in IE memory is freed.
> >
> > 8an
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

RE: [Dynapi-Dev] Continuing Freeing memory

[Eytan H. <ey...@tr...>]

The problem is not mainly with that but with freeing memory of the element.
BTW
Why don't we use removeChild for removing layers in NN6?
8an

RE: [Dynapi-Dev] Continuing Freeing memory

[Pascal <pb...@oi...>]

> "Note that delete affects only property values, not objects
> referred to by those
> properties"

> >From this can we establish that we cannot rely on delete to
> free memory reliably ???
> Does this also mean that we'd have to iterate through
> sub-objects deleting them? Perhaps
> some kind of destroy() method ???

hmm, it would then be possible to atleast delete all objects created within
the DynLayer (simple for loop can be used)  problematic thing are all
objects with objects them selves..

the deletefromparent method could do this for us, take care of deletion of
all objects referred to. I'll see if I can come up with anything.. and if it
actually frees any memory at all.


Pascal Bestebroer (pb...@oi...)
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com

Re: [Dynapi-Dev] Continuing Freeing memory

[Mark P. <mar...@hi...>]

From "Javascript : The Definitive Guide - 3rd Edition, Flannagan - O'Reilly"

"Note that delete affects only property values, not objects referred to by those
properties"

also

"If you are a C++ programmer, note that the delete operator in JS in nothing like the
delete operator in C++. In JS, memory deallocation is handled automatically by garbage
collection, and you never have to worry about explicitly freeing up memory."

From this can we establish that we cannot rely on delete to free memory reliably ???
Does this also mean that we'd have to iterate through sub-objects deleting them? Perhaps
some kind of destroy() method ???


Pascal wrote:

> so:
>
> myLayer = new DynLayer
>
> delete myLayer
>
> destroys it completely? (or do we have to delete every object created within
> the dynlayer object ?)
>
> Pascal Bestebroer (pb...@oi...)
> Software ontwikkelaar
> Oberon Informatiesystemen b.v.
> http://www.oibv.com
>
> > -----Oorspronkelijk bericht-----
> > Van: dyn...@li...
> > [mailto:dyn...@li...]Namens Eytan
> > Heidingsfeld
> > Verzonden: woensdag 21 februari 2001 14:20
> > Aan: Dynapi-Dev
> > Onderwerp: [Dynapi-Dev] Continuing Freeing memory
> >
> >
> > Amazing news flash:
> > Thanx to Bradford Maness and the delete command in JS I found
> > that if you
> > delete objects(repeating objects not elements) in IE memory is freed.
> >
> > 8an
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

RE: [Dynapi-Dev] Continuing Freeing memory

[Pascal <pb...@oi...>]

so:

myLayer = new DynLayer

delete myLayer

destroys it completely? (or do we have to delete every object created within
the dynlayer object ?)

Pascal Bestebroer (pb...@oi...)
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Eytan
> Heidingsfeld
> Verzonden: woensdag 21 februari 2001 14:20
> Aan: Dynapi-Dev
> Onderwerp: [Dynapi-Dev] Continuing Freeing memory
>
>
> Amazing news flash:
> Thanx to Bradford Maness and the delete command in JS I found
> that if you
> delete objects(repeating objects not elements) in IE memory is freed.
>
> 8an
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] DynAPI.require() method

[Michael P. <mp...@ph...>]

check for my earlier post reagrding this.  I included code that would collect
the errorHandler errors and display them in a separate window when the page
has finsihed loading.

martin ström wrote:

> yes, i know, i thought the DynAPI.alert could be used
> instead of alerts in for example addLibrary() and
> when debugging, forward this alert to a console instead.
>
> instead of getting a
> alert("Incorrect DynAPI.addLibrary usage:\n\nExample:
> DynAPI.addLibrary('dynapi.ext',['inline.js'])");
>
> this string could be shown i a debugging-console
> just to get everything at one place.
>
> /martin
>
> > -----Original Message-----
> > From: dyn...@li...
> > [mailto:dyn...@li...]On Behalf Of Michael
> > Pemberton
> > Sent: den 21 februari 2001 14:09
> > To: dyn...@li...
> > Subject: Re: [Dynapi-Dev] DynAPI.require() method
> >
> >
> > there is a DynAPI.errorHandler method that is used for debugging
> > purposes.  I
> > suggest that you use this method for all API related alerts.
> > This allows for
> > the error to be hidden from the user and logged for later processing.
> >
> > martin ström wrote:
> >
> > > i've made a quick and dirty .require() method written
> > > to use in widgets to make sure the right files are included.
> > > it was first meant to call DynAPI.include() for each file
> > > missed but this didn't really work so i decided just to show
> > > an alert telling which files.
> > >
> > > take a look in button.js for example how to use the
> > > require() method.
> > >
> > > i've made some minor changes in include() and added
> > > a small _include() method to get everything to work
> > >
> > > i've also added a DynAPI.alert() method which by
> > > default just shows an alert but can be overwritten
> > > for debugging-issues.
> > > this is better than common alert()s popuping up here and
> > > where in DynAPI-code.
> > >
> > > I know this maybe isn't exacly what we need talking
> > > optimizing, speed and size but i thought it could be usefull, please
> > > take a look. (as far as i know, a require() method was discussed
> > > a couple of months ago?)
> > >
> > > as i said, the code i quick written, just wanted to show my ideas
> > >
> > > (maybe this code could be an extension instead of core api,
> > > and now i noticed it has some bugs which order the files are
> > > included in netscape. well..)
> > >
> > > cheers
> > > /martin
> > >
> > >
> > ------------------------------------------------------------------------
> > >                   Name: require.zip
> > >    require.zip    Type: Zip Compressed Data
> > (application/x-zip-compressed)
> > >               Encoding: base64
> >
> > --
> > Michael Pemberton
> > mp...@ph...
> > ICQ: 12107010
> >
> >
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

--
Michael Pemberton
mp...@ph...
ICQ: 12107010

RE: [Dynapi-Dev] DynAPI.require() method

[<ma...@ab...>]

yes, i know, i thought the DynAPI.alert could be used
instead of alerts in for example addLibrary() and
when debugging, forward this alert to a console instead.

instead of getting a
alert("Incorrect DynAPI.addLibrary usage:\n\nExample:
DynAPI.addLibrary('dynapi.ext',['inline.js'])");

this string could be shown i a debugging-console
just to get everything at one place.

/martin

> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf Of Michael
> Pemberton
> Sent: den 21 februari 2001 14:09
> To: dyn...@li...
> Subject: Re: [Dynapi-Dev] DynAPI.require() method
>
>
> there is a DynAPI.errorHandler method that is used for debugging
> purposes.  I
> suggest that you use this method for all API related alerts.
> This allows for
> the error to be hidden from the user and logged for later processing.
>
> martin ström wrote:
>
> > i've made a quick and dirty .require() method written
> > to use in widgets to make sure the right files are included.
> > it was first meant to call DynAPI.include() for each file
> > missed but this didn't really work so i decided just to show
> > an alert telling which files.
> >
> > take a look in button.js for example how to use the
> > require() method.
> >
> > i've made some minor changes in include() and added
> > a small _include() method to get everything to work
> >
> > i've also added a DynAPI.alert() method which by
> > default just shows an alert but can be overwritten
> > for debugging-issues.
> > this is better than common alert()s popuping up here and
> > where in DynAPI-code.
> >
> > I know this maybe isn't exacly what we need talking
> > optimizing, speed and size but i thought it could be usefull, please
> > take a look. (as far as i know, a require() method was discussed
> > a couple of months ago?)
> >
> > as i said, the code i quick written, just wanted to show my ideas
> >
> > (maybe this code could be an extension instead of core api,
> > and now i noticed it has some bugs which order the files are
> > included in netscape. well..)
> >
> > cheers
> > /martin
> >
> >
> ------------------------------------------------------------------------
> >                   Name: require.zip
> >    require.zip    Type: Zip Compressed Data
> (application/x-zip-compressed)
> >               Encoding: base64
>
> --
> Michael Pemberton
> mp...@ph...
> ICQ: 12107010
>
>
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

[Dynapi-Dev] RE: Freeing Memory

[<la...@li...>]

Hi,

I am all with Pascal here. Redesigning DynAPI2 seems mad at this stage. The
API is pretty good as it is.
The only major problem at prevents it from beeing used at *every* page on
the web that uses dhtml is the fact that it is still leaking a lot of
memory.

Though you might think that it is not your problem as API-developers to fix.
It is all microsofts fault (everything is now-a-days).
The memoryleak still is the only major thing that keeps this otherwise great
project from beeing useful.

I am going to devote some of my day tomorrow to reduce some of the problems
with leaks that I have with a widget that I am developing. It has currently
been cut from 1mb+ leaks to 400kb leaks pr. reload.

My reduction was done soly by reducing the number of layers used at the page
and replacing that with less dynamic tables and css styles.

I have tested and found that a page with DynAPI and 1 layer eats 200kb pr.
reload. So that must be the minimum I am heading for. Still too much though.

I'd like some pointers to what else I could try to reduce the leak. And not
the least what have been tried and found not to be working.

/Lasse

- And sure, I'll post the widget once it is done :)

----- Original Message -----
From: "Pascal" <pb...@oi...>
To: <dyn...@li...>
Sent: Wednesday, February 21, 2001 3:04 AM
Subject: RE: [Dynapi-Dev] Freeing Memory


> Ok, it then seems I misunderstood the complete discussion.. but I don't
> think everyone was on the same thinking-plane as Robert is, and some other
> people (the few that actually reacted) might have thought the same way I
> have: the plan of creating a new API from the ground up.
>
> This is something I don't think has any potential what so ever (just
> restating my point here) for the reasons I posted in the other mail.
>
> I'm all for cleaning up the current code, but not for changing things
around
> "hoping" it will end up faster and lighter (I strongly believe it won't)
>
> To reply to Raymond's  disullisioned problem  quote:
>
> "To be honest I was a little disillusioned with the overall response to
what
> I was proposing.  And I'm certainly not interested in expending a large
> amount of my time for nothing."
>
> That's just part of my problem as well.. people seem to like discussing
> things (I'm one of them) but almost nothing is being done!  This is what I
> see as the biggest problem with the DynAPI2.  I have now read numerous
posts
> of people saying that they fixed bugs, created great add-ons.. great, BUT
> SHOW US.   don't tell us you did it, and it works, and it's better..give
it
> up! (read the LICENSE agreement).
>
> Everyone saying that the current API could be improved alot is correct,
but
> not for the reasons they give, but for the fact that if everyone would
start
> sharing there work more it would have grown faster.
>
> Ofcourse, Raymond, your ideas are great and planning things is fine (as
long
> as we're planning the enhancement and continueation of THIS api).. but if
> planning is all that's being done by people, then I'd rather not
> participate...and I fear that that's the case (as usual)
>
>
> "<emotes> flips blow torch in the air and extends the hand towards the
rest
> of you all."
>
> lets see who will reach towards it then, just don't get disillusioned
> again...
>
>
> Pascal Bestebroer (pb...@oi...)
> Software ontwikkelaar
> Oberon Informatiesystemen b.v.
> http://www.oibv.com
>

[Dynapi-Dev] Continuing Freeing memory

[Eytan H. <ey...@tr...>]

Amazing news flash:
Thanx to Bradford Maness and the delete command in JS I found that if you
delete objects(repeating objects not elements) in IE memory is freed.

8an

Re: [Dynapi-Dev] DynAPI.require() method

[Michael P. <mp...@ph...>]

there is a DynAPI.errorHandler method that is used for debugging purposes.  I
suggest that you use this method for all API related alerts.  This allows for
the error to be hidden from the user and logged for later processing.

martin ström wrote:

> i've made a quick and dirty .require() method written
> to use in widgets to make sure the right files are included.
> it was first meant to call DynAPI.include() for each file
> missed but this didn't really work so i decided just to show
> an alert telling which files.
>
> take a look in button.js for example how to use the
> require() method.
>
> i've made some minor changes in include() and added
> a small _include() method to get everything to work
>
> i've also added a DynAPI.alert() method which by
> default just shows an alert but can be overwritten
> for debugging-issues.
> this is better than common alert()s popuping up here and
> where in DynAPI-code.
>
> I know this maybe isn't exacly what we need talking
> optimizing, speed and size but i thought it could be usefull, please
> take a look. (as far as i know, a require() method was discussed
> a couple of months ago?)
>
> as i said, the code i quick written, just wanted to show my ideas
>
> (maybe this code could be an extension instead of core api,
> and now i noticed it has some bugs which order the files are
> included in netscape. well..)
>
> cheers
> /martin
>
>   ------------------------------------------------------------------------
>                   Name: require.zip
>    require.zip    Type: Zip Compressed Data (application/x-zip-compressed)
>               Encoding: base64

--
Michael Pemberton
mp...@ph...
ICQ: 12107010

Re: [Dynapi-Dev] Freeing Memory

[Richard B. <ma...@ri...>]

> Everything is a journey.  I just want to kick a rock and start a new path
in
> motion.  The bricks of this API are the building blocks and it's a bit
> premature to discuss architectual relevance at this point (this is a
> metaphor Richard).
Yes, I thought it sounded a little over the top :o)

R.
----- Original Message -----
From: "Raymond Smith" <dst...@or...>
To: <dyn...@li...>
Sent: Wednesday, February 21, 2001 12:33 PM
Subject: Re: [Dynapi-Dev] Freeing Memory

[Dynapi-Dev] DynAPI.require() method

[<ma...@ab...>]

i've made a quick and dirty .require() method written
to use in widgets to make sure the right files are included.
it was first meant to call DynAPI.include() for each file
missed but this didn't really work so i decided just to show
an alert telling which files.

take a look in button.js for example how to use the
require() method.

i've made some minor changes in include() and added
a small _include() method to get everything to work

i've also added a DynAPI.alert() method which by
default just shows an alert but can be overwritten
for debugging-issues.
this is better than common alert()s popuping up here and 
where in DynAPI-code.

I know this maybe isn't exacly what we need talking
optimizing, speed and size but i thought it could be usefull, please
take a look. (as far as i know, a require() method was discussed
a couple of months ago?)

as i said, the code i quick written, just wanted to show my ideas

(maybe this code could be an extension instead of core api,
and now i noticed it has some bugs which order the files are
included in netscape. well..)

cheers 
/martin

RE: [Dynapi-Dev] Event Code Separation

[Pascal <pb...@oi...>]

uhm.. no comment ;)

I'll give it a look tonight (unless Jordi wants to take this one.. with his
event war et al :)

Pascal Bestebroer (pb...@oi...)
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Michael
> Pemberton
> Verzonden: woensdag 21 februari 2001 12:47
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] Event Code Separation
>
>
> it has been mentioned before.  I'm just surprised no one did
> it earlier.  pascal
> must be getting behind in his work : )
>
> Jordi - IlMaestro - Ministral wrote:
>
> > This is one thing to be taken into account now that we're
> planning a code
> > clean-up
> >
> > Michael Pemberton wrote:
> >
> > > I've recently finished splitting the events code into
> separate files.
> > >
> > > It removes the mouse and drag events code from the
> dynapi.api section.
> > >
> > > I've placed the drag / dragdrop / mouse / key code all in
> their own
> > > dynapi.events section.
> > >
> > > I found that there was a slight modification to the
> dynlayer required.
> > > It was posted a few days ago.
> > >
> > > If anyone finds any problems with it, please post your
> comments.  I've
> > > been working with the new setup for the last week but may
> have missed a
> > > few bugs.
> > >
> > > I've also included a tweaked version of Henrik Våglin's
> keyevents code.
> > > Thanks for that goes to him.
> > > --
> > > Michael Pemberton
> > > mp...@ph...
> > > ICQ: 12107010
> > >
> > >
> --------------------------------------------------------------
> ----------
> > >                  Name: events.zip
> > >    events.zip    Type: Zip Compressed Data
> (application/x-zip-compressed)
> > >              Encoding: base64
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
> --
> Michael Pemberton
> mp...@ph...
> ICQ: 12107010
>
>
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] Event Code Separation

[Michael P. <mp...@ph...>]

it has been mentioned before.  I'm just surprised no one did it earlier.  pascal
must be getting behind in his work : )

Jordi - IlMaestro - Ministral wrote:

> This is one thing to be taken into account now that we're planning a code
> clean-up
>
> Michael Pemberton wrote:
>
> > I've recently finished splitting the events code into separate files.
> >
> > It removes the mouse and drag events code from the dynapi.api section.
> >
> > I've placed the drag / dragdrop / mouse / key code all in their own
> > dynapi.events section.
> >
> > I found that there was a slight modification to the dynlayer required.
> > It was posted a few days ago.
> >
> > If anyone finds any problems with it, please post your comments.  I've
> > been working with the new setup for the last week but may have missed a
> > few bugs.
> >
> > I've also included a tweaked version of Henrik Våglin's keyevents code.
> > Thanks for that goes to him.
> > --
> > Michael Pemberton
> > mp...@ph...
> > ICQ: 12107010
> >
> >   ------------------------------------------------------------------------
> >                  Name: events.zip
> >    events.zip    Type: Zip Compressed Data (application/x-zip-compressed)
> >              Encoding: base64
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

--
Michael Pemberton
mp...@ph...
ICQ: 12107010

Re: [Dynapi-Dev] Freeing Memory

[Raymond S. <dst...@or...>]

Well, I learned disillusionment from a master.  I remember a certain
disillusioned Pascal that went off to create Dynacore.  Your still here.
I'm not going anywhere. And a lot of the passion that drove you to leave and
get it "done" proved right in the end.

Everything is a journey.  I just want to kick a rock and start a new path in
motion.  The bricks of this API are the building blocks and it's a bit
premature to discuss architectual relevance at this point (this is a
metaphor Richard).


----- Original Message -----
From: "Pascal" <pb...@oi...>
To: <dyn...@li...>
Sent: Wednesday, February 21, 2001 3:04 AM
Subject: RE: [Dynapi-Dev] Freeing Memory


> Ok, it then seems I misunderstood the complete discussion.. but I don't
> think everyone was on the same thinking-plane as Robert is, and some other
> people (the few that actually reacted) might have thought the same way I
> have: the plan of creating a new API from the ground up.
>
> This is something I don't think has any potential what so ever (just
> restating my point here) for the reasons I posted in the other mail.
>
> I'm all for cleaning up the current code, but not for changing things
around
> "hoping" it will end up faster and lighter (I strongly believe it won't)
>
> To reply to Raymond's  disullisioned problem  quote:
>
> "To be honest I was a little disillusioned with the overall response to
what
> I was proposing.  And I'm certainly not interested in expending a large
> amount of my time for nothing."
>
> That's just part of my problem as well.. people seem to like discussing
> things (I'm one of them) but almost nothing is being done!  This is what I
> see as the biggest problem with the DynAPI2.  I have now read numerous
posts
> of people saying that they fixed bugs, created great add-ons.. great, BUT
> SHOW US.   don't tell us you did it, and it works, and it's better..give
it
> up! (read the LICENSE agreement).
>
> Everyone saying that the current API could be improved alot is correct,
but
> not for the reasons they give, but for the fact that if everyone would
start
> sharing there work more it would have grown faster.
>
> Ofcourse, Raymond, your ideas are great and planning things is fine (as
long
> as we're planning the enhancement and continueation of THIS api).. but if
> planning is all that's being done by people, then I'd rather not
> participate...and I fear that that's the case (as usual)
>
>
> "<emotes> flips blow torch in the air and extends the hand towards the
rest
> of you all."
>
> lets see who will reach towards it then, just don't get disillusioned
> again...
>
>
> Pascal Bestebroer (pb...@oi...)
> Software ontwikkelaar
> Oberon Informatiesystemen b.v.
> http://www.oibv.com
>
> > -----Oorspronkelijk bericht-----
> > Van: dyn...@li...
> > [mailto:dyn...@li...]Namens Jordi -
> > IlMaestro
> > - Ministral
> > Verzonden: woensdag 21 februari 2001 10:25
> > Aan: dyn...@li...
> > Onderwerp: Re: [Dynapi-Dev] Freeing Memory
> >
> >
> > Amen. However Pascal I don't think anyone pretends to redo
> > the API. We should
> > blame Raymond ( as usual :) ) because he introduced the 3 in
> > the name and made
> > it all look scary.
> >
> > When we're saying DynAPI3 I understand we're meaning DynAPI2
> > with better and
> > cleaner code, not a new API.
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] Event Code Separation

[Jordi - I. - M. <jmi...@or...>]

This is one thing to be taken into account now that we're planning a code
clean-up

Michael Pemberton wrote:

> I've recently finished splitting the events code into separate files.
>
> It removes the mouse and drag events code from the dynapi.api section.
>
> I've placed the drag / dragdrop / mouse / key code all in their own
> dynapi.events section.
>
> I found that there was a slight modification to the dynlayer required.
> It was posted a few days ago.
>
> If anyone finds any problems with it, please post your comments.  I've
> been working with the new setup for the last week but may have missed a
> few bugs.
>
> I've also included a tweaked version of Henrik Våglin's keyevents code.
> Thanks for that goes to him.
> --
> Michael Pemberton
> mp...@ph...
> ICQ: 12107010
>
>   ------------------------------------------------------------------------
>                  Name: events.zip
>    events.zip    Type: Zip Compressed Data (application/x-zip-compressed)
>              Encoding: base64

[Dynapi-Dev] Event Code Separation

[Michael P. <mp...@ph...>]

I've recently finished splitting the events code into separate files.

It removes the mouse and drag events code from the dynapi.api section.

I've placed the drag / dragdrop / mouse / key code all in their own
dynapi.events section.

I found that there was a slight modification to the dynlayer required.
It was posted a few days ago.

If anyone finds any problems with it, please post your comments.  I've
been working with the new setup for the last week but may have missed a
few bugs.

I've also included a tweaked version of Henrik Våglin's keyevents code.
Thanks for that goes to him.
--
Michael Pemberton
mp...@ph...
ICQ: 12107010