std.allocator: plea for contributions

[Atila Neves via Digitalmars-d]

Tried to, couldn't get it to compile with git HEAD. Could you 
please post the dmd and druntime git hashes, or are those forks 
as well?

Atila

On Monday, 11 May 2015 at 19:41:36 UTC, Andrei Alexandrescu wrote:
> As some might have inferred from my recent posts, there is good 
> progress on std.allocator.
>
> I have come to think that this is going to be significant. This 
> is hard to put in words but I'm sure many others understand the 
> feeling of having found the "right" design, where all parts 
> seems to fit and add to a greater whole.
>
> Worst case, std.allocator will be a reasonable collection of 
> today's typical patterns in memory allocation, and an obscure 
> library available to D users. Best case, it will be a zeitgeist 
> of today's thinking about memory allocation, a compelling 
> reason to use D, and a compelling reason to link applications 
> written in other languages with D.
>
> Code in the dedicated branch in my repo 
> (https://github.com/andralex/phobos/tree/allocator/std/experimental/allocator) 
> has gotten near 9KLOC. At this size, any significant work by 
> one person requires quite a bit of maneuvering, which slows me 
> down.
>
> It would be great if I could get some help with this on one 
> specific topic that is parallelizable: test coverage. Running
>
> make BUILD=debug std/experimental/allocator.test
>
> produces a bunch of .lst files in the current directory that 
> show which code is covered (or not). Pull requests that 
> increase test coverage would be of great help to the project. 
> They're also a meaningful way to get into std.allocator and 
> learn about memory allocation techniques for anyone interested.
>
> There's another, more advanced, topic: defining a 
> SharedFreeTree, i.e. a thread-shared version of 
> https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/free_tree.d. 
> If a lock-free or almost-lock-free abstraction could be defined 
> for that, then we'd have at our disposal a battery of adaptable 
> freelists that we can front the standard GC allocator with, to 
> great effect.
>
> There is of course the matter of better documentation, but as 
> I'm working actively on it please hold off on that for now.
>
> So, to any and all who'd want to contribute - fork that branch, 
> get it working, and send me PRs for it!
>
>
> Thanks,
>
> Andrei