Re: std.allocator: plea for contributions
On Thursday, 14 May 2015 at 19:07:51 UTC, Andrei Alexandrescu wrote: On 5/13/15 2:19 PM, Atila Neves wrote: 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? Thanks for looking into it! Here's what I have: dmd - acbe13ee54e024c0bba044d1146e244a5ea57502 druntime - 18d57ffe3eed8674ca2052656bb3f410084379f6 I haven't rebased phobos in a while, maybe that's the matter. What errors are you getting? Thanks, Andrei Things like (snipped): std/concurrency.d(1402): Error: 'core.sync.condition.Condition.mutex' is not nothrow std/regex/internal/parser.d(1159): Error: struct std.uni.InversionList!(GcPolicy).InversionList member add is not accessible from module parser I checked out the hashes you gave but still got similar errors. Atila
Re: std.allocator: plea for contributions
On 5/13/15 2:19 PM, Atila Neves wrote: 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? Thanks for looking into it! Here's what I have: dmd - acbe13ee54e024c0bba044d1146e244a5ea57502 druntime - 18d57ffe3eed8674ca2052656bb3f410084379f6 I haven't rebased phobos in a while, maybe that's the matter. What errors are you getting? Thanks, Andrei
Re: std.allocator: plea for contributions
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
std.allocator: plea for contributions
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
