On 31/10/2023 9:28 PM, Atila Neves wrote:
> There's plenty of work to be done in Phobos, the issue is finding contributors. We need replacements for std.{json,xml}. I wouldn't mind replacing/updating std.socket either. Robert Schadek's made the case more than once that we need more file formats in there too, which I agree with. Then there's the fact that we're currently concentrating on finishing/stabilising instead of adding new features.
> 
> The prerequisite right now in my opinion is finishing allocators and moving them out of experimental. I don't think it makes sense to start work on Phobos v2 before v1 is done, and it isn't. It doesn't help that I need to figure out how to include the library's evolution in the proposal for editions.

Two years ago you said you would talk to me about what needed to be done with std.experimental.allocators, you have not.

I was motivated at the time to see them completed. I no longer am.

Paul Backus has currently taken up the task with some feedback from myself and is doing R&D on what an allocator API should look like (as the current one has some mighty big problems with it).

The problem has not been finding contributors, its aligning the window of time when a contributor is willing and motivated to do something and when leadership is receptive of it.

I am reminded about std.uni's table generator. You said one thing on one previous PR, and on mine after I had done the work wouldn't say anything affirmative about it going in. What is absolutely sad about this is after it was in I heard that Symmetry were starting to get uneasy about the tables being so old and were thinking about replacing the entire thing.

There is much to learn from before going forward positively and for a lot of previous contributors that has been: "Not worth it, they are not receptive or encouraging of my contributions".

On Tuesday, 31 October 2023 at 09:28:40 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 31/10/2023 9:28 PM, Atila Neves wrote:
>> There's plenty of work to be done in Phobos, the issue is finding contributors. We need replacements for std.{json,xml}. I wouldn't mind replacing/updating std.socket either. Robert Schadek's made the case more than once that we need more file formats in there too, which I agree with. Then there's the fact that we're currently concentrating on finishing/stabilising instead of adding new features.
>> 
>> The prerequisite right now in my opinion is finishing allocators and moving them out of experimental. I don't think it makes sense to start work on Phobos v2 before v1 is done, and it isn't. It doesn't help that I need to figure out how to include the library's evolution in the proposal for editions.
>
> Two years ago you said you would talk to me about what needed to be done with std.experimental.allocators, you have not.
>
> I was motivated at the time to see them completed. I no longer am.

Sorry about that, I clearly dropped the ball. Want to restart?

>
> Paul Backus has currently taken up the task with some feedback from myself and is doing R&D on what an allocator API should look like (as the current one has some mighty big problems with it).

I also did some R&D recently, and as soon as I'm done with editions I want to talk to him about exactly this. And Timon, probably.

> I am reminded about std.uni's table generator. You said one thing on one previous PR, and on mine after I had done the work wouldn't say anything affirmative about it going in. What is absolutely sad about this is after it was in I heard that Symmetry were starting to get uneasy about the tables being so old and were thinking about replacing the entire thing.

I don't know enough about the issue to opine, unfortunately.

> There is much to learn from before going forward positively and for a lot of previous contributors that has been: "Not worth it, they are not receptive or encouraging of my contributions".

Valid. The best case scenario is aligning contributors' interests and time with what's good for the language/library/ecosystem/etc.

On Tuesday, 31 October 2023 at 10:50:20 UTC, Atila Neves wrote:
> On Tuesday, 31 October 2023 at 09:28:40 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> Paul Backus has currently taken up the task with some feedback from myself and is doing R&D on what an allocator API should look like (as the current one has some mighty big problems with it).
>
> I also did some R&D recently, and as soon as I'm done with editions I want to talk to him about exactly this. And Timon, probably.

I've published a first-draft writeup of my overall approach as a gist [1], and hope to have a working demo/proof-of-concept up on github sometime in the next few days. I look forward to comparing our findings. :)

[1] https://gist.github.com/pbackus/29c520bc4e1f4aa075c9171db791d234

On Tuesday, 31 October 2023 at 10:50:20 UTC, Atila Neves wrote:
> On Tuesday, 31 October 2023 at 09:28:40 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> [...]
>
> Sorry about that, I clearly dropped the ball. Want to restart?
>
>> [...]
>
> I also did some R&D recently, and as soon as I'm done with editions I want to talk to him about exactly this. And Timon, probably.
>
>> [...]
>
> I don't know enough about the issue to opine, unfortunately.
>
>> [...]
>
> Valid. The best case scenario is aligning contributors' interests and time with what's good for the language/library/ecosystem/etc.

What are your comments on this?

https://forum.dlang.org/post/jcgphabrvyjecnjzjlpf@forum.dlang.org

On 31/10/2023 11:50 PM, Atila Neves wrote:
> On Tuesday, 31 October 2023 at 09:28:40 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> I was motivated at the time to see them completed. I no longer am.
> 
> Sorry about that, I clearly dropped the ball. Want to restart?

Not particularly. I'll leave it to Paul to communicate the big stuff.

Mine: https://github.com/Project-Sidero/basic_memory/tree/main/source/sidero/base/allocators

Only things I'd change is dump TypeInfo in favor of my own thing, and allow getting rid of duplicative state (defensive programming).

>> I am reminded about std.uni's table generator. You said one thing on one previous PR, and on mine after I had done the work wouldn't say anything affirmative about it going in. What is absolutely sad about this is after it was in I heard that Symmetry were starting to get uneasy about the tables being so old and were thinking about replacing the entire thing.
> 
> I don't know enough about the issue to opine, unfortunately.

See that is concerning. That means you haven't done risk analysis yet. After all, having tables that were later manually modified (which they were) without the table generator is a ticking time bomb. That could stop dmd being released.