• Vladimir Kulev (24/24) Sep 28 2006 Why basic functionality like associative arrays needs GC to be run,
• Don Clugston (3/12) Sep 28 2006 Ever heard of Ares? I guess not. Check it out at dsource, it does
• Vladimir Kulev (10/12) Sep 28 2006 You did not guess, however. I am using D for more than a year and watchi...
• Sean Kelly (14/21) Sep 28 2006 For what it's worth, this was the primary goal of Ares and has been a

Vladimir Kulev <me lightoze.net> writes:

Why basic functionality like associative arrays needs GC to be run,
otherwize cause memory leaks? For example, the code below slowly raise
memory usage if you don't call std.gc.fullCollect.

Generally, I have the following proposals about phobos organization:
1) Make all basic functions working with and without GC enabled.
2) Separate phobos runtime from phobos userland functions. Preferably into
different packages like "phobos." and "std.". Make first to be independent
from second, even if duplication of some functions is needed.

What do people think about this?

Sample code:

private import std.stdio;
private import std.gc;
private import std.c.time;

int main() {
        int[ int ] a;
        while ( true ) {
                a[ 1 ] = 1;
                a.remove( 1 );
                usleep( 10000 );
                writefln( "..." );
                // fullCollect();
        }
        return 0;
}

Don Clugston <dac nospam.com.au> writes:

Vladimir Kulev wrote:
 Why basic functionality like associative arrays needs GC to be run,
 otherwize cause memory leaks? For example, the code below slowly raise
 memory usage if you don't call std.gc.fullCollect.
 
 Generally, I have the following proposals about phobos organization:
 1) Make all basic functions working with and without GC enabled.

 2) Separate phobos runtime from phobos userland functions. Preferably into
 different packages like "phobos." and "std.". Make first to be independent
 from second, even if duplication of some functions is needed.

Ever heard of Ares? I guess not. Check it out at dsource, it does 
exactly this.

Vladimir Kulev <me lightoze.net> writes:

Don Clugston wrote:
 Ever heard of Ares? I guess not. Check it out at dsource, it does
 exactly this.

You did not guess, however. I am using D for more than a year and watching
for everything on digitalmars.com/d and dsource.org. I have even
participated in Ares developemnt a little bit :)

Ares developement is stalled, and I think Ares is unnecessary waste of time
now. Phobos runtime is good enouth and it should be developed together with
dmd. But attaching phobos framework is not good idea, because this
slowdowns developing of such things like Mango, Ares framework, DTL and
others.
Again, this is logically different things at all.

Sean Kelly <sean f4.ca> writes:

Vladimir Kulev wrote:
 
 Ares developement is stalled, and I think Ares is unnecessary waste of time
 now. Phobos runtime is good enouth and it should be developed together with
 dmd.

For what it's worth, this was the primary goal of Ares and has been a 
property of the library since its inception--the standard library, 
garbage collector, and compiler runtime are all logically separate 
components rather than being somewhat integrated as they are in Phobos. 
  Therefore, I believe Ares may be a better starting point for such as 
design than Phobos.

As for Ares development having stalled--I'll admit I've been too busy 
with other projects recently to keep Ares up to date.  But I have spent 
some time recently mulling over design changes that should make for a 
much improved next release (which I plan to get to before too terribly 
long).

 But attaching phobos framework is not good idea, because this
 slowdowns developing of such things like Mango, Ares framework, DTL and
 others.

Exactly.


Sean