Thread overview
Progress on std.container
Jul 16, 2012
Matthias Walter
Jul 17, 2012
Matthias Walter
Jul 17, 2012
Tobias Pankrath
July 16, 2012
Hi,

I'd like to know who is currently working on std.container - at some point I read that Andrei works on user-controlled allocation and then the issues of container structures will be addressed. Unforntunately, at the moment std.container.Array is unusable for me because of missing const Range (8248) and impossible arrays of arrays (6153).

Is there a way to see how far this development is? Can one contribute somehow? I would offer to contribute but only on a basis where the general design is fixed (e.g. there is a reference implementation for a certain container) to add other missing containers.

Best regards,

Matthias
July 16, 2012
On 7/16/12 4:19 AM, Matthias Walter wrote:
> Hi,
>
> I'd like to know who is currently working on std.container - at some
> point I read that Andrei works on user-controlled allocation and then
> the issues of container structures will be addressed. Unforntunately, at
> the moment std.container.Array is unusable for me because of missing
> const Range (8248) and impossible arrays of arrays (6153).
>
> Is there a way to see how far this development is? Can one contribute
> somehow? I would offer to contribute but only on a basis where the
> general design is fixed (e.g. there is a reference implementation for a
> certain container) to add other missing containers.

I'm the bottleneck for that. My list of actual work (aside from my duties as phobos/druntime/tools/dlang.org curator) is:

1. Put std.benchmark through the review process

2. Define allocators

3. Integrate allocators with std.container

If you have fixes for std.container that are faraway from allocation issues, I think it's safe to propose them as pull requests. I assume the advent of allocators will be a uniform additive changes for all containers.


Thanks,

Andrei
July 17, 2012
On 07/17/2012 12:41 AM, Andrei Alexandrescu wrote:
> On 7/16/12 4:19 AM, Matthias Walter wrote:
>> Hi,
>>
>> I'd like to know who is currently working on std.container - at some point I read that Andrei works on user-controlled allocation and then the issues of container structures will be addressed. Unforntunately, at the moment std.container.Array is unusable for me because of missing const Range (8248) and impossible arrays of arrays (6153).
>>
>> Is there a way to see how far this development is? Can one contribute somehow? I would offer to contribute but only on a basis where the general design is fixed (e.g. there is a reference implementation for a certain container) to add other missing containers.
> 
> I'm the bottleneck for that. My list of actual work (aside from my duties as phobos/druntime/tools/dlang.org curator) is:
> 
> 1. Put std.benchmark through the review process
> 
> 2. Define allocators
> 
> 3. Integrate allocators with std.container
> 
> If you have fixes for std.container that are faraway from allocation issues, I think it's safe to propose them as pull requests. I assume the advent of allocators will be a uniform additive changes for all containers.

That's good news - despite the fact the you have loads of work. I will probably work on these things.

Thank you!
July 17, 2012
>
> I'm the bottleneck for that. My list of actual work (aside from my duties as phobos/druntime/tools/dlang.org curator) is:
>
> 1. Put std.benchmark through the review process
>
> 2. Define allocators
>
> 3. Integrate allocators with std.container
>
> If you have fixes for std.container that are faraway from allocation issues, I think it's safe to propose them as pull requests. I assume the advent of allocators will be a uniform additive changes for all containers.
>
>
> Thanks,
>
> Andrei

What is left for std.benchmark before a second review can start?

We have several modules in the RQ or the TBD-Q (thinking about std.xml, std.json, std.benchmark, std.log) that are abandoned or at least don't get the love they deserve.

Maybe we should put a "what remains to be done" comment on those modules and advertise them as easy entry points for new contributors.