Re: D Language Foundation January 2024 Monthly Meeting Summary
Mike Parker kirjoitti 14.5.2024 klo 16.23: The D Language Foundation's monthly meeting for January 2024 was held on Friday the 12th. There were two things of particular note about this meeting. Thanks for the write-up once again! Always nice to know what is cooking, even when the news come a bit late.
Re: D Language Foundation January 2024 Monthly Meeting Summary
Wow I see I was mentioned at a lot at this meeting! In saying that I do have some points to add about Item 2 data structures. Data structures come in one of two forms generally: owning and non-owning. ### Non-owning Non-owning is the simplest, its an index. It doesn't own any memory that isn't internal. Takes in a single memory allocator for its internal state. For its memory safety you are pretty limited to concerns surrounding read-only-ness of its internal state. Which only exist because the GC allocator might be in use. You pass a value in, you get a value out. No references. ### Owning Owning data structures come with two subsets which may be mixed to form a third combined subset. Cleans up Takes in two memory allocators, one for its internal state, one for its deallocation of values. Will deallocate any memory given to it, which also means that once memory is placed into it, it now owns it and is responsible for its cleanup. As for memory safety you have only one (as long as you don't use references out). Owner escape analysis, this is a DIP Walter has required for me to work on before reference counting. So its going in anyway. References out I'll assume here that it does not clean up any memory passed in, that you handle this manually, that the data structure is merely an index. In almost all ways its similar to non-owning, one memory allocator, still has the memory safety concerns of the owner. An you also have to worry about borrows typically from a struct acting as a reference. Which once again is resolved with owner escape analysis (noticing a trend yet?). What this tells us is that non-owning data structures can go in pretty much immediately, although there will need to be some remedial work once we get reference counting and with that a solution to read only memory. But of course because Walter wants owner escape analysis first, it doesn't matter, both owning and non-owning will need to go together. Note: concurrent data structures will need the read only memory solution due to the locks (notice a trend yet?) as well. We'll likely want to use long names to differentiate all these behaviors unfortunately. As it could be quite desirable to have all the different variations.
Re: D Language Foundation January 2024 Monthly Meeting Summary
On Tuesday, 14 May 2024 at 14:01:28 UTC, Hipreme wrote: [snip] ### Item 8 There was a project which is basically rdmd but faster out there, done by Jonathan Marler. - https://github.com/dragon-lang/rund Sometime ago I thought about just pushing to d tools, but since no one cared about, I simply abandoned the idea, but there it is: I was thinking the same thing! I had used it a few times, but I just don't use rdmd enough to want to use an alternative to it. If the improved functionality were built-in, then that would be a positive.
Re: D Language Foundation January 2024 Monthly Meeting Summary
On Tuesday, 14 May 2024 at 13:23:17 UTC, Mike Parker wrote: The D Language Foundation's monthly meeting for January 2024 was held on Friday the 12th. There were two things of particular note about this meeting. [...] I have some things to feedback on those points ### Item 6 I had done my DIP thinking mostly about intermediate values on mixin template. That would make the value not included in mixin template, but yes, static foreach also needs that, so a good solution would be one that solves them both. ### Item 7 Redub is a tool that is basically a dub clone which improves what dub is not doing very smartly: building. Recently I've done a simple, yet major UX improvement: if dmd is not found, it tries ldc. But the apex of UX I've done is inside my engine, but I've shared a plenty of times: build selector. This tool is focused into: All the items ending with a `*` are optionally done by the user. - Downloads a D compiler if none is found on the user system - Downloads and installs git [only on Windows that is automatic. Other systems it shows an error requiring that to be done] - [Windows] - Installs MSVC and vcruntime so D is able to build it on systems that doesn't have this option (I needed that when running with a VM). - Download Android SDK/NDK [based on the user system], with the supported LDC compiler and sets up the DFLAGS required to build for Android.* - Sets up a custom D runtime which supports building to WASM, sets up the DFLAGS required to build it. May also get a supported compiler.* - Sets the DFLAGS required for being able to build for iOS.* ### Item 8 There was a project which is basically rdmd but faster out there, done by Jonathan Marler. - https://github.com/dragon-lang/rund Sometime ago I thought about just pushing to d tools, but since no one cared about, I simply abandoned the idea, but there it is:
D Language Foundation January 2024 Monthly Meeting Summary
The D Language Foundation's monthly meeting for January 2024 was held on Friday the 12th. There were two things of particular note about this meeting. First, Jonathan Davis joined us for the first time and is now a permanent member. We're very happy to have him aboard. Second, this was the first meeting where we adopted a new format. Previously, we'd go around the "room" to give each participant a turn to say everything they needed to say or as much as they could say before we had to move on in the interest of time. Sometimes people had problems they wanted to solve, other times they just had status updates or progress reports. When our membership was small, it all worked well, but as the invitation list grew, we could end up with long meetings in which important topics got cut short because they didn't get brought up until later in the meeting. For the new process, I ask everyone to send me any agenda items they'd like to discuss that are not progress reports or status updates. At the meetings, I'll go round-robin through the lists in the order I receive them: first item from each list, second item, etc, until either there are no more items or we've hit the hour-and-a-half mark. If we get through the items early, then I'll open the floor to anyone who has something to report. If we still have agenda items at the hour-and-a-half mark, I'll ask if we should continue for another 30 minutes or call it. This new approach has worked well for us since. It's also going to change how I write the monthly summaries. Each section heading is a topic of discussion rather than a participant's name. The only agenda items I received from the members for this meeting came from Timon. He had quite a list, and we went through pretty much the whole thing. But I did give the floor to Robert at the beginning for a very brief update. I also had one item that came in the form of a request on the Discord server. ## The Attendees The following people attended the meeting: * Andrei Alexandrescu * Walter Bright * John Colvin * Jonathan M. Davis * Timon Gehr * Martin Kinkelin * Dennis Korpel * Mathais Lang * Razvan Nitu * Mike Parker * Robert Schadek * Steven Schveighoffer * Adam Wilson ## The Summary ### Item 1: Bugzilla to GitHub migration As I noted in the [November meeting summary](https://forum.dlang.org/post/lywqaaibghfinljxo...@forum.dlang.org), some potential issues had come up regarding the effect of the Bugzilla to GitHub migration on the dlang bot. Robert had said he'd investigate them. As an update, he'd discovered some changes needed to be made to the changelog generator and had made good progress on that. He said Vladimir Panteleev had been working on some changes to the dlang bot related to how it closed solved issues. When that was all completed, they'd be able to test it. He wanted to put it through multiple tests to make sure it held up and worked as intended. ### Item 2: D data structures Monkyyy asked me on the Discord server to bring his article on [D data structures](https://monkyyyscience.substack.com/p/d-data-structures?r=99zq&utm_campaign=post&utm_medium=web) to the meeting. I emailed a link to everyone before the meeting. I received a little bit of feedback in the email thread. In summary: * Monkyyy's complaint that allocators are "unmerged" highlights why Átila wants them out of `std.experimental`. * The article doesn't specify any specific data structures he'd like to see in the standard library. * Any redesign of Phobos needs to consider containers at some point, but how comprehensive should it be? How high of a priority? * Some simple containers can easily be built on top of arrays. Should we add that kind of thing to Phobos, or only more complex ones? * Would it be better to have a comprehensive container library in the dub registry? I asked if anyone had any more feedback that they hadn't raised in the email thread. Timon suggested that someone should do what Paul did with the sumtype package: write a container library and then we could put it in Phobos if it was good enough. Adam said he'd been having discussions about containers with Rikki and others. He told us that Rikki felt that we needed to focus on allocators first, then once that was solved we could start looking at containers. Adam said he didn't know if that was necessary or not, but based on that and other conversations he'd had on Discord, he thought that was the point of the article. Steve said he agreed with Timon: if we were going to have something that was going into Phobos, it should be put up on dub first to prove that it was worth including. There were so many different opinions around containers and their APIs that it wasn't something we should just say, "Here's some space in Phobos, now put them in." Put it in dub first, work out the API we wanted, make sure it all works, and then put it in Phobos. Razvan wondered what the procedure would be. There
