Mike Hearn wrote:
So assuming there has been no action on this front I guess
there are three ways to fix this:
* Fix the Python interpreter to use a real compacting GC
That could be worse! Compacting GC's require twice the memory of a
non-compacting one. (you dont know how much garbage you have when you
walk the heap to GC so you need another empty heap of the same size to
copy everything into it)
* Rewrite the applet in something other than Python and which
isn't going to cause massive flamewars (which basically means
C or C++)
Could do but might not be economical time wise for the devloper(s)
* Somebody could implement a Python-like language which compiles
to native code.
I would like to but GCC4 has absolutely no docs for implementing new
languages. It should also be a community effort to create a new language
if existing ones are unsuitable.
But then you'd have pretty much cloned Boo, and
might as well be using Mono anyway.
Mono and most other GC languages (gcj/java et al) also suffer from
memory leaks due to the boehm GC not being precise enough. This alone
makes them unsuitable for long running apps or daemons else you risk
having all your free memory being eaten up in the long run.
The right solution is to not use a GC langugae for these kinds of apps
(unless they offer manual freeing of objects in addition to GC which the
boehm GC supports).
--
Mr Jamie McCracken
http://www.advogato.org/person/jamiemcc/
_______________________________________________
desktop-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
