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

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.

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.

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