On 04/05/2015 05:16 AM, Andrei Alexandrescu wrote:
> Right now the allocator design works well as a flexible malloc/free
> implementation, but has no support for tracing-based garbage collection.
>
> I am evaluating whether I should add tracing capabilities to
> std.allocator, or stop here. Tracin
On 4/5/15 4:50 AM, Kagamin wrote:
On Sunday, 5 April 2015 at 03:16:32 UTC, Andrei Alexandrescu wrote:
Things are going well with std.allocator. I broke the code into a
package with modules, which makes it quite nice to deal with. Also I
just implemented a simple heterogeneous freelist allocator
On Sunday, 5 April 2015 at 03:16:32 UTC, Andrei Alexandrescu
wrote:
Things are going well with std.allocator. I broke the code into
a package with modules, which makes it quite nice to deal with.
Also I just implemented a simple heterogeneous freelist
allocator akin to the Kernighan-Ritchie one
On Sunday, 5 April 2015 at 03:16:32 UTC, Andrei Alexandrescu
wrote:
Things are going well with std.allocator. I broke the code into
a package with modules, which makes it quite nice to deal with.
Also I just implemented a simple heterogeneous freelist
allocator akin to the Kernighan-Ritchie one
On 5/04/2015 3:16 p.m., Andrei Alexandrescu wrote:
Following up on Brian's nice offer:
What's going on with std.allocator? I have a few projects (some on
Github, some at EMSI) that use it because it seemed like it was on
its way to being in Phobos. What can I do to help with this?
Things are
Following up on Brian's nice offer:
What's going on with std.allocator? I have a few projects (some on
Github, some at EMSI) that use it because it seemed like it was on
its way to being in Phobos. What can I do to help with this?
Things are going well with std.allocator. I broke the code into
