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

[Dynapi-Dev] Dynamic Content Loading (IT WORKS)

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

I now have it working in both NS and IE (only win tested) and can't see
any bugs. (I should open my eyes)

Just place all the files in their own directory called "file" in your
libs directory.

Then all DynLayer's will have a new method called setURL:
    DynLayer.prototype.setURL=function(url,js,noevt)

url is the location of the file.
    this can be relative to the current main page or absolute.
    it MUST only be on the current domain, java does not allow external
server downloads
js
    do you wish any found javascript to be executed?
noevt
    do you wish the load events to be triggered?

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

Re: [Dynapi-Dev] Event Code Separation

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

I'm not sure about CVS but the code I attached is THE SAME as we already have.

It is simply split into separate files.  there should be NO speed difference
other than the browser having to download more small files intead of less big
ones.

Doug Melvin wrote:

> when can we see this and all of the other enhancements in the CVS snapshot?
> I am getting sick of patching my copy of DynAPI three times a week.
>
> We REALLY need to develop some sort of benchmarking standard so we can
> determine if a change is beneficial, and worth adding to the production copy
> of DynAPI.
> ----- Original Message -----
> From: "Michael Pemberton" <mp...@ph...>
> To: <dyn...@li...>
> Sent: Wednesday, February 21, 2001 3:18 AM
> Subject: [Dynapi-Dev] Event Code Separation
>
> > 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
> >
>
> ---
> Outgoing mail is certified Virus Free by AVG Free Edition
> Download at: http://www.grisoft.com/html/us_index.cfm
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

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

Re: [Dynapi-Dev] Continuing Freeing memory

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

Not sure if my tests are reliable, but I tried the following, and it showed
little difference:

www.aavex.com/asl/memtests


jaredn :: http://webfx.eae.net

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

[Pascal B. <pa...@dy...>]

think I already added the code from michael to CVS (unless the update didn't
work :)

Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Doug Melvin
> Verzonden: donderdag 22 februari 2001 1:08
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] DynAPI.require() method
>
>
> Hw about adding a switch?
> I had to comment out the errorhandler in my copy as it did not work in IE.
> It would be nice to be able to turn this on and off.
> Rather than haveing to comment the damned thing out every time I update my
> copy if the API
> ----- Original Message -----
> From: "Michael Pemberton" <mp...@ph...>
> To: <dyn...@li...>
> Sent: Wednesday, February 21, 2001 5:09 AM
> 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
>
>
> ---
> Outgoing mail is certified Virus Free by AVG Free Edition
> Download at: http://www.grisoft.com/html/us_index.cfm
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] Continuing Freeing memory

[Doug M. <do...@cr...>]

my hero!!
good score old chap..
too bad it's JS 1.5
----- Original Message -----
From: "Raymond Smith" <dst...@or...>
To: <dyn...@li...>
Sent: Wednesday, February 21, 2001 8:01 AM
Subject: Re: [Dynapi-Dev] Continuing Freeing memory


> JavaScript-1.5 Reference
> JS_GC Function
>
> Summary
> Performs garbage collection in the JS memory pool.
> Syntax
> void JS_GC(JSContext *cx);
>
>
> Description
> JS_GC performs garbage collection, if necessary, of JS objects, doubles,
and
> strings that are no longer needed by a script executing in a specified
> JSContext, cx. Garbage collection frees space in the memory pool so that
it
> can be reused by the JS engine.
> When you use JS_malloc and JS_realloc to allocate memory for executable
> script contexts, these routines automatically invoke the garbage
collection
> routine.
>
> When your scripts create many objects, you may want to call JS_GC directly
> in your code, particularly when request ends or a script terminates. To
run
> garbage collection only when a certain amount of memory has been
allocated,
> you can call JS_MaybeGC instead of JS_GC.
>
> JS_malloc Function
>
> Summary
> Allocates a region of memory for use.
> Syntax
> void * JS_malloc(JSContext *cx, size_t nbytes);
>
> Name Type Description
> cx JSContext * Pointer to a JS context from which to derive runtime
> information.
>
> nbytes size_t Amount of space, in bytes, to allocate.
>
>
> Description
> JS_malloc allocates a region of memory nbytes in size. If the allocation
is
> successful, JS_malloc returns a pointer to the beginning of the region.
> If the memory cannot be allocated, JS_malloc passes cx to
> JS_ReportOutOfMemory to report the error, and returns a null pointer.
>
> As with a standard C call to malloc, the region of memory allocated by
this
> call is uninitialized and should be assumed to contain meaningless
> information.
>
>
> Notes
> Currently JS_malloc is a wrapper on the standard C malloc call. Do not
make
> assumptions based on this underlying reliance. Future versions of
JS_malloc
> may be implemented in a different manner.
>
> JS_realloc Function
>
> Summary
> Reallocates a region of memory.
> Syntax
> void * JS_realloc(JSContext *cx, void *p, size_t nbytes);
>
> Name Type Description
> cx JSContext * Pointer to a JS context from which to derive runtime
> information.
>
> p void * Pointer to the previously allocated memory
>
> nbytes size_t Amount of space, in bytes, to reallocate.
>
>
> Description
> JS_realloc reallocates a region of memory, while preserving its contents.
> Typically you call JS_realloc because you need to allocate more memory
than
> orginally allocated with a call to JS_malloc, but it can also be called to
> decrease the amount of allocated memory, and even to deallocate the memory
> region entirely. p is a pointer to the previously allocated memory region,
> and nbytes is the size, in bytes, of the region to allocate.
>
> Notes
> Currently JS_realloc is a wrapper on the standard C realloc call. Do not
> make assumptions based on this underlying reliance. Future versions of
> JS_realloc may be implemented in a different manner.
> If p is null, then JS_realloc behaves like JS_malloc. If p is not null,
and
> nbytes is 0, JS_realloc returns null and the region is deallocated. As
with
> JS_malloc, new space is not initialized and should be regarded to contain
> meaningless information.
>
> If a reallocation request fails, JS_realloc passes cx to
> JS_ReportOutOfMemory to report the error.
>
> Whenever the pointer returned by JS_realloc differs from p, the old region
> of memory is deallocated and should not be used.
>
> JS_MaybeGC Function
>
> Summary
> Invokes conditional garbage collection on the JS memory pool.
> Syntax
> void JS_MaybeGC(JSContext *cx);
>
>
> Description
> JS_MaybeGC performs a conditional garbage collection of JS objects,
doubles,
> and strings that are no longer needed by a script executing in a specified
> JSContext, cx. This function checks that about 75% of available space has
> already been allocated to objects before peforming garbage collection. To
> force garbage collection regardless of the amount of allocated space, call
> JS_GC instead of JS_MaybeGC.
>
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] Continuing Freeing memory

[Doug M. <do...@cr...>]

eh?
there IS a delete operator in JS.
and saying "the specs say that mem is autoatically cleaned"
is silly considering that we KNOW that it is not
----- Original Message -----
From: "Raymond Smith" <dst...@or...>
To: <dyn...@li...>
Sent: Wednesday, February 21, 2001 7:57 AM
Subject: Re: [Dynapi-Dev] Continuing Freeing memory


> 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.)
>
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] Continuing Freeing memory

[Doug M. <do...@cr...>]

> 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!?)
>

assuming our assumtions about the delete operator (and it's implementation
in IE and NS)
are correct, it would indeed be that easy


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] Continuing Freeing memory

[Doug M. <do...@cr...>]

DOH.
Someone beet me to it..
(the recursive function I mean
----- Original Message -----
From: "Jordi - IlMaestro - Ministral" <jmi...@or...>
To: <dyn...@li...>
Sent: Wednesday, February 21, 2001 7:14 AM
Subject: 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


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] Continuing Freeing memory

[Doug M. <do...@cr...>]

> > "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.

a recursive funtion maybe?
'psudo code'

function delete_children(obj){

    for each child in obj.children[] {
        delete_children(child)
    }
    delete obj
}

this would delete all children of all children of all children.. ect


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] Continuing Freeing memory

[Doug M. <do...@cr...>]

that was my misstake then, I was trying to delete each and avery aspect of
an object.
not just the object.
----- Original Message -----
From: "Eytan Heidingsfeld" <ey...@tr...>
To: "Dynapi-Dev" <dyn...@li...>
Sent: Wednesday, February 21, 2001 5:20 AM
Subject: [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


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] RE: Freeing Memory

[Doug M. <do...@cr...>]

NOw this is what I mentioned earlier.
If you go nuts with the api (tree with 600 layers, list with 35 layers..)
You will get a huge memory leak.

I think people need to learn moderation.
For instance, while the menu on the toolabr looks like it's four layers,
it's actually ONE layer with ONE event handler.
I just get where in the layer the mouse is to determine which menu should be
popped up.

----- Original Message -----
From: "Lasse Lindgård" <la...@li...>
To: <dyn...@li...>
Sent: Wednesday, February 21, 2001 5:18 AM
Subject: [Dynapi-Dev] RE: Freeing Memory


> 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 mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

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

[Doug M. <do...@cr...>]

Hw about adding a switch?
I had to comment out the errorhandler in my copy as it did not work in IE.
It would be nice to be able to turn this on and off.
Rather than haveing to comment the damned thing out every time I update my
copy if the API
----- Original Message -----
From: "Michael Pemberton" <mp...@ph...>
To: <dyn...@li...>
Sent: Wednesday, February 21, 2001 5:09 AM
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


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] Event Code Separation

[Doug M. <do...@cr...>]

when can we see this and all of the other enhancements in the CVS snapshot?
I am getting sick of patching my copy of DynAPI three times a week.

We REALLY need to develop some sort of benchmarking standard so we can
determine if a change is beneficial, and worth adding to the production copy
of DynAPI.
----- Original Message -----
From: "Michael Pemberton" <mp...@ph...>
To: <dyn...@li...>
Sent: Wednesday, February 21, 2001 3:18 AM
Subject: [Dynapi-Dev] Event Code Separation


> 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
>


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

[Dynapi-Dev] DynAPI direction

[Doug M. <do...@cr...>]

Just want to make my viewpoint known.

I don't care if this is version 2.
I don't care if we go to version 3.
I just want a fully functional and fast API to allow me to build =
beautiful
Web-based applications, and make some good cash while I'm at  it.

The only reason I picked DynAPI was, well, because it was the best.
Of all the DHTMl libraries out there, this one has the most =
functionality,
the most user participation, and the most potential for the future.

But I must agree with Pascal that talking about future=20
versions is totally WRONG when we haven't even finished this one!

I must say that my priorities with the DynAPI are SPEED and PORTABILITY.
Hell, we STILL haven't come even close to fixing the MAC IE problems,
and it still takes over a minute for my main demo to load completely.

I know I haven't been participating very heavily lately,=20
and I quite frankly don't feel bad about that.
I do, after all have a life and a job.

Have a nice day.

Doug Melvin

P.S. to all who wish to start another project. GO AHEAD.
Just get the hell out of THIS list as it is for DynAPI 2.=20
Not for your personal recruitment use.


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: Re: Re: [Dynapi-Dev] Continuing Freeing memory

[Barre B. <ba...@ho...>]

Actually it would be more like:
function destroy(o){
    for(var i in o){
      if(typeof o[i]=="object") destroy(o[i])
      delete o[i]
    }
    o=null
  }   

But I've tried creating and destroying a lot of nested 
objects, and just using blank pages, and I get basically 
the same result = IE5 always steals about 100 k, no matter 
what.
However , 100k is alot better than 2 megs. So the destroy 
method might help in those cases.
Try it out.

> (might have double posted this.. sorry ;))
> 
> hmm.... I wonder if this is still true... that garbage 
> collection is done by reference counting...
> This would be very wierd since there are circular 
> references already in host objects! (Like subobjects of 
> window that point back at window.)
> But.. this would explain IE:s general memory leak I guess.
> I wonder if delete solves this problem?
> At any rate, the destroy method would have to be 
recursive, 
> i.e something like:
> 
> function destroy(obj){
>   for(var i in obj)
>     if(typeof obj[i]=="object") destroy(obj[i])
>   delete obj
> }
> 
> 
> > 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
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 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] Freeing Memory

[Doug M. <do...@cr...>]

so let's say, DynAPI 2.01 ?
----- Original Message -----
From: "Jordi - IlMaestro - Ministral" <jmi...@or...>
To: <dyn...@li...>
Sent: Wednesday, February 21, 2001 1:24 AM
Subject: 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.
>
> Pascal wrote:
>
> > Well to get this said in time:
> >
> > I think that any moves towards a DynAPI3 should be on a seperate
sourceforge
> > project (or atleast other location).
> >
> > I have absolutely no interest in doing everything all over again or even
> > participating in a venture like that.
> >
> > The DynAPI2 has been in development for little more then a year  now,
and we
> > "made" everyone drop the dynapi1 in favour of DynAPI2 saying "dynapi1 is
> > discontinued, dynapi2 will support ie55 and ns6 and other new browsers,
it's
> > better more flexible and you should just use it"
> >
> > Now you guys are thinking about doing it all over again.. this means
you'r
> > saying to all the users (and there are ALOT)  sorry people, now you'll
have
> > to use this unfinished-slightly-not-100%-working version of a
crossbrowser
> > library  because we're going to redo everything.
> >
> > Most people here haven't been involved with the full developing of the
> > DynAPI, I can think of only 3 persons at this moment that have been
> > participating in the development for this long period (and still only
about
> > 3-5 persons doing all the stuff: documentation, bug fixing, patches,
> > administrating, etc).
> >
> > In one more year, alot of you will have abonded the API3 completely,
leaving
> > only a few guys on board.. the API will work crossbrowser partially, and
not
> > fully supporting the latest browsers (by that time something like
versions
> > 110 of those browsers and DOM20)... Seen it happen already with this
code,
> > don't want to redo it just to end up with the same thing.
> >
> > In the beginning we had clean code, it was backwards compatible and was
nice
> > to look at, but didn't had the powerfull functionality it has now..
There's
> > not much wrong with the current API, the only thing is that no body ever
> > took the time to go thru the code and optimise it. I for one will keep
> > working on THIS version of the API and know it can be cleaned up, and
make
> > it work on any other future browsers coming our way.
> >
> > let the flaming begin.
> >
> > Pascal Bestebroer (pb...@oi...)
> > Software ontwikkelaar
> > Oberon Informatiesystemen b.v.
> > http://www.oibv.com
> >
> > _______________________________________________
> > 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


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] Continuing Freeing memory

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

Oh my this is going to be fun

Raymond Smith wrote:

> 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
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

Re: Re: [Dynapi-Dev] Continuing Freeing memory

[Barre B. <ba...@ho...>]

(might have double posted this.. sorry ;))

hmm.... I wonder if this is still true... that garbage 
collection is done by reference counting...
This would be very wierd since there are circular 
references already in host objects! (Like subobjects of 
window that point back at window.)
But.. this would explain IE:s general memory leak I guess.
I wonder if delete solves this problem?
At any rate, the destroy method would have to be recursive, 
i.e something like:

function destroy(obj){
  for(var i in obj)
    if(typeof obj[i]=="object") destroy(obj[i])
  delete obj
}


> 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
> 
> 
> 
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> 

Re: Re: [Dynapi-Dev] Continuing Freeing memory

[Barre B. <ba...@ho...>]

hmm.... I wonder if this is still true... that garbage 
collection is done by reference counting...
This would be very wierd since there are circular 
references already in host objects! (Like subobjects of 
window that point back at window.)
But.. this would explain IE:s general memory leak I guess.
I wonder if delete solves this problem?
At any rate, the destroy method would have to be recursive, 
like:

function destroy(obj){

}


> 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
> 
> 
> 
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> 

Re: [Dynapi-Dev] Continuing Freeing memory

[Joachim L. <lu...@ho...>]

I did a search about memory leaks in IE in Microsoft's knowledgebase. These are the issues that seemed relevant or could shed a light on this dark matter :-)


Complex DHTML Pages Cause Memory Usage to Increase Beyond Bounds
	http://support.microsoft.com/support/kb/articles/q248/6/30.asp
	Status: Fixed in 5.01

Memory Leak in Internet Explorer When Background Image Is Resized
	http://support.microsoft.com/support/kb/articles/q254/6/37.asp
	Status: Not relevant to DynAPI, but fixed in 5.01 SP1

Memory Leak in Internet Explorer Default Download Behavior
	http://support.microsoft.com/support/kb/articles/q259/3/65.asp
	Status: Not relevant to DynAPI, but fixed in 5.5 SP1

Memory Leak in JScript Array.toString and Array.toLocaleString Methods
	http://support.microsoft.com/support/kb/articles/q281/1/48.asp
	Workaround: Use Array.join(",") instead of the Array.toString method.
	Status: Bug exists in JScript 5.5, not in earlier versions

COM Objects Created in JScript Not Released Immediately
	http://support.microsoft.com/support/kb/articles/q164/4/94.asp
	Status: Not a bug, and not relevant to DynAPI


The Array.toString method was the only "live" bug I found, but I don't know if it's used anywhere in the code, but there is a workaround. There must be other issues because I use the workaround in my own code, and I still have the memory problem.

Personally I'm suspecting the first one hasn't _really_ been fixed.

/Lunna

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

[Pascal B. <pa...@dy...>]

Looks very interesting.

only problem is, as you stated, the speed of the including, but maybe we can
optimise it a bit more.


Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens martin ström
> Verzonden: woensdag 21 februari 2001 13:49
> Aan: dyn...@li...
> Onderwerp: [Dynapi-Dev] DynAPI.require() method
>
>
> 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] Continuing Freeing memory

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

The "11.7 Garbage Collection" section on gc was found on a .ru site that had
illegally posted the entire JavaScript: The Definitive Guide book by
O'Reilly online.  Since I have the book I checked.  It on pages 192-197 of
the 3rd Edition

Re: [Dynapi-Dev] Continuing Freeing memory

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

My post was a quote from O'Rielly's.  Also, I am gathering all the data I
can find that might be pertinent to finding what works.

----- Original Message -----
From: "Richard Emberson" <emb...@co...>
To: <dyn...@li...>
Sent: Wednesday, February 21, 2001 9:10 AM
Subject: Re: [Dynapi-Dev] Continuing Freeing memory


> Raymond Smith wrote:
>
> > Sounds like we need a "null cycle killer".  Damn sure circular
references a
> > playing a big roll in our leak...
> >
>
> A good, modern gc collects cycles. The Boehm gc does and so does java's. I
> assume
> M$ uses similar technology. Don't know what NS does. All
> memory allocated is kept track of. Starting from a set of "well known
objects"
> (top
> level objects) one sweeps marking all reachable objects (and not
traversing
> objects
> more than once). Then all objects that have not been marked are collected.
> Cycles are NOT a problem.
>
> Richard Emberson
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] Continuing Freeing memory

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

JavaScript-1.5 Reference
JS_GC Function

Summary
Performs garbage collection in the JS memory pool.
Syntax
void JS_GC(JSContext *cx);


Description
JS_GC performs garbage collection, if necessary, of JS objects, doubles, and
strings that are no longer needed by a script executing in a specified
JSContext, cx. Garbage collection frees space in the memory pool so that it
can be reused by the JS engine.
When you use JS_malloc and JS_realloc to allocate memory for executable
script contexts, these routines automatically invoke the garbage collection
routine.

When your scripts create many objects, you may want to call JS_GC directly
in your code, particularly when request ends or a script terminates. To run
garbage collection only when a certain amount of memory has been allocated,
you can call JS_MaybeGC instead of JS_GC.

JS_malloc Function

Summary
Allocates a region of memory for use.
Syntax
void * JS_malloc(JSContext *cx, size_t nbytes);

Name Type Description
cx JSContext * Pointer to a JS context from which to derive runtime
information.

nbytes size_t Amount of space, in bytes, to allocate.


Description
JS_malloc allocates a region of memory nbytes in size. If the allocation is
successful, JS_malloc returns a pointer to the beginning of the region.
If the memory cannot be allocated, JS_malloc passes cx to
JS_ReportOutOfMemory to report the error, and returns a null pointer.

As with a standard C call to malloc, the region of memory allocated by this
call is uninitialized and should be assumed to contain meaningless
information.


Notes
Currently JS_malloc is a wrapper on the standard C malloc call. Do not make
assumptions based on this underlying reliance. Future versions of JS_malloc
may be implemented in a different manner.

JS_realloc Function

Summary
Reallocates a region of memory.
Syntax
void * JS_realloc(JSContext *cx, void *p, size_t nbytes);

Name Type Description
cx JSContext * Pointer to a JS context from which to derive runtime
information.

p void * Pointer to the previously allocated memory

nbytes size_t Amount of space, in bytes, to reallocate.


Description
JS_realloc reallocates a region of memory, while preserving its contents.
Typically you call JS_realloc because you need to allocate more memory than
orginally allocated with a call to JS_malloc, but it can also be called to
decrease the amount of allocated memory, and even to deallocate the memory
region entirely. p is a pointer to the previously allocated memory region,
and nbytes is the size, in bytes, of the region to allocate.

Notes
Currently JS_realloc is a wrapper on the standard C realloc call. Do not
make assumptions based on this underlying reliance. Future versions of
JS_realloc may be implemented in a different manner.
If p is null, then JS_realloc behaves like JS_malloc. If p is not null, and
nbytes is 0, JS_realloc returns null and the region is deallocated. As with
JS_malloc, new space is not initialized and should be regarded to contain
meaningless information.

If a reallocation request fails, JS_realloc passes cx to
JS_ReportOutOfMemory to report the error.

Whenever the pointer returned by JS_realloc differs from p, the old region
of memory is deallocated and should not be used.

JS_MaybeGC Function

Summary
Invokes conditional garbage collection on the JS memory pool.
Syntax
void JS_MaybeGC(JSContext *cx);


Description
JS_MaybeGC performs a conditional garbage collection of JS objects, doubles,
and strings that are no longer needed by a script executing in a specified
JSContext, cx. This function checks that about 75% of available space has
already been allocated to objects before peforming garbage collection. To
force garbage collection regardless of the amount of allocated space, call
JS_GC instead of JS_MaybeGC.

Re: [Dynapi-Dev] Continuing Freeing memory

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

Raymond Smith wrote:

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

A good, modern gc collects cycles. The Boehm gc does and so does java's. I
assume
M$ uses similar technology. Don't know what NS does. All
memory allocated is kept track of. Starting from a set of "well known objects"
(top
level objects) one sweeps marking all reachable objects (and not traversing
objects
more than once). Then all objects that have not been marked are collected.
Cycles are NOT a problem.

Richard Emberson