D Community Conversation with Mathias Lang
If you haven't been keeping up with our YouTube channel, I've been publishing a conversation with a member of the D community on the last Sunday of every month since January. This follows on from two conversations I had with Walter a while back. So far this year, I've talked with Martin Kinkelin, Razvan Nitu, and Dennis Korpel. Today, I've published my conversation with Mathias Lang, which you can find here: https://youtu.be/SsVHFwBPLgk Yes, I'm working my way through the core team at the moment, but I'll start gradually branching out eventually. It's D *Community* Conversations after all. I've already got a list of names I want to work through. Your name might be on it. In addition to being a core team member and the current maintainer of dub, Mathias has built a career as a D programmer over the past decade, so we had a lot of ground to cover. I enjoyed chatting with him, and I'm sure you'll find value in it. Enjoy! Be sure to check out the other chats if you haven't already! Walter (Parts 1 & 2) https://youtu.be/-kkMYJN3MnA https://youtu.be/G6b62HmsO6M Martin https://youtu.be/XpPV5OBJEvg Razvan https://youtu.be/Wndz2hLpbdM Dennis https://youtu.be/KxlY2ZQpiuI
Re: How to make project with main application and cli application in the same folder?
On Sunday, 21 April 2024 at 08:44:38 UTC, alex wrote:
Hi guys. Trying to play with vibe-d and want to create separate
web app, and cli app which can add admin users. When I just
keep both files app.d and cli.d in source folder, I get an
error that I can't have more then 1 main function.
You can do this using configurations. Whichever you list first
will be the default. Then you can use `-c configName` or
`--config=configName` to build the other one.
You'll want to exclude one of the main functions when building
the configuration to which it doesn't belong. You can do that
with version specifications (e.g., add a `cli` version in the cli
configuration, then `vesrion(cli) void main {...}` in the code).
Alternatively, if the files the main functions are in are
self-contained, then you can just exclude the one you don't need
in each configuration with the `excludeSourceFiles` directive.
Configurations:
https://dub.pm/dub-guide/recipe/#configurations
D Language Foundation January 2024 Quarterly Meeting Summary
The D Language Foundation's quarterly meeting for January, 2024 took place on Friday the 5th at 15:00 UTC. It lasted for about 45 minutes. Our quarterly meetings are where representatives from businesses big and small can come to bring us their most pressing D issues, status reports on their use of D, and so on. ## The Attendees The following people attended the meeting: * Walter Bright (DLF) * Iain Buclaw (GDC) * Luís Ferreira (Weka) * Max Haughton (Symmetry) * Dennis Korpel (DLF) * Mario Kröplin (Funkwerk) * Mathias Lang (DLF/Symmetry) * Vijay Nayar (Funnel-Labs.io) * Átila Neves (DLF/Symmetry) * Luna Nielsen (Inochi2D) * Razvan Nitu (DLF) * Mike Parker (DLF) * Guillaume Piolat (Auburn Sounds) * Carsten Rasmussen (Decard) * Robert Schadek (DLF/Symmetry) * Bastiaan Veelo (SARC) ## The Summary ### Luís __Undefined references__ Luís said that Weka had encountered a lot of undefined references when attribute inference infers the wrong attributes. For example, sometimes `@nogc` was inferred when really the GC was being used, or vice versa. Then when linking with other modules where the attributes were inferred differently, they ended up with undefined references. They had a workaround---creating an alias to another template with the mangled name that is supposed to be generated---but it was very cumbersome. Right now, this was their biggest issue. He said this didn't manifest when compiling with one compiler invocation, but when multiple invocations were involved. They would like to be able shift to building with LTO and compiling the objects file by file rather than in one compiler invocation. He also noted that one of the issues they had with compiling as a single invocation was the amount of RAM used. He said they also saw errors with attribute inference that were dependent on how the compiler was invoked. Each of the files should compile independently, but depending on the order they're passed to the compiler or which ones are passed, the errors they get are different. He said that basically, in a specific semantic pass, the compiler was just giving up on attribute inference. He also tangentially brought up a problem with [import order causing forward reference errors](https://issues.dlang.org/show_bug.cgi?id=23414). Walter said he needed to see Bugzilla issues demonstrating the problems before he could attempt to fix it. Luís said there were some similar issues reported. He was trying to Dustmite down to some minimal examples. Átila noted that it was very difficult to isolate template issues like this. He'd run into similar issues over and over and hadn't yet filed anything on Bugzilla because it's was never a trivial example. Walter said he understood and was aware of Átila's longstanding problems with this. Robert said he'd never encountered these problems at all, but that could be because of the way he used templates. Atila thoought it came down to whether you compile all at once or not. Max said that Symmetry had gotten a reduced case at one point. He thought it had made it into Bugzilla, saying Martin would have filed it. That particular case may even have been fixed. Walter reiterated that he needed a test case to reproduce it. Talking about it wouldn't move anything forward. Luís said he had a test case in the PR he had submitted in an attempt to fix it. He noted that Walter had also made an effort, but that the PR got stuck and then sank because it didn't solve the problem. (__NOTE__: [Bugzilla Issue #17541](https://issues.dlang.org/show_bug.cgi?id=17541) describes the problem. The failed attempts Walter and Luís made to fix it are in [dmd PR #10959](https://github.com/dlang/dmd/pull/10959) and [dmd PR #15534](https://github.com/dlang/dmd/pull/15534).) __Compile times__ Weka's biggest issues with compile times were with the performance of template instantiations and CTFE. They use the time trace flag with LDC and it shows these are the biggest problems. Luís asked if there were any plans to implement caching of template instantiations so that they wouldn't need to be instantiated on subsequent runs of the compiler. He also asked if it would be possible for us to have a JIT to speed up CTFE. Razvan said he was unaware of any plans to implement template caching. Luís said the idea would be to do something like LDC does with its codegen cache, where it caches the LLVM IR. Razvan asked if he was suggesting caching the actual template instance or the result after the template has been interpreted. Luís suggested that the AST should be pure. Some work could be done to separate out the member functions that mutate AST nodes so that they could be made immutable. With such a pure AST, then we could make it hashable and cache some of the work after the semantics, after some code gen. Razvan said there had been some discussion of this in the past, but he was unaware of anyone working on it. __Linter update__
Re: Best way to use large C library in D as of 2024
On Saturday, 30 March 2024 at 05:01:32 UTC, harakim wrote: @D Language Foundation - This is a HUGE selling point. I had to use cups the other day and I just copied some code from a d file and linked the library. It was so easy I was suspicious but it worked. Using C from D is pretty much as easy as using C from C and I think you should advertise that better! Though I appreciate the sentiment, it's much more effective and efficient for people actually using the feature, and who appreciate it, to write up a blog post about it somewhere and share that on Twitter/Reddit/HN, etc. Just a handful of people doing that would potentially reach a wider audience, they'd be able to show the feature in use in actual code, and their words will probably carry more weight as a language user than someone from the DLF. There's a world of difference between showing it in use in a real-world project vs. showing examples of how it can be used, which is all that I'd be able to do if I were to write about it. And that goes for anything that makes you think "the DLF should advertise this". I mean, when I had time to prioritize the blog, I was regularly writing articles about cool D features, and sometimes getting others to write guest posts about their projects or whatever. But that's pretty much like one person standing on a hilltop with a megaphone, periodically handing it off to someone else. How many other people from the D community were adding their voices? Now and then, someone would write something up somewhere, but it wasn't happening regularly or often. Anyone happy using D, who wants to see it continue to grow and improve, can help toward that end by telling the world about it. That said, if there's anyone out there who would like to take on management of the blog and make it more active, I'd love to hear from you.
D Language Foundation December 2023 Monthly Meeting Summary
The D Language Foundation's monthly meeting for December 2023 took place on Friday the 8th at 16:00 UTC. It lasted two hours. ## The Attendees The following people attended the meeting: * Andrei Alexandrescu * Paul Backus * Walter Bright * Iain Buclaw * Martin Kinkelin * Razvan Nitu * Mike Parker * Adam D. Ruppe * Steven Schveighoffer * Timon Gehr * Adam Wilson ## The Summary ### Me I opened the meeting by detailing my plans for how we run our monthlies going forward. The approach we'd been using from the beginning was to give each person a turn, allowing them to bring up multiple topics before moving on to the next person. Sometimes someone had nothing to report, sometimes one or two issues, sometimes a progress report on their work, and sometimes one or more issues that got us into long discussions. Given that our invite list had grown quite a bit in the preceding months, this had become cumbersome, leading to overly long meetings or discussions being abruptly tabled in the interest of moving on. So, I informed everyone that starting with our January monthly meeting, I would send out the invitations earlier than usual and ask everyone to email me a prioritized list of agenda items. Then at the meeting, I would only call on the people who sent me a list, going round robin in the order I received them, starting with the first item from each list, then the second, and so on, until either there were no more items or we hit the hour-and-a-half mark. If we did hit the time limit, we could decide whether to go on to two hours or not. I introduced and welcomed Paul Backus. This was his first time with us. I'd had a call with him a couple of weeks before and invited him to join us. He'd said, "Sure, I can come in for a meeting." I told him I wasn't asking him to come to one meeting but to join us as a regular member. I thought his contributions would be valuable. Happily, he accepted. __UPDATE__: We did start the new approach in January. ### Adam W. Adam W. opened by telling us he'd received an email from someone using the crypto library he'd written a few years ago. The person reported some bugs and made the case that D needed crypto in the standard library. Without that, it was hard to know which library to trust. Adam W. said he was going to fix the bugs and, since he had now started working on Phobos v3 (which the person who emailed him had no way of knowing), wanted to talk later about getting crypto in. Regarding Phobos v3, Adam W. said he and Walter had discussed it at the Seattle meetup in November. He'd sent Walter a document and Walter had suggested he put it up on GitHub for feedback and discussion. At the moment, he and Walter were having a debate over how to version the standard library, and he expected that would continue at the next Seattle meetup the following week. __UPDATE__: You can view [the Phobos v3 Design document](https://github.com/LightBender/PhobosV3-Design) in Adam W.'s repo, and participate [in the ongoing discussion](https://github.com/LightBender/PhobosV3-Design/discussions). The repo was initially private, but he made it public during this meeting. ### Timon Timon said he had some type system and language issues but didn't think they were at the forefront right now. He suggested we could discuss them in a different meeting. I asked if he wanted to get in on our planning sessions. He said he did. ### Adam R. Adam R. said that the PR for the `@standalone` attribute opened in August and the string interpolation thing that had been open for a while were both stalled out. He then said he was very interested in the Phobos v3 stuff and would love to see the document. Adam W. said made the repo public and posted the link in the chat. I said I'd thought Walter had approved `@standalone` in a previous meeting, then asked if Razvan or Dennis had looked at the PR. Dennis said there had been a weird test failure on it, but it was passing now. He thought the bug might still be there, but just wasn't triggering. Even so, since it was green, it was going to be merged. Paul said he'd dug into it and found that the problem was a timeout on the CI test runner, so it shouldn't be a blocker. Walter said there had been disagreement over whether the feature should be an attribute or a pragma, and that had been his main objection to it. He thought it just didn't look good as an attribute, especially given how it was an extremely specific use case. He thought pragma was more suitable for it. Adam R. noted that pragmas weren't backward compatible. Walter said unrecognized pragmas were supposed to be ignored. That was their intended purpose. Dennis said that's not how the compiler currently worked. There was a switch to ignore pragmas. Walter hadn't been aware that had been added. He told Adam he'd take a look at the PR again. Timon commented that although pragmas are supposed to be benign, pragma mangle could break
Re: DConf '24 Early-Bird Registration is Open, Submission Deadline Set!
On Monday, 25 March 2024 at 20:57:39 UTC, Mike Parker wrote: We also now have a submission deadline of June 8 AOE. Let's get those submissions coming in, folks! Please note that the submission deadline is now May 17.
DConf '24 Early-Bird Registration is Open, Submission Deadline Set!
Early-Bird registration is now open! If you're thinking about attending DConf this year, you've got until June 17 to take advantage of the 15% discount. General registration opens on June 18. As always, students can register at a discounted rate that remains fixed throughout the registration period. All of the details are on the DConf '24 homepage: https://dconf.org/2024/ We also now have a submission deadline of June 8 AOE. Let's get those submissions coming in, folks! Note that this year, we have some text fields along with the PayPal button. One of them is where you can let us know if you have any special dietary requirements. The other is to let us know if you'd like a nickname, like a forum or GitHub handle, included on your name tag. Please let me know if you have any issues making the payment. See you in London!
Re: DConf Online Livestream Link
On Monday, 18 March 2024 at 11:11:03 UTC, Nick Treleaven wrote: BTW each link to slides is giving me a 404. Luckily the live stream video is still up to rewind :-) I thought I'd fixed that the other day (I'd forgotten to add the slides directory to the Makefile initially), but apparently make behaves differently on Mac and Linux. Fixed now.
Re: DConf Online Livestream Link
On Sunday, 10 March 2024 at 16:07:23 UTC, Mike Parker wrote: The countdown is on! I'll kick off the DConf Online Livestream at 14:55 UTC on March 16. You can find it here: https://www.youtube.com/live/8GV_TuYk3lk And if you haven't seen the details yet, take a look here: https://dconf.org/2024/online/index.html See you there! We're a few minutes away from kicking off.
D Language Foundation October/November 2023 Planning Updates
## October We had no regular planning sessions in October. Instead, there were two workgroup meetings focused on DMD as a library. These took place after the monthly meeting and involved several people who were stakeholders, were interested in the project, or had some level of experience with it. The invitation list included Dennis Korpel, Jan Jurzitza (WebFreak), Prajwal S N, Razvan Nitu, Ali Çehreli, Luís Ferreira, Martin Kinkelin, and Walter Bright. The main focus of these meetings was a proposal Razvan had regarding the possibility of overriding AST Nodes, something [he'd brought up in our September meeting](https://forum.dlang.org/thread/hetwfhikjqwzlvywm...@forum.dlang.org). His idea was to enable it via mixins. Walter was reluctant to take that approach and suggested AST nodes should just be simple classes with fields and helper methods. That approach would simplify how AST families are created, but wouldn't fix the underlying issue of being unable to override a node's behavior. (Also see [Razvan's DConf '23 talk on the topic](https://youtu.be/eKT3MYpRgYA).) In the end, they agreed to refactor the AST implementation by pulling all semantic routines and fields out of the AST nodes so that `ASTBase` will only contain imports of AST nodes as opposed to the duplicate implementations it contains now. Once this is complete, they'll revisit Razvan's idea about the mixins. Razvan has since gotten started on this project. You can [track its progress in our project tracker](https://github.com/orgs/dlang/projects/41/views/1). He recently [published a blog post](https://dlang.org/blog/2024/02/22/dmd-compiler-as-a-library-a-call-to-arms/) as a call to arms seeking assistance. A handful of people have stepped up, but there's still a lot of work. Anyone looking to make some impactful contributions should read the blog post and [the relevant section of the contributor guide](https://github.com/dlang/dmd/blob/master/CONTRIBUTING.md#refactoring-the-dmd-ast) to learn how to help out. ## November We had one planning session in November. It was held the week before our monthly meeting. The main points of discussion were details about the Bugzilla to GitHub migration and more implementation details for DMD as a library. For the former, Robert had already migrated the Visual D issues and wanted feedback on the order in which to migrate the remaining projects. Everyone agreed he should go from the project with the lowest issue count to the highest. We also discussed some details about dlang-bot, how to handle attachments, and some more implementation details. The other issue was regarding `extern(C++)` classes in DMD. These are `extern(C++)` so that they're available to LDC, GDC, and any other future tools and compilers that need to integrate the D compiler into a C++ codebase. However, this had caused problems for people using DMD as a library in practice. For example, forgetting that the class is `extern(C++)` when subclassing it; this caused problems when trying to use features unavailable for `extern(C++)`, e.g., dynamic arrays. There was a workaround for that particular case, but a new one had popped up when the overriding class was templated and was instantiated with, e.g., a dynamic array type. Razvan expected this would continue to be an annoying problem and was looking for ideas to solve it. We discussed the possibility of making the DMD as a library classes `extern(D)` instead. Ultimately, the consensus was that though the visitor classes could be made such, there was no simple way to do it for the AST nodes. We have more important issues than this to focus on right now.
Re: D Language Foundation November 2023 Monthly Meeting Summary
On Monday, 4 March 2024 at 11:17:16 UTC, Sergey wrote: On Monday, 4 March 2024 at 11:07:07 UTC, Mike Parker wrote: snip Thanks for keep posting it just a bit awkward to read in March about November.. Yeah, sorry about that. I'll get caught up this month. Then I'll be back to posting them on a regular schedule.
D Language Foundation November 2023 Monthly Meeting Summary
# Summary The D Language Foundation's monthly meeting for November 2023 took place on Friday, the 10th, at 16:00 UTC. It lasted around one hour and ten minutes. ## The Attendees The following people attended the meeting: * Walter Bright * Martin Kinkelin * Mathias Lang * Átila Neves * Mike Parker * Adam D. Ruppe * Robert Schadek * Steven Schveighoffer * Adam Wilson ## The Summary ### Steve and Me I have to apologize to Steve. I managed to botch the initial recording, so whatever he and I said at the top of the meeting is lost. I'm pretty sure I talked about preliminary planning for DConf '24, but beyond that, I don't recall. I also know that whatever Steve reported, it wasn't anything that sparked debate. The first audible words I have from him are, "That's about all I have, really." ### Adam Ruppe (AR) __@standalone__ The first item on AR's list was the `@standalone` attribute that he had proposed in a previous meeting. He said he'd like to see something happen with that. [Dennis had a PR for it](https://github.com/dlang/dmd/pull/15537). AR had pinged him about it, and Dennis had made a few updates. He just wanted to make sure it wasn't forgotten. Walter asked for a link to the PR, and Adam said he'd get it to him later. (__UPDATE__: The PR was eventually merged and [released in DMD 2.107.0](https://dlang.org/changelog/2.107.0.html#dmd.standalone-attribute).) __String interpolation__ Next, AR brought up the string interpolation implementation. He said he had a quite a full implementation with a lot of examples down. He said that several people had tried it and even those who weren't convinced before had come around. He wanted to get that merged as well. Walter asked if there was a specification for it. AR said it was basically the same as DIP 1036, but slightly different. Walter said that's what he means; it needs to be a complete and correct specification for what the proposal is. AR said Walter could go read the code. Walter said we don't document things by telling people to go read the code. This sparked a discussion regarding the requirement for a spec and the history of string interpolation proposals. In the end, Átila offered to try out AR's implementation and write out the spec as he understood it, and asked if Steve or AR would be willing to correct it. Steve said it was just a simplified version of 1036, so it shouldn't take much time to write the proposal as long as it wasn't something that's going to be dead on arrival. Átila said he was volunteering to write the spec, but he was going to be on holiday for a couple of weeks and wouldn't get started on it until sometime after he got back. Walter said the last time he had reviewed the proposal, he'd been excoriated by people telling him "that's not what the actual implementation is." Steve noted that the proposal Walter had reviewed was an incomplete one by John and Andrei that they hadn't touched in years and said that Walter had misunderstood the point of some of the examples. Átila confirmed he would write the spec. Walter and Steve both said "all right." AR said he'd follow up on it because he really wanted to see it done. He'd used it in production and it was very useful. If Átila had any questions about what it did, he should try it. Átila reiterated that he was going to try it first and document it after, and would ask AR to correct his understanding if it was wrong. (UPDATE: Ultimately, [Átila finished the proposal](https://github.com/atilaneves/DIPs/blob/string-interpolation/Interpolation.md). After [a long discussion in the forums](https://forum.dlang.org/thread/unhv5u$1gps$1...@digitalmars.com), Walter approved the feature and [it was merged](https://github.com/dlang/dmd/pull/15715). Steven Schveighoffer [is working on a spec PR](https://github.com/schveiguy/dlang.org/blob/istring/spec/istring.dd).) __Bugzilla to GitHub transition__ Next, AR said people had been asking about the timeline for the Bugzilla to GitHub transition. Robert said he had tested the migration API with [the Visual D issues](https://github.com/dlang/visuald/issues) and that worked. But in a recent planning session, potential issues with the dlang bot had come up. He detailed his understanding of what the bot was doing and what he thought he needed to change to ensure everything keeps working post-migration. It was just a matter of making the time to investigate and implement everything. AR said it's fair to say we're probably still looking at several months. Robert said he'd do what he could to not make it that long. __Status of editions and the future of Phobos__ Next, AR asked about the status of the editions proposal and plans for the future of Phobos. He figured they would be related. Átila said the editions proposal wasn't finished yet, and he was now going to kick it further down the road to work on the string interpolation spec. Átila said AR was probably right that the
Re: The New DIP Process
On Thursday, 29 February 2024 at 05:44:08 UTC, Brad Roberts wrote: I set them up earlier today. It's entirely possible I missed something while configuring them as it's been just over 6 years since the last new group was added, so do shout if anything looks off. I see that the first two messages already posted made it through, so my confidence is reasonably high. Also worth noting, the news group names are NOT dip.idea and dip.development. They're actually digitalmars.dip.ideas (note the plural) and digitalmars.dip.development. I made the list names just dip.ideas@ and dip.development@ for brevity. Later, Brad Much appreciated, Brad!
Re: The New DIP Process
On Wednesday, 28 February 2024 at 19:24:32 UTC, Jonathan M Davis wrote: I see that they're up on the NNTP server, and the web forum is hooked up to them, but there is no mailing list. Is that forthcoming and just isn't up yet since that takes some time, or are these lists not going to have mailing lists like the others? They had to be up on NNTP for them to be added to the forums. I just didn't think about the mailing list. I'll contact Brad.
Re: The New DIP Process
On Wednesday, 28 February 2024 at 08:46:13 UTC, Richard (Rikki) Andrew Cattermole wrote: As it has already had a lot of back and forth from Walter and me with the help of Adam Wilson (very much appreciated!), it's ready for a development forum post. So Mike, once the forum is up, am I in the clear to start at development? https://gist.github.com/rikkimax/1d7cfdb8ed74e9e4efc9ba0208f42e7e Yeah, go for it.
The New DIP Process
After discussion in a recent meeting, we're ready now to start accepting DIPs for review. And that means it's time to announce the new process. The main goal of the new process is to reduce the amount of "process". The rules of the prior system were intended to create a moderately high barrier of entry in order to discourage frivolous proposals. In practice, they created an extremely high barrier of entry that also discouraged serious proposals, frustrated several DIP authors who went through the process, created too much of a time sink for everyone involved, and did not allow for early indication of the chances that an author's time and effort would result in a favorable outcome. The new system simplifies the process by putting most of the control in the hands of DIP authors. Some key points: * Feedback begins with the initial DIP idea. * The predefined review rounds are gone. * Multiple DIPs can be under review at the same time. * The DIP author decides when a draft is ready to submit for assessment. Most of the process takes place in two new forums: DIP Ideas and DIP Development (dip.idea and dip.development on the NNTP server). The purpose of the Ideas forum is to determine if developing the DIP is feasible. The purpose of the Development forum is to strengthen proposals in development. The process works as follows. * A potential DIP author (or someone looking for an author) posts a description of the idea in the DIP Ideas forum for community discussion and feedback. Periodically, I'll make sure Walter and Atila are aware of the new idea posts so they can provide their initial thoughts. This should give a potential author a good sense of the DIPs chances, e.g., great idea, go for it; maybe, give it a go if you'd like; no way, no how. Based on this feedback, the potential author can decide whether to proceed with development. * When an author does proceed, then once the initial draft is ready, they should make a new post in the DIP Development forum with a link to the draft for community feedback. They should address feedback as necessary by revising the DIP or explaining why they disagree. The author should expect to allow two or three weeks for feedback just to give stakeholders enough time to process it and formulate an opinion, particularly if they want feedback from Walter and Atila at this stage. * After at least two or three weeks of feedback, the author can contact me when the revised draft is ready. If the extent of revision is significant, I'll ask the author to make a new DIP Development thread for feedback on the new draft. Otherwise, I'll ask the author to submit a PR to the DIP repository. * When the PR is submitted, I'll merge it, assign a DIP number, edit as necessary, and email Walter and Atila for assessment. They'll have two weeks to review it (though depending on circumstances, we can extend that as necessary). As before, they'll accept it, reject it, or ask for modifications. I want to emphasize that though any DIP that makes it to assessment in this new process should theoretically have a strong chance of acceptance, there can never be a guarantee. For example, Walter or Atila or someone else may uncover a major overlooked flaw before the decision is made. Or an author may have proceeded with a DIP that Walter and/or Atila expressed skepticism toward at some point in the Ideas or Development forum and the DIP failed to convince. The key point is that we want the author to know before the first draft whether the DIP has a strong, weak, or near-zero chance, and during development whether they're generally going in the right direction, but no one can offer a 100% guarantee. All potential DIP authors should read the DIP Authoring Process doc here: https://github.com/dlang/DIPs/blob/master/docs/process-authoring.md Once the development is underway, the author should also read the Authoring Guidelines: https://github.com/dlang/DIPs/blob/master/docs/guidelines-authors.md I should note that while we still want the language of the final draft to be semi-formal to formal, it's not something the author needs to be overly concerned about during development. Once the PR is submitted, I'll clean up the language as much as necessary and check with the author to ensure I've not changed the meaning of anything. The guidelines describe some simple things the author can keep in mind during development, but getting the details right is the primary concern at that stage. Finally, I want to make it clear that the new forums will be heavily and strictly moderated. We want focused, on-topic discussion there. On the web interface, each forum will have a banner at the top of the page that includes a link to the forum guidelines: https://github.com/dlang/DIPs/blob/master/docs/guidelines-forums.md With the publication of this announcement, Vladimir will deploy the new forums when he's ready to do so. At that point, the
A Conversation with Razvan Nitu on his D Programming Language Work
A few days back, I sat down with Razvan Nitu for this month's Community Conversation. We talked about his path to D, how he got onto the core team, his work teaching D at university, mentoring SAOC, and more. https://youtu.be/Wndz2hLpbdM Thanks to Razvan for taking the time to do this. Look for the next episode on the last Sunday of March, when I'll upload my upcoming conversation with Dennis Korpel.
Re: DIP 1036e not on the DIPs list?
On Friday, 23 February 2024 at 23:30:26 UTC, kdevel wrote: The DIP 1036e is not listed in https://github.com/dlang/DIPs/tree/master/DIPs is this intentional? The DIP process has been closed for a while now. Atila did write a proposal for Adam's implementation, and I'll add it to the repo after I open up the DIP process again (reopening very soon). It won't be 1036e, though.
DMD Compiler as a Library: A Call to Arms
For the last few months, Razvan Nitu has been periodically working through a refactoring of the AST nodes in the DMD codebase. This is a necessary step in getting the DMD-as-a-library project closer to the finish line. It's not hard work, but it is a lot of work. Razvan still has to keep up with his other responsibilities, so he can't work on it full time. Now he's asking for help. You can find the details in his latest blog post: https://dlang.org/blog/2024/02/22/dmd-compiler-as-a-library-a-call-to-arms/ You do not need to be familiar with the DMD codebase to help out with this. In fact, it's a great way to start getting familiar with it. And this work is impactful. DMD-as-a-library is a priority project for us. The work being done here will be beneficial not only for third-party tools that would like to make use of the compiler's AST, but also for potential enhancements to the utility of the compiler itself, such as having it run as a daemon with a built-in LSP server. Once you've read the blog post, you can find more details in the updated contributor guidelines (also linked in the blog post): https://github.com/dlang/dmd/blob/master/CONTRIBUTING.md#refactoring-the-dmd-ast Thanks in advance to everyone who steps up to help with this.
Get Ready for DConf '24!
It's time to start thinking more seriously about that DConf talk you've been thinking about submitting: DConf '24 is tentatively scheduled for September 17 - 20. Symmetry Investments is again our host and primary sponsor. We'll be back for a third time at CodeNode, and we're working again with Brightspace Events to put it all together. If you'd like to submit a talk but aren't sure you've got anything to talk about, just take a look at our past [DConf and DConf Online editions](https://dconf.org) for inspiration. If you're using D for anything right now, then you've almost certainly got content for a DConf talk. I'll quote Ali's words of wisdom once more: Coming up with an idea for a talk is as simple as the way you use D. Just look at your code, and it makes a presentation... Never spoken at DConf? Never spoken at a conference at all? No problem. We've had a higher than usual number of first-time speakers at the past two DConfs and are always open to more. The DConf audience is always a friendly one. I plan to launch the website with the submission details in early March, with a deadline in late April. If you have something in mind and you'd like to send it in now, then please go right ahead. Here's the info we need: * The title * Duration (we're looking for talks of 30 - 45 minutes) * The intended audience (Beginner/Intermediate/Advanced/All) * The kind of presentation (talk/paper/panel) * The abstract (a brief summary; the "elevator pitch"; this will go on the website if selected) * The description (as much detail as you want to provide; some speakers have submitted outlines; portions of this may go on the website if selected) **Send your submission in either plain text or Markdown** to soc...@dlang.org. Please, no PDF, word processor formats, etc.
Google Summer of Code 2024 Application Submitted
I've just pressed the submit button on the GSoC 2024 application form. All we can do now is keep our fingers crossed that we're accepted this year. In the meantime, we can continue to update and refine the project ideas list: https://github.com/dlang/project-ideas So any submissions to the issues list there are welcome. I expect either Razvan or I will be updating the projects in the root directory after our monthly meeting this week.
Symmetry Autumn of Code 2023 Result
If you've been paying attention to the forums over the past few months, you'll have seen weekly updates from the three SAOC 2023 participants: Teodor Dutu (his third SAOC!), Emmanuel Nyarko, and Prajwal S N. Congratulations to each of them for making it all the way to the end. The work the put in was both well done and valuable for the D ecosystem. Additional congratulations are in order for Prajwal S N, whom the judges selected for the final $1000 payment and the free trip to DConf '24. Well done! Prajwal worked on modifying dfmt to use the DMD AST. Along the way, he made some improvements to dmd. He currently is working on identifying and fixing bugs and plans to get the new dfmt into a production-ready state. As for the other two, they are still going forward with their projects. Teo has worked on converting DRuntime hooks to templates during and between three SAOC editions. He [gave a talk about it at DConf '22](https://youtu.be/dsa8GWL6TUo). He's got the finish line in sight now. Once he crosses it, he says he'll be on the lookout for further opportunities to research and improve the D compilers. Emmanuel set out to hook D up to some C++ containers. He made a good bit of progress on that front and plans to continue. He tells me he will be looking for other opportunities to contribute to D beyond this project in the future. Thanks to Razvan Nitu and Mathias Lang for taking on the mentor role this time. Razvan mentored Teo and Prajwal, Mathias mentored Emmanuel. Thanks also to Átila Neves, Robert Schadek, and Jonathan M. Davis for serving as judges. That's a tougher job than one might think. As for the future, I can announce already that SAOC 2024 is a go. I'll put out the call for applications in a few months. Thanks to Symmetry Investments for their ongoing support for the D ecosystem through SAOC and more.
Google Summer of Code 2024
Applications for GSoC 2024 opened very recently and close on February 6. All of our information is in order on their website. Before submitting, we just need to ensure that our project-ideas repository is in good shape: https://github.com/dlang/project-ideas If there are any project ideas you'd like to add, feel free to do so. Just please pay attention to the README. Also, please keep the following in mind (from the GSoC FAQ): The GSoC 2024 program has some flexibility in the schedule for projects. The length of time allowed to complete a project can range from 10 weeks to 22 weeks for medium and large projects with the standard length of 12 weeks. Small projects can range from 8 to 12 weeks. GSoC Contributors and their mentors can decide together if a project should be extended to end a couple of weeks or so later. If you're willing to be a mentor for a GSoC project, please let me know. As for SAOC, the three participants submitted their final reports before January 22nd and the judges have reached a decision. I've informed the participants of their status. I'll announce the results as soon as all three have acknowledged my email.
Re: Preparing for the New DIP Process
On Tuesday, 30 January 2024 at 00:06:26 UTC, mate wrote: On Monday, 29 January 2024 at 12:34:05 UTC, Atila Neves wrote: I like private as it is now. Especially because if anyone wants it to be "class-private", they can do that anyway: write a class per module like one has to in Java. My 2 centimes (cos I live in Switzerland) is that if you're worried about too much code having access to your private functions, your module is probably too large. To get peace from the forum troll, it might be worth it to add a compiler switch `-privateToTheClass` which errors out when it finds more than one class per file. Let's shut this down please. Thanks.
Re: Preparing for the New DIP Process
On Sunday, 28 January 2024 at 22:31:59 UTC, FairEnough wrote: No more comments about this in this thread. I promise. Thank you. For those who don't consider it 'a pile of mush', here is where it 'can' be discussed (freely I hope): It can be freely discussed here, too. Just please stop hijacking threads to do it. As for "pile of mush", it's what the dead horse has been beaten into at this point.
A Conversation with Martin Kinkelin on LDC
Some of you may recall the two conversations I had with Walter a while back, part of what I called the 'D Community Conversations' series. I've long planned to get that going as a regular, monthly thing. Finally, the time has come. I want to thank Martin Kinkelin for agreeing to sit down with me to chat about his road to programming and to the D language, how he ended up as the lead maintainer of LDC, and some of the details about the role. I very much enjoyed our conversation. I hope you do, too. You can find it here: https://youtu.be/XpPV5OBJEvg The full playlist is here: https://youtube.com/playlist?list=PLIldXzSkPUXXEL-2gfragUgNC2P2Yw6au=jih87SW_4A7jwRt5 Look for the next episode on the last weekend in February.
Re: Preparing for the New DIP Process
On Sunday, 28 January 2024 at 04:47:30 UTC, FairEnough wrote: So 60 some odd posts later... If you want to beat this pile of mush further, please do it in a new thread. Going forward, any posts I see about private-to-the-module which are off topic in any given thread will be happily deleted. You've hijacked enough of them. Thanks!
DConf Online '24: Still have room for talks
If you waffled over whether or not to submit a talk for DConf Online '24, we still have space for some. If we don't get anymore, then it's going to be a one-day event. I'd very much like to make it two. I'll waive the requirement for a video submission. Just let me know the talk title and an abstract, with a bit of a description of how it will go. Remember, we want to keep them around 20-30 minutes.
Re: DConf Online '24: Still have room for talks
On Tuesday, 23 January 2024 at 15:40:02 UTC, Mike Parker wrote: If you waffled over whether or not to submit a talk for DConf Online '24, we still have space for some. If we don't get anymore, then it's going to be a one-day event. I'd very much like to make it two. I'll waive the requirement for a video submission. Just let me know the talk title and an abstract, with a bit of a description of how it will go. Remember, we want to keep them around 20-30 minutes. Oh, and the original announcement was here: https://forum.dlang.org/post/owawpppuujgemsuui...@forum.dlang.org
Preparing for the New DIP Process
A few months back when I announced in one of our planning updates that we were freezing the DIP queue to focus on stabilization, I noted that the DIP process was going to get an overhaul. I've since learned that this message didn't stick, so I'll paste here what I said then. --- The DIP process is getting a long-needed overhaul. Over time, I've had feedback from people who have authored DIPs and those who decided not to. There are a number of different opinions about how things can change, but there are some common themes among them. I'll write in more detail about this later, but there are a few major goals I have with the overhaul: * reduce the burden on the author * reduce the amount of time a submitted DIP is in review * establish support for fleshing out ideas before a DIP is even written * establish support for developing initial DIP drafts before they are submitted Previously, I'd always considered development of the DIP separate from the DIP "process", which I saw as beginning with the submission of a pull request. In reality, the process begins even before an author opens an editor to start typing. I hope that by recognizing that, and by providing support for discussing ideas and writing the DIP, we'll foster an environment that still maintains a relatively high bar for DIPs that get submitted, but also creates a filter such that potential DIP authors can be more confident that they aren't wasting their time once they get to the development stage. By the time they get there, they'll have no doubt if it's an idea worth pursuing. --- I'm getting ready to open things up again. The new process is going to be much, much looser than before. I'll have all the details in the announcement when we reopen, and I should be able to give you a general timeframe after our planning session tomorrow. I'm making this pre-announcement announcement now so that any authors with a DIP frozen in the PR queue can have a heads up. We'll need to treat these somewhat differently than new DIPs, but we'll be ready to get moving on them when the author is. It's entirely on the author's schedule, not ours. And if any of you are thinking about submitting a new DIP, I ask you to start thinking about the details, but don't start writing it just yet. Once the new process is open, you won't have to sit and write it in isolation with no feedback from Walter or Atila. You'll be able to get feedback early from both them and the community, so you can know very early on if it's something you're willing to pursue, and you'll hopefully have a good bit of help to get it developed. The process as it existed had a high bar with the intention of encouraging the production of quality DIPs and discouraging frivolous proposals. In practice, that high bar was a high barrier to entry and ended up discouraging even good proposals. I'm optimistic that the new process will lower the barrier to entry and still encourage quality proposals. And by "quality" I'm not referring to the quality of the DIP's language. In the new process, the focus will be entirely on the details of the proposal and not on the language in which they're presented. I'm happy to clean that up myself once a proposal is accepted. Just wanted to put out a heads up. More to come!
Re: Reminder: DConf Online '24 Submissions
On Monday, 1 January 2024 at 15:24:44 UTC, Mike Parker wrote: I'd like to remind everyone that we're accepting submissions for DConf Online '24 until January 14th. Please find the submission details in my previous announcement: The deadline is this weekend, folks!
Reminder: DConf Online '24 Submissions
I hope everyone had safe and happy holiday celebrations the past couple of weeks. I broke my toe in late November, so my holiday was rather subdued, but nice, nonetheless. I'd like to remind everyone that we're accepting submissions for DConf Online '24 until January 14th. Please find the submission details in my previous announcement: https://forum.dlang.org/post/owawpppuujgemsuui...@forum.dlang.org I've finalized the dates, so March 16 & 17 are locked in. I'll have the website live in a couple of days, with the submission details reprinted there. Happy New Year!
D Language Foundation October Monthly Meeting Summary
The D Language Foundation's monthly meeting for October 2023 took place on Friday the 13th at 15:00 UTC. It lasted around one hour and thirty minutes. I was unable to attend, so thanks to Razvan for running it and to Dennis for recording it. Two attendees were first-timers: Adam Wilson and Luís Ferreira. I invited Adam along after a conversation we had a DConf. Luís was originally supposed to attend the quarterly meeting the week before as a representative of Weka but had been unable to make it, so I invited him to this one. ## The Attendees The following people attended the meeting: * Andrei Alexandrescu * Walter Bright * Luís Ferreira * Timon Gehr * Martin Kinkelin * Dennis Korpel * Átila Neves * Razvan Nitu * Adam D. Ruppe * Steven Schveighoffer * Adam Wilson ### Razvan Razvan got started with an issue he had recently encountered with the inliner that he didn't know how to resolve. Normally, when module A imports module B and calls a function from B, then you'll end up with a linker error if B's object file isn't handed off to the linker, e.g., when compiling with `A.d` on the command line and omitting `B.d`. However, when the called function is inlined, no linker error is raised. He suspected this was an optimization. He'd found that this behavior breaks building with BetterC with the inline flag. He explained that the inliner runs after Semantic 3, but since B is not the root module some extra semantic stuff is done, and then you end up with `TypeInfo` errors. His first instinct was that this was a hack and that the inliner shouldn't be doing any semantic analysis. But if we change this, it might cause linker errors elsewhere. Walter said this was the first he'd heard of this. Why not just link in module B or add it as a root file? And why was it a particular problem for BetterC? To the former, Razvan said that's the way to fix the error. Then he asked if Walter agreed that the inliner shouldn't be doing any semantic analysis. Walter said he didn't know as he hadn't looked into it. He didn't remember that the inliner was doing semantic analysis. Razvan then asked if everyone agreed that compilation with and without the inline flag should yield the same result. Walter said not necessarily. If a function is inlined, you don't need to link it in. And to link it, you have to add it as a root module. So he didn't see why this was a problem and why it was a particular problem for BetterC. Steve said that the inliner had to semantically analyze the inlined code. So he asked if Razvan was talking about some other semantic analysis taking place, like on code that wasn't used. Razvan explained he was talking about the analysis the inliner has to do on inlined code when the imported module isn't a root module. Martin mentioned some LDC linker flags that require extra semantic analysis on things that would otherwise be linked externally. He said if something is a root module, it's going to be analyzed anyway, but if you just compile module A and it decides to inline another function that would otherwise not require semantic analysis, then yes... He wasn't sure he understood what the problem was here, but he could confirm that they'd had a problem a couple of weeks before. They were getting linker errors related to inlining, but it had nothing to do with separate compilation. He said that was a topic for later. Walter noted that if the inlined function from module B called any other functions from module B, then you'd see linker errors if B wasn't linked. Was that the problem? Martin said it wasn't the problem in their case. It was a unit test runner that included all of the code, so there shouldn't be any undefined symbols. Walter asked Razvan to clarify what sort of linker errors he was seeing. Razvan said it had to do with `TypeInfo` generation in BetterC code. The fundamental issue was that semantic analysis was being done when it shouldn't and `TypeInfo` was being generated. If you compile with `-betterC` but without `-inline`, you don't see the errors, but if you compile with both, you see them. Walter said that, okay, it was a `TypeInfo` issue. To figure that out, he'd have to trace through the code to understand why a `TypeInfo` was being generated in module B in that case. He couldn't think of a reason off the top of his head. Razvan suggested an alternative fix would be to only inline functions from root modules. Walter said that would never work. You wouldn't be able to have header-only libraries very well. He said the correct fix was to determine why a `TypeInfo` was being generated when it shouldn't be. Martin said LDC didn't have these kinds of issues with `TypeInfo` because it had a different emission strategy for them. He suggested DMD take the same route. For classes, the `TypeInfo` is always generated in the module which contains the class declaration. That was the same as DMD as far as he knew. Where
DConf Online '24 Call For Submissions
I'm happy to announce that DConf Online '24 is tentatively scheduled for March 16th & 17th, 2024. I should have the dates locked in for sure by the end of the year, at which time I'll publish the website and all the details. What I know for certain at this moment is that we'll be doing things differently this time around. Everything will be happening in the live stream (no more switching browser tabs between the stream and the talks), and the Q & A sessions with the speakers will be better integrated with the stream (no more Jitsi Meet). I'm looking forward to upping our game a little bit this time around. If you'd like to submit a talk for DConf Online, we're accepting submissions between now and January 14. If you've never presented for DConf Online, then your submission should be in the form of a short video presentation. Your submission video should be either 1080p or 4K. The only frame rate requirement we have is a maximum of 60 fps. The presentation should contain the details we need about the talk: * What kind of prerecorded session you plan to present -- we're looking for standard slideshow talks, active coding tutorials, and program demos, and are open to creative ideas. * How long you expect it to be -- we prefer sessions of about 20-30 minutes duration, but we can make exceptions if the content warrants it. * What it's about - walk us through your concept of the session from start to finish. Ideally, you'll present this as a slide show with your face in the bottom right or left corner of the screen. Your face doesn't need to be in either the submission or the final presentation, but it's our preferred format. Please upload the video to a cloud storage service and send a shareable link to soc...@dlang.org. You should include the following text in your email: * An abstract * A bio blurb If you've presented at DConf Online before, you can put all of this in text form. All accepted speakers will receive some DConf Online '24 swag and a small gift in gratitude for their participation. Also, we're open to ideas for events to hold once the regular talks are done. For example, Adam Ruppe has done a live coding session at each edition of DConf Online: * 2020 - https://youtube.com/live/0VfXqRW0yQo * 2021 - https://youtube.com/live/XuYcZPYWbKk * 2022 - https://youtube.com/live/V6KFtzF2Hx8 And last year [Brian Callahan put together a series of tutorial videos for a workshop](https://www.youtube.com/playlist?list=PLIldXzSkPUXWlvQmxrVBC-_n-RU7KPibA). So tell us about your projects, the problems you've solved with D, the algorithms you've applied, the process you went through in learning D, the first part of a talk that you'll want to continue later in the year at DConf '24, or anything you'd like to tell the world about your D experience. I'm looking forward to your submissions! And speaking of DConf '24, it's quite likely I'll be putting out a call for submissions again before DConf Online takes place. So do consider submitting to both :-)
D Language Foundation October 2023 Quarterly Meeting Summary
The D Language Foundation's quarterly meeting for October 2023 took place on Friday the 6th at 15:00 UTC. This was quite a short one as far as quarterlies go, clocking in at around 35 minutes. ## The Attendees The following people attended the meeting: * Mathis Beer (Funkwerk) * Walter Bright (DLF) * Dennis Korpel (DLF) * Mario Kröplin (Funkwerk) * Mathias Lang (DLF/Symmetry) * Átila Neves (DLF/Symmetry) * Mike Parker (DLF) * Igor Pikovets (Ahrefs) * Carsten Rasmussen (Decard) * Robert Schadek (DLF/Symmetry) * Bastiaan Veelo (SARC) ## The Summary ### Bastiaan Bastiaan reported that SARC had been testing their D codebase (transpiled from Pascal---[see Bastiaan's DConf 2019 talk](https://youtu.be/HvunD0ZJqiA)). They'd found the multithreaded performance worse than the Pascal version. He said that execution time increased with more threads and that it didn't matter how many threads you throw at it. It's the latter problem he was focused on at the moment. At first, they'd suspected the GC, but it turned out to be contention resulting from heap allocation. In Pascal, they'd heavily used variable-length arrays. For those, the length is determined at run time, but it's fixed. Since they can't grow, they're put on the stack. This makes them quite fast and avoids the global lock of the heap. One way to do that in D is to use `alloca`, but that's an issue because the memory it allocates has to be used in the same function that calls the `alloca`. So you can't, e.g., use `alloca` to alloc memory in a constructor, and that prevents using it in a custom array implementation. He couldn't think of a way to translate it. He was able to work around it by using allocators in the array implementation with a thread-local free list. He found that promising. His current problem was that it took a lot of time to understand the experimental allocators package. Once he got this sorted, he would have to see if it helped solve the problem they were seeing with more threads resulting in worse performance. There was also a problem with DMD underperforming Pascal. DMD's output was about five times slower than Pascal's. His tests with LDC showed it was two times faster than Pascal. Unfortunately, they are currently limited to 32-bit Windows, and it will be a few years before they can migrate to 64-bit. LDC unfortunately had an issue that [caused stack corruption on 32-bit Windows](https://github.com/ldc-developers/ldc/issues/4265). They'd hit it in one case and were able to work around it, but he couldn't be sure they wouldn't hit it somewhere else. He wasn't willing to risk unreliable computations. He said that LDC could do the right thing, but his understanding from talking to Martin was that implementing it would have a large time cost. Since Win32 is going to eventually go away, he wasn't very keen on paying that cost. They'd spoken at DConf about the possibility of LDC raising compilation errors when stack corruption could occur so that they could then work around those cases, but he hadn't followed up with Martin about it. They'd spent seven years getting the transcompilation complete, so this was a critical issue they needed to resolve. He was hopeful that the experimental allocator package would help solve it. Robert asked if he'd looked into doing something like the small string optimization, where you set a default size that you use for static arrays and then only resort to heap allocation when you need something larger. Had they analyzed their code to determine the array sizes they were using? Bastiaan said yes, a consequence of this issue was that they were linking with a rather large stack size. Walter suggested he just use `alloca`. Just have the transcompiler emit calls to `alloca` in the first lines of the function body for any VLAs and they should be okay. Bastiaan said they'd thought of allocating large chunks of memory up front and just picking off chunks of that for a custom allocator. That works very close to a free list, then he discovered the std allocator package has a free list. His experiments with that worked, but it had been challenging to implement it more generally. He said he would have to take another look at `alloca`. Walter said `alloca` wasn't used very much in D, but it's there. If he were to implement C VLAs, that's what he'd use to do it. Robert stressed they should analyze their code to see what a magic maximum number of elements is and just use that for static arrays, allocating on the heap when they need more. Static arrays and `alloca` were comparable to some degree. Maybe they could get away with that. It should result in cleaner code. Robert also suggested that since this project has been going on for so long and was a good showcase for D in general, Bastiaan should come back and ask for help even on more than a quarterly basis. We then had a bit of discussion about what it would take to fix the LDC
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote: ## Editions Átila took on the job of writing the proposal and we set November 1st as the deadline. We've since moved it to mid-December. I'm going to refrain from chiming in on this any further for now. I know what our goals are. I know that we've discussed much of what has come up in this thread (e.g., command-line flags vs. module attribute). I don't yet know what the draft proposal will look like. I can't say anything definitively until I've seen it. Our number one goal with editions is to avoid breaking code with new compiler releases. Old code, your project or your dependencies, should always compile, but still benefit from bug fixes in new compiler releases, ideally without any extra steps required from you. Átila has looked into Rust's editions, the proposal for C++ epochs, and probably some other stuff. So he's taking inspiration from those along with the discussions we've had so far. When the draft is ready, we'll publish it for feedback.
Re: DLF September 2023 Planning Update
On Wednesday, 15 November 2023 at 02:38:38 UTC, Adam D Ruppe wrote: On Wednesday, 15 November 2023 at 02:27:42 UTC, Mike Shah wrote: I just want to echo Steve's sentiment, that it should be easy for new (and old) D users to start up a project without worrying about editions. Actually, this brings another question to mind: what about old users who keep up with the language? Do they need to edit dozens or hundreds of files on each and every language update? (Of course, making a script do this for you wouldn't be especially difficult, but I don't trust scripts to edit my code soo lol and besides, what about things like ddoc examples, will it edit them too?) The goal is that you will never have to touch those dozens or hundreds of files when you update to a new version of the compiler. That old code will benefit from any bug fixes in the newest compiler versions, but will always compile. If and when you're ready to make use of a new feature from a newer edition, e.g., tuples from Edition N, then you take three steps: 1. fork your project 2. run the fix tool on however many modules/packages you want/need to 3. manually touch up whatever the fix tool couldn't handle automatically That should cover any modifications required for changed/removed features, and now you can use tuples in those updated modules. That's the idea, anyway, as I currently understand it.
Re: DLF September 2023 Planning Update
On Wednesday, 15 November 2023 at 02:27:42 UTC, Mike Shah wrote: I just want to echo Steve's sentiment, that it should be easy for new (and old) D users to start up a project without worrying about editions. Reducing friction is incredibly important for adoption and usage. If the library writer specifies the 'edition' within their own module and it's totally encapsulated, that seems fine -- I think that is what I understand from the editions proposal (and if they don't specify the edition, it defaults to whatever the compilers default edition is). It's just like any other language feature you have to learn. The documentation will be clearly divided by edition. You'll have one section for the base language (the default edition) and one for each subsequent edition. You can jump in an use the default language without caring about editions. Then when you want to learn more, say sumtypes and tuples from edition N, the documentation, tutorials, and example code you see should make it very clear that you need to specify edition N. And the documentation for edition N will explain all the changes that edition makes. If someone misses all of that and tries to use tuples without specifying edition N, the compiler should be able to tell them what the problem is, how to solve it (annotate your module declaration with `@edition(N)`), and provide the URL to the relevant documentation. The problem with changing the default for each compiler version means in effect there is no default, and downloading any new version means potential breakage that requires extra steps to fix, whether you're a beginner or not. We want to eliminate the need for extra steps.
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 17:57:36 UTC, Steven Schveighoffer wrote: That's not any better. If you have to opt-in to the language as it exists, people are going to quit immediately. I'm not joking about this. Imagine spending 2 hours trying to figure out why your app that is trying out some new feature doesn't compile, only to find out after posting online that it was looking at some ancient version of phobos. You won't have to spend two hours figuring out. If you use a feature from a later edition, the compiler will give you an error and tell you what you need to do. I think it's much more frustrating to pull down a new version of the compiler and find your current project breaks. You shouldn't have to change your code or adjust your build system to use a new version of the compiler. It should just work.
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 15:05:34 UTC, Steven Schveighoffer wrote: On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote: * Editions will most likely be implemented via an attribute on the module declaration. We haven't discussed any details about that, but for now, just imagine something like `@edition(2024) module foo;`. When considering how this should work, I would strongly suggest it be the default to work with the current edition of the language. Nobody wants to always have to attribute their module (or whatever other opt-in mechanism) to use current features. It's going to be a WTF moment for all newcomers to D. This brings us to the problem that no prior libraries have editions marked on them. So I think there needs to be an external mechanism to be able to set the edition for a package or module from the command line, or somehow in a config file. Or you can set the "assumed" edition using a switch (but it should still default to "current"). Experience with deprecations has shown people don't want to take extra steps to make their outdated dependencies compile. The goal with editions is that you should never have to take any extra steps to use older code in your program. You can't do that if the default edition changes with every new compiler release. But you can do that if each module explicitly declares which edition it needs. An option to specify the latest edition via the attribute came up in our discussions, so I'm sure we'll have that. And I anticipate there'll be some way to generate source files with the appropriately decorated module declarations, probably through third-party tools like code-d, maybe from a tool that ships with (or is built into) the compiler.
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 10:31:54 UTC, Mike Parker wrote: On Tuesday, 14 November 2023 at 09:51:29 UTC, Imperatorn wrote: Great summary. From the user side of things I think our best options are code-d and Visual D, but I haven't heard so much about Visual D-development plans. Do you know if there are any? Thanks! You'll have to ask Rainer about his plans for Visual D. I haven't chatted with him in a long while. And I should add that at some point, I do hope to be able to tell people about plans for Visual D. That's one of the projects we need to think about once we start discussion broader ecosystem plans.
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 09:51:29 UTC, Imperatorn wrote: Great summary. From the user side of things I think our best options are code-d and Visual D, but I haven't heard so much about Visual D-development plans. Do you know if there are any? Thanks! You'll have to ask Rainer about his plans for Visual D. I haven't chatted with him in a long while.
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 08:55:22 UTC, Nicholas Wilson wrote: I hope you mean "we will keep around old editions as (potentially command line) selectable options and we can update the default to be the current" No. The whole point is that old code will continue to compile without any special flags. We want to get out of this situation where an old but useful library stops compiling just because you use a newer compiler version on your project. The default edition doesn't change.
DLF September 2023 Planning Update
In September 2023, we had one planning session. The major item on the agenda was editions. Other items were a new meeting format, the Bugzilla to GitHub migration, and the future of D. ## Attendees The following people attended the session. * Walter Bright * Ali Çehreli * Martin Kinkelin * Dennis Korpel * Átila Neves * Razvan Nitu * Mike Parker * Robert Schadek ## Editions We had agreed in [the September monthly meeting](https://forum.dlang.org/post/hetwfhikjqwzlvywm...@forum.dlang.org) the week before that we need to define what editions will look like before we start deciding which features should go in any given edition. My goal with this session was to establish the first point on the timeline: a deadline for the editions proposal. I also thought it would be a good opportunity for all of us to clarify what editions are (there were some different ideas about that) and discuss aspects of the concept we need to consider. Here are some points that came out of the discussion. * Editions are essentially feature sets. Each edition can add/remove/deprecate features. * Editions are entirely opt-in and only affect the source you explicitly apply them to, i.e., they are not transitive to dependencies. * Editions will most likely be implemented via an attribute on the module declaration. We haven't discussed any details about that, but for now, just imagine something like `@edition(2024) module foo;`. * Features cannot be opted into individually. When you apply an edition to a module, you get the whole thing. * The default edition, meaning the code you have now, should compile forever. * We should have a tool that automates as much as possible the migration of modules to new editions * DMD-as-a-library is a critical component for that tool and other tools in the ecosystem. We need to put a priority on working out all the implementation issues Razvan has raised. * Given that much of the D community uses code-d, we need to bring Jan Jurzitza into any discussions about DMD-as-a-library. Átila took on the job of writing the proposal and we set November 1st as the deadline. We've since moved it to mid-December. One thing I'm looking forward to: editions will provide us with a framework to clearly define a roadmap for the language and the library. ## Workgroup sessions Our monthly and quarterly meetings have no fixed agendas. These are opportunities for each participant to report what they're working on and raise issues they'd like to see resolved. Our planning sessions are shorter, more focused meetings in which we resolve or decide how to proceed with a specific set of agenda items. I proposed we start having what I called "workgroup sessions", meetings aimed at hammering out details on bigger problems that can't be resolved in one meeting or by one person. DMD-as-a-library was a good example. This project had been in the works in one form or another for years. Razvan has been making an effort to get it to the finish line, but there were some critical issues to resolve in terms of interface and implementation. It took a large chunk of time in our September monthly meeting and external conversations with no resolution. Complex issues like this need a group of stakeholders focused on hammering out the details. We agreed I should set up a meeting. I noted who was interested in participating and took suggestions for other invitations. We ended up having two DMD-as-a-library meetings in October. I didn't participate, but I'll post an update on the outcome. ## Bugzilla to GitHub migration I've already written about this as an update note in the September monthly meeting summary, but this was the session where we agreed that Robert should be running the migration script instead of me. He just needed admin access to our GitHub repositories, and there were no objections to granting it. We agreed with Robert's proposal to migrate the VisualD issues first, then each project in order from lowest to highest issue count. I'll have more on this in upcoming summaries and updates. ## The future of D Robert had been itching to talk about our long-term plans for D. I think most of us understood that he was talking in terms of language features, but in this session, he explained that's not what he meant. D started as a successor to C and C++, but he doesn't see the language that way. He sees it as the best parts of C, Haskell, and Python. Others may see it differently. So how do we define the language going forward? What role do we want it to play? Are we mostly concerned with C-style stuff where every bit counts? Do we see D as a great tool for one-off scripts that would normally be written in something like Python? This prompted Walter to introduce the first draft of his Didactica, a list of the principles behind the language. That's the kind of thing Robert was looking for. Everyone looked them over and provided feedback. As I noted in the September
Re: DLF September 2023 Monthly Meeting Summary
On Monday, 13 November 2023 at 00:55:37 UTC, zjh wrote: On Sunday, 12 November 2023 at 19:50:02 UTC, Mike Parker wrote: https://gist.github.com/mdparker/f28c9ae64f096cd06db6b987318cc581 I can't access it,please post it here. I can't. It's too big. That's why I posted it there.
DLF September 2023 Monthly Meeting Summary
Well. For the first time in all my years of using these forums, I've managed to post something that exceeds the byte limit. You'll find the September 2023 Monthly Meeting Summary at the following link: https://gist.github.com/mdparker/f28c9ae64f096cd06db6b987318cc581
Re: Blog post: How we are using D to develop Aspect from the ground up
On Tuesday, 24 October 2023 at 08:01:59 UTC, Sergey wrote: Thanks for sharing it. I think this is nice article and it deserves to be posted on Reddit/HN resources. https://www.reddit.com/r/programming/comments/17fcsyg/using_dlang_to_develop_a_photo_organizer_app_from/
DConf '23 Day One Talk Videos
I've just pushed out Vijay's talk, the last from Day 1, to the DConf '23 playlist: https://youtube.com/playlist?list=PLIldXzSkPUXWH97DYBENhAqLk4DUqKUmf=any30KpW1hAki1IF Walter's talk will be up in a few days. I'll announce here again when all the Day 2 talks are up. Enjoy!
Re: From the D Blog: Crafting Self-Evident Code in D
On Tuesday, 3 October 2023 at 13:39:33 UTC, user1234 wrote: A message specifically dedicated for you, Mike. According to me there is a problem in the blog. Author and publication date should be put on top of an entry (currently the information are only at the bottom). Yes, I agree. That's the way it was before I switched from our custom theme to one of the default ones. When I get around to revamping the blog, I'll put them back on top.
From the D Blog: Crafting Self-Evident Code in D
It's been a long, long while since I published anything on the blog. I do intend to get pick it up again down the road, but Walter recently surprised me with plans of his own. He's taken the topic of his DConf '23 talk and derived a blog post from it: https://dlang.org/blog/2023/10/02/crafting-self-evident-code-with-d/ I guess he got impatient with the pace at which I'm getting the talk videos uploaded :-) And for anyone who'd like to engage in any Reddit discussion that comes up: https://www.reddit.com/r/programming/comments/16y2h36/crafting_selfevident_code_in_dlang/
Re: DConf '23 Talk Videos
On Thursday, 21 September 2023 at 11:58:17 UTC, Mike Parker wrote: The service center gave me a replacement. It has 12GB VRAM vs the 10GB of the original, so it's turned into a free upgrade. I guess I do get lucky sometimes. And I'm back in business. The video of Timon's talk is here: https://youtu.be/v-SHpG2rNWM
Re: SAOC 2023 Projects
On Thursday, 21 September 2023 at 16:12:45 UTC, Mike Parker wrote: * __Replace DRuntime Hooks with Templates__: Teodor Dutu is * __Replace libdparse with the DMD Library in dfmt__: Prajwal S I managed to leave out that Razvan Nitu is mentoring both of these projects.
SAOC 2023 Projects
Milestone 1 of the sixth edition of Symmetry Autumn of Code kicked off on September 15th! We have three coders hacking away on D projects for the next four months. You should be reading their first weekly forum updates very soon. So here's what's happening this time around: * __Replace DRuntime Hooks with Templates__: Teodor Dutu is back for a third stint in SAOC. Not only has he worked on this project in two previous SAOCs, he's been working on it in between when time allows. [The abstract of his DConf '22 talk](https://dconf.org/2022/#teodord) provides an overview of the project (or [you can skip straight to the video](https://youtu.be/dsa8GWL6TUo)). * __Interfacing D with C++ Associative Containers__: Emmanuel Nyarko is a first-time SAOC participant who aims to improve D's interface with the C++ standard library. Specifically, Emmanuel will be working on bindings for the C++ `std::set`, `std::map`, and `std::unordered_map` containers. Mathias Lang is the mentor. * __Replace libdparse with the DMD Library in dfmt__: Prajwal S N, another first-time SAOC participant, will be working towards removing libdparse from [the dfmt tool](https://github.com/dlang-community/dfmt) and replacing it with DMD as a library. You may recall that Lucian Danescu did some work in SAOC 2022 to enable DMD to be used as a replacement for libdparse in tooling, specifically targeting D-Scanner (you can [watch his DConf '22 talk](https://youtu.be/JYkb3PjIn4c) if you need to refresh your memory). This new project will get us closer to having a DMD-as-a-library tooling ecosystem. This year's judges are Átila Neves, Robert Schadek, and Jonathan M. Davis. Thanks to Symmetry for continuing to fund this event every year, and good luck to the three programmers working to improve the D ecosystem!
Re: DConf '23 Talk Videos
On Thursday, 21 September 2023 at 11:17:29 UTC, Steven Schveighoffer wrote: A family friend had the exact same thing happen. It was a software change to get them spinning again. The service center gave me a replacement. It has 12GB VRAM vs the 10GB of the original, so it's turned into a free upgrade. I guess I do get lucky sometimes.
Re: DConf '23 Talk Videos
On Thursday, 21 September 2023 at 01:11:13 UTC, matheus wrote: Not a HW expert, but lowering the GPU settings couldn't at least get the job done (Slower but... done). Not in this case. Turns out the graphics card's fans have stopped spinning. He's taking it to the service center today.
Re: DConf '23 Talk Videos
On Wednesday, 20 September 2023 at 22:04:25 UTC, Jonathan M Davis wrote: Clearly, your computer is just sick of hearing about dconf and decided to go on strike. ;) You're the second person to tell me that :-)
Re: DConf '23 Talk Videos
On Wednesday, 20 September 2023 at 08:41:01 UTC, Stefan Koch wrote: My feeling is this could be a faulty power supply. You should try a new PSU first. How old is the hardware? It's a two-year-old box. Yes, it could be the PSU, but in my experience when they go bad it manifests in more than one way. I've had a couple of them fail over the years. At any rate, the guy I took it to will zero in on it. I'll have a definitive answer tomorrow. If I'm lucky, a full internal cleaning of the graphics card and some new thermal paste will solve it. I'm usually not that lucky, though :-)
Re: DConf '23 Talk Videos
On Sunday, 17 September 2023 at 15:35:59 UTC, FeepingCreature wrote: Thank you for your work! You're welcome! Unfortunately, last night my GPU started to consistently overheat and shut down when doing anything graphics intensive, including rendering video. I've done everything I can reasonably do locally, so today I'm going to see if my goto computer dude can make room for me. Either he'll fix it or I'll buy a new card from him. How soon I'm able to render again depends on how soon I can see him. I don't want to just go out and buy a new gpu unless I absolutely have to.
DConf '23 Talk Videos
I've begun editing, rendering, and publishing the standalone videos of the DConf '23 talks. The venue gave us access to all of their footage this year rather than just a subset of it, and I'm happy to make use of it. I've also got the benefit of AI subtitle generation built into the latest version of the editor I'm using. It does an amazing job of it. The first video required only very minor tweaks. The upshot is that if you have English CC enabled, you'll get a more accurate script than the auto-generated one from YouTube. The first video, Saeed's talk, is live: https://youtu.be/cN0zS04wOFU Please let me know if anything is problematic with the video and of any errors you happen to find in the subtitles. I'm not going to announce every video I publish. I'll announce when I'm finished with all of them. If you're not subscribed to the channel, you can periodically check the DConf '23 playlist for updates: https://youtube.com/playlist?list=PLIldXzSkPUXWH97DYBENhAqLk4DUqKUmf=kpEpj3Y_A5zSAoVT I'll try to publish a new one every two or three days, but I've got a lot going on right now and make no promises. If you want to keep up with my progress on the DConf videos and other tasks related to the DLF's YouTube channel, you can follow the project tracker here: https://github.com/orgs/dlang/projects/40
Re: DConf '23 Livestream Links
On Tuesday, 22 August 2023 at 14:31:17 UTC, matheus wrote: I just hope we don't have the old "split" slides with presenter. I have eye impairment and the last one was hard to watch. I'll talk to the video crew and ask them to show more of the fullscreen slides and less of the split screen.
DConf '23 Livestream Links
The countdown is on! We're a week away from the first day of DConf, and that means it's time to schedule the livestreams. If you can't be there in person, this is the next best thing. When you're watching the livestream, feel free to type questions at any point during the talks. Someone will always be monitoring the livestream chat and will ask your questions on your behalf. * [August 29 (Day 1) Livestream](https://www.youtube.com/live/uzuKqiFVNZM?feature=share) * [August 30 (Day 2) Livestream](https://www.youtube.com/live/wXTlafzlJVY?feature=share) * [August 31 (Day 3) Livestream](https://www.youtube.com/live/CMrb6ZWhqXs?feature=share)
D Language Foundation August 2023 Monthly Meeting Summary
The D Language Foundation's monthly meeting for August 2023 took place on the 11th. At just under 35 minutes, it was our shortest monthly meeting to date. ## The attendees The following people attended the meeting: * Walter Bright * Ali Çehreli * Martin Kinkelin * Dennis Korpel * Mathias Lang * Átila Neves * Mike Parker * Adam D. Ruppe * Robert Schadek * Steven Schveighoffer ## The summary ### Me I had nothing new, other than to say that DConf planning was on track. ### Adam Adam had nothing for us this time. ### Robert Robert said he was happy. Dennis asked if the compiler was fast enough (as regular readers of these summaries may know, Robert often says the compiler is too slow). Robert said it's still slow. He just wanted to see LSP support in the compiler and take all the good things. Walter noted he'd been working on improving compilation speeds. He'd realized that the compiler was being compiled with exceptions, so he'd been working on making it compile without exceptions to see what effect that had on speed. It might be a small difference, but every little difference helps. Adam said his library compiled in half a second. Robert said that was still too slow. His work project didn't compile in half a second. He said his goal was that by the time of the key-up event after pressing 'Enter' on Ninja or whatever build tool/compiler he's using, it should have already restarted the application. Átila agreed that half a second was too long. Adam brought up D1. An old game he wrote back in 2007 compiles and links in 10 milliseconds. If you looked at a big chunk of the difference between D1 and D2, `object.d` back then was around 600 lines. Now it was much bigger, and that adds up. Walter said that he was a bit upset with the state of `object.d`. It was supposed to be a minimal thing and had turned into a kind of garbage dump somewhere along the way. ### Steve Steve said that Dennis had been doing a fantastic job with his PR on the compiler part of static associative array initialization. Steve thought it was about ready to go if someone could push the button. He didn't want to be the one to push it, because he didn't know the compiler code very well and couldn't vouch for its correctness. ([The PR is still open](https://github.com/dlang/dmd/pull/15468) as I write.) ### Dennis Dennis said he'd been working on that AA PR, but had nothing else to report. He still had some other things to pursue, like looking at pattern support for the deprecation (-d/-de/-dw) and obsolete warning (-wo) switches, as well as the `standalone` attribute or pragma for static constructors. ([In our July monthly](https://forum.dlang.org/thread/amsduzcnbgvptaxjt...@forum.dlang.org), Adam proposed a means to annotate static constructors that could make them independent of cycle detection. [In a subsequent planning session](https://forum.dlang.org/thread/vccxtwaaxqxxjojgx...@forum.dlang.org), we agreed to implement it. Since the August meeting, [Dennis has submitted a PR](https://github.com/dlang/dmd/pull/15537) for the `@standalone` attribute, but in the PR discussion thread, Walter thinks it should be a pragma.) ### Martin Martin said the bump to version 2.104 of the frontend went well on the LDC side and was quite painless. Next, he had an interesting side note inspired by [a forum post he'd seen](https://forum.dlang.org/thread/ofbvqasfvxylbxxpw...@forum.dlang.org) about getting LDC to work on a 8-bit AVR platform. He'd looked into it and found it an interesting question in terms of whether and how we want to support architectures with pointer sizes less than 32 bits. Currently, the frontend has a hard-coded limit: `size_t` and `ptrdiff_t` are either 32 or 64 bits, nothing lower than that. It's a frontend check, and the definitions in DRuntime directly depend on the compiler's internal type because they use the `typeof` expression. He had tried to make the frontend accept 16-bit and 8-bit `size_t` and `ptrdiff_t`, but doing that bumps up against the integer promotion rules. The promotion rules can work in some specific cases when using a smaller `int`, but when you have something like the length of a slice and do a little plus one or minus one, that's a problem. You need to cast it. So either we need to change dealing with the promotion rules in this regard, try to mimic C++ in this regard, or hopefully do something better. He said Adam had proposed something in a past discussion that would handle it generically so it's still target independent. Walter wondered if Rust supported less than 32-bit compilation and what compromise they made for that. Martin said he wasn't sure. He'd only checked C and C++. Robert looked it up and found that Rust has a tiny bit of support for 16-bit MSP340, but it's a big asterisk and everything else is 32 or 64. Martin wasn't sure if it was even worth looking into these architectures, because he had no idea how long they'd be
D Language Foundation July 2023 Monthly Meeting Summary
The D Language Foundation's monthly meeting for July 2023 took place on the 14th. It lasted roughly one hour and forty-five minutes. John Colvin, who has participated in several quarterlies representing Symmetry, joined us for the first time as a permanent member of the monthlies. ## The attendees The following people attended the meeting: * Walter Bright * Iain Buclaw * Ali Çehreli * John Colvin * Dennis Korpel * Mathias Lang * Razvan Nitu * Mike Parker * Adam D. Ruppe * Robert Schadek * Steven Schveighoffer * Nick Treleaven ## The summary ### Me I opened with an update on DConf preparations. I had been able to compile a solid estimate of how much we'd need to pay out in travel & lodging reimbursements. The total allotted for reimbursements from Symmetry's budget coupled with the revenue from registrations and additional sponsorship would be enough to cover it all. I was optimistic that we'd be able to make enough room in the budget for some catering upgrades. (I can now say that we were able to get two upgrades to the breakfast selection and one for lunch. At this point, we're expecting around 75 attendees.) ### Adam __Standalone static constructors__ (First, some background. At one point during [the June monthly meeting](https://forum.dlang.org/thread/jekkkcemzjaxcybgv...@forum.dlang.org), we got off on a tangential discussion about cycles when running static constructors. Essentially, static constructors can get into a circular dependency situation when other modules are imported and execution will abort with a "cycle detected" error even if the constructor itself has no dependencies. Adam suggested a couple of approaches to solving the problem. To get us back on topic, I proposed we put it off for a future meeting. I then followed up with Adam and he gave me a short proposal showing what he had in mind. I emailed the proposal to everyone before this meeting.) Adam proposed that we introduce a new annotation that can be used on static constructors to tell the compiler that they have no dependencies. Then the compiler could add them to a separate list for which cyclic dependency checking is turned off. Walter said we already had a mechanism for that in the form of `pragma(crt_constructor)`, which designates a function to be executed by the C runtime during startup. Adam reminded Walter we had discussed this last time. The problem with that is that CRT constructors are executed before DRuntime is initialized, so any static constructor that depends on DRuntime can't be a CRT constructor. Walter asked how this could be implemented. Adam said that the implementation for it is already in DRuntime. Steve clarified that the compiler can decide in certain cases that a standalone static constructor will not participate in cycle detection. Those constructors are not required to run in any specific order, so they're handled separately from those that are. That's what Adam was referring to. Since we already have a way for the compiler to flag standalone static constructors, he was just asking for a way that the user could tag a static constructor as standalone to go onto that same list. Walter said he had recommended to people in the past that the way to avoid cycle detection on static constructors is to put them in their own module with no additional imports. Then they'll be standalone. Adam said that was unrealistic. Walter said his resistance to Adam's idea was rooted in a reluctance to change the language to do things that can be done, maybe not perfectly but at least reasonably, in other ways. Also, did we really need this? Not this feature in particular, but any we consider. Because if not, the language becomes full of clutter. And that's not good for any of us. Is there any way we can do this without adding a new feature to the language? Walter also noted that allowing people to do this would add a bit of unsafety to the language. They may be mistaken about whether a static constructor has dependencies. It may work on one system and break on another because there would be no guarantee on the order in which it's run. The whole idea behind the ordering of constructors is to remove the responsibility from the programmer of trying to figure out in what order they are going to run when he may have no idea in what order they need to run. At the very least, such a feature would have to implicitly be `@system`. So are there other ways to do this? Are they reasonable or unreasonable? Walter then asked how many times Adam had found a clear need for standalone constructors in a program. Adam cited his "JNI interop thing". It generates other static constructors to register classes with the Java runtime. That's an independent thing, but because it's done by a mixin it can't be set off in its own module. So if you were able to mark it as independent, you could avoid cycle detection. Walter wanted to know why putting the mixin in a separate
D Language Foundation July 2023 Planning Update
We had two planning sessions in July, one on the 21st and one on
the 28th.
## Language Editions
### Background
I first reported on our new deprecation policy in [my June
Planning
Update](https://forum.dlang.org/post/jmtcppvsweimsojla...@forum.dlang.org). Later, Walter expanded on that in a forum post titled ['Evolving the D Language'](https://forum.dlang.org/post/u87vfb$1b9h$1...@digitalmars.com). The TL;DR:
* we will be much more conservative with deprecations
* Walter is evaluating current deprecations to see if they're
unnecessary or causing problems and reverting them if so
* we should strive to compile obsolete code by default, i.e.,
features that would otherwise be deprecated, but where possible
provide a means to opt-in to warnings about its use (in the form
of the `-wo` switch) rather than taking the opt-out approach of
deprecation
These changes are rooted in our new vision statement:
To enable the realization of ideas by shifting the way
programmers think.
Our approach to deprecations was a hindrance to the realization
of ideas and so was not aligned with our vision. The changes are
aimed at decreasing breakage and increasing the odds of success
when someone tries to compile an older D library with a newer D
compiler, goals that will enable the realization of ideas.
### The decision
In the face of these changes, how can we continue to evolve the
language? That was the big question we set out to answer in our
first July planning session.
Átila has mentioned language editions in his talks for [DConf
Online 2021](https://youtu.be/UqW42_8kn0s?t=961) and [DConf
'22](https://youtu.be/p1Q2DfYBw-w?t=1848). The topic has also
come up in recent meetings, most recently in our July monthly
meeting. After much discussion in the planning session, we agreed
that editions look like the best way for us to maintain backward
compatibility while still evolving the language without suffering
the hard split of a major version change.
[The planning update I published in
May](https://forum.dlang.org/thread/mqwhekbqqkabdvqpd...@forum.dlang.org) listed the three high-level goals we've set ourselves. One of them is to stabilize the language, so we aren't currently implementing new features. We'll revisit these goals down the road and, at some point, we'll add "evolve the language" to the list. Before that day comes, we need to have our policy on language editions in place.
To that end, Átila volunteered to draft a proposal. When he
brings it to us, we'll review it and shape it up as needed, then
ask for community feedback.
One consequence of this is that DIP 1000 will not be enabled by
default until we can do it in a new edition. The warnings about
scope parameters, which are errors when DIP 1000 is enabled, will
remain behind the `-wo` switch. Additionally, Dennis is going to
see about adding support for filters to `-wo`, `-d`, `-de`, and
`-dw` so that you can, e.g., enable warnings about obsolete code
for your codebase and keep it off for dependencies, and shut off
deprecation messages for dependencies while keeping them on for
your codebase.
## New Annotation for Static Constructors
### Background
In [our June monthly
meeting](https://forum.dlang.org/post/jekkkcemzjaxcybgv...@forum.dlang.org), we discussed the problem that DRuntime sometimes aborts execution of static constructors with a "cycle detected" error when modules with static constructors import other modules with static constructors. There should be a way to prevent that when a constructor is truly standalone. The workarounds Walter always suggests are to either put the constructor in its own module with no other imports or to tag it with `pragma(crt_constructor)`. Adam Ruppe and Steven Schveighoffer insisted that isn't always feasible.
Adam came to our July monthly meeting with a proposal: we should
implement a new annotation that users can apply to a static
constructor to indicate that it is standalone and should be
excluded from cycle detection. The result of that discussion was
that Walter asked Adam and Steve to provide example code showing
when neither of the suggested workarounds is possible.
In the days after the monthly, I followed up with Adam and Steve.
They gave me their example code, and I brought it to the first
July planning session.
Steve's example:
```d
__gshared string[string] dict;
shared static this() {
dict = ["a" : "b"];
}
```
There are two arguments here: this can't be a CRT constructor
because it depends on DRuntime, and arguing that it should go in
its own module is a QoL issue---we can make that case for classes
when you want private-to-the-class rather than
private-to-the-module because the language is working as
intended, here it isn't.
Adam's example:
```d
__gshared Object function()[string] factories;
Object build(string s) {
return factories[s]();
}
mixin template Register() {
shared static this() {
Re: pragma lib doesn't support static libraries?
On Sunday, 30 July 2023 at 05:28:32 UTC, ryuukk_ wrote: I should have explained exactly what i am doing.. Looks like it doesn't work when i compile in 2 step - compile with: ``dmd -c of=bin/game.o`` - link with: ``dmd bin/game.o`` When doing it this way, then it doesn't work However, when compiling/linking in one ``dmd`` invocation (without ``-c``), then it all works So it looks like the pragma is not passed on the linked when it was compiled with ``-c`` Is this a bug? should i report it?, or is that the expected behavior? It's expected behavior. There's no link step in the first command, so the pragma is meaningless there. And I'm unaware of any mechanism for embedding static library names in an object file for a linker to read later.
D Language Foundation July 2023 Quarterly Meeting Summary
I mistakenly posted the summary in the General forum. You can find it here: https://forum.dlang.org/thread/jzlympfqmwckaiuhq...@forum.dlang.org
Re: Designated initializers to function argument
On Friday, 28 July 2023 at 21:07:47 UTC, bachmeier wrote: On Friday, 28 July 2023 at 17:07:37 UTC, IchorDev wrote: No shit, it felt like an eternity. But it's still not in the spec...? I'd expect it to appear in the spec after there's a real release. This is the first I've heard of it being supported, and it sounds like it's incomplete. https://github.com/orgs/dlang/projects/19 Dennis has been working on this in pieces rather than all at once, as it required modification to multiple parts of the compiler.
Re: D Language Foundation June 2023 Monthly Meeting Summary
On Thursday, 13 July 2023 at 14:00:49 UTC, Mike Parker wrote: said in the chat window that this is a straight-up bug). Átila had also learned that static constructors should always be `nothrow`. Walter said he couldn't see why anyone would write a static constructor that throws. Átila said the point is, it's not muscle memory. It's easy to forget to add `nothrow`. Walter asked him to file an enhancement request on Bugzilla to make static construction `nothrow`. I forgot to add the follow up on this. Átila did open the issue, and Razvan submitted a PR to see what breaks. https://issues.dlang.org/show_bug.cgi?id=23973 https://github.com/dlang/dmd/pull/15318
D Language Foundation June 2023 Monthly Meeting Summary
The monthly meeting for June 2023 took place on Friday the 2nd at 15:00 UTC. It lasted about an hour. We had three new faces for this one: Adam D. Ruppe, Steven Schveighoffer, and Nick Treleaven. I'll be sending them invites to all of our future monthlies, but we've left it up to them to decide if they want to become regular or part-time members. The following people attended: * Walter Bright * Ali Çehreli * Martin Kinkelin * Dennis Korpel * Mathias Lang * Átila Neves * Razvan Nitu * Mike Parker * Adam D. Ruppe * Robert Schadek * Steven Schveighoffer * Nick Treleaven ## The summary ### Me I opened with a reminder that Razvan had sent most of us an email reporting that he had set up an initial set of projects on [our GitHub Projects page](https://github.com/orgs/dlang/projects?query=is%3Aopen) as we'd decided in our planning sessions. The projects were all private. I emphasized that once we made them public, we needed to start focusing on them. The project list should become part of our regular workflow. I asked that everyone look over the project list and make sure they're okay with it, after which we could make it public. (We have since done so.) Razvan said that when any of us submit a PR related to one of the projects, we should add it to the project so that anyone who wants to can follow along. Dennis said he was excited for us all to start using organized task lists, and Walter thanked Razvan for setting it up. Next, I gave an update on the DConf submissions. We'd received 39 submissions from 20 people and 1 team. We had already begun the selection process. I and one other person had made our selections and I was still waiting for two more. I reminded them that I wanted to publish the schedule as soon as possible, so I asked that they get their choices made over the weekend. (The four people making the selections were Walter, Átila, Ali, and me. I had all of the selections by Saturday night my time and subsequently informed all of the submission authors of their status.) Finally, I told everyone about a conversation I'd had with someone who was planning to submit a proposal to add slices to C. Walter was happy to hear about that, as he had been informally pushing for that for years. He talked about his article on the topic ([C's Biggest Mistake](https://digitalmars.com/articles/C-biggest-mistake.html)) and how C++ had copied that mistake. He says it can be backward compatible in C and analogous to D's slices, it just wouldn't allocate memory for you. ### Robert Robert said his biggest gripes had been added to the project list, so he was a happy camper. Other than that, the only thing he had to report was an update on the Bugzilla to GitHub migration. At the time, I had done some testing with the program he wrote for it and found some problems with it, so he was going to work on fixing those and improving the usability. I had set up a dummy repository to test it out on and he would use that for further testing. (He got it back to me a couple of weeks later. I have since submitted two forum posts ([post one](https://forum.dlang.org/post/pfpoeaoihsqpohumj...@forum.dlang.org) and [post two](https://forum.dlang.org/thread/kttzxwbbvdpzxlmoy...@forum.dlang.org)) soliciting feedback and providing updates. You can track the progress on this task in our [Enhance the Ecosystem project](https://github.com/orgs/dlang/projects/23?pane=issue=29572916).) ### Mathias Mathias had nothing to report. ### Martin Martin had been on vacation, so had nothing completed to report on. His immediate plans were to finalize the LDC 1.33 release, which was based on D 2.103, then get to work on the 2.104 merge. (He announced [the first 1.33 beta on May 14](https://forum.dlang.org/thread/umxjxuzvitbnmtezw...@forum.dlang.org) and [the second on June 11](https://forum.dlang.org/thread/jmshfqmyceakivyhs...@forum.dlang.org)). ### Dennis Dennis was in a car, so was only listening. ### Ali Ali had nothing to report. He was still using D at work. He was happily producing successful stuff with it. ### Razvan __An issue with runtime hooks__ Razvan opened by reminding everyone that Teodor Dutu was still working on converting DRuntime hooks to templates and that the project was part of a major goal we had set to get to a pay-as-you-go DRuntime (which you [can follow on our project tracker](https://github.com/orgs/dlang/projects/34)). He had noticed that some of those hooks are [implemented in rt/lifetime.d](https://github.com/dlang/dmd/blob/master/druntime/src/rt/lifetime.d). Nothing in the `rt` package is supposed to be imported outside of the `rt` package itself (see [the DRuntime README](https://github.com/dlang/dmd/blob/master/druntime/README.md)). However, `object.d` needs to use some of those hooks, so it declares `extern(C)` function prototypes to make that possible. He asked if anyone knew why we were doing it that way. Mathias said it's just for historical
Re: Anyone interested in mentoring?
On Wednesday, 12 July 2023 at 16:56:45 UTC, Emmanuel Danso Nyarko wrote: Thank you very much Mike. Will early submissions help my application? No. That's not a factor in the selection process.
Re: Anyone interested in mentoring?
On Tuesday, 11 July 2023 at 02:18:34 UTC, Emmanuel wrote: I would like to work on the interoperability between C++ associative containers and the D language. Is this for a SAOC project application? If so, please feel free to submit the application without a mentor attached. If you later find one before the deadline, you can let me know and I'll amend the application. You might also ask in the community's Discord: https://discord.com/invite/bMZk9Q4
Re: D Language Foundation Monthly Meeting Summary for May 2023
On Tuesday, 27 June 2023 at 12:36:20 UTC, Sergey wrote: After that real person could verify result and make small corrections. It should significantly reduce effort and decrease time-to-market :) Yes. The next version of Davinci Resolve (which I use for video editing) will have automated transcriptions. Once it's released, I intend to start loading my meeting recordings into it and then derive my summaries from that. However, I still will write the summaries as summaries, rather than publishing the transcripts directly or otherwise quoting them verbatim. This will save me from having to go back and forth through the video, so it will certainly save time. I still will put at least three or four weeks between the meetings and the summaries. One benefit I've found in the delay is that it's an easy way for me to follow up on any actionable items. As I'm writing a summary, I can check on the status of issues, follow up with anyone who said they'd do something, etc. Then I don't have to worry about taking notes during the meeting, I can add the current status directly into the summary, and anything that's not done by the time I write it up I can stay on top of.
Re: A New Era for the D Community
On Tuesday, 27 June 2023 at 12:00:48 UTC, Mike Parker wrote: Anyway, the main point of this announcement wasn't IVY, it's that we're finally getting organized. IVY is just the tool we're using to do it. No D user or contributor needs to pay any attention to it if they don't want to. And I should add, for those who haven't seen it elsewhere, one of the changes we've made is that we've incorporated GitHub projects into our workflow (some of us more quickly than others). You can see what we're working on here: https://github.com/orgs/dlang/projects?query=is%3Aopen And if anyone sees something they'd like to pitch in on, please get in touch with me.
Re: A New Era for the D Community
On Tuesday, 27 June 2023 at 11:30:42 UTC, Francesco Mecca wrote: It would be great if you specify or at least give us a glimpse of what this "change" is about. Right now, it sounds like corporate propaganda for Ucora It's not propaganda. I answered questions about it in BeerConf last month, and Adam summarized it here: https://dpldocs.info/this-week-in-d/Blog.Posted_2023_05_29.html TLDR; it's about understanding stakeholder motivations and looking for opportunities where they align. Right now, we're just employing it internally to get our house in order. Down the road, when we're able to find volunteers to take on tasks (a few people have expressed interest already after the BeerConf session), understanding their motivations will help us know who to approach first for any given task. That's just one way in which we'll be employing it. It's helped me in recognizing opportunities I wouldn't have before, and it's had an impact on the way the DLF team conducts meetings and approaches problem solving and planning. Anyway, the main point of this announcement wasn't IVY, it's that we're finally getting organized. IVY is just the tool we're using to do it. No D user or contributor needs to pay any attention to it if they don't want to.
D Language Foundation Monthly Meeting Summary for May 2023
The monthly meeting for May 2023 took place on Friday the 5th at 14:00 UTC. It lasted about an hour and a half. This was the last meeting before we started our new planning sessions. The following people attended: * Walter Bright * Iain Buclaw * Ali Çehreli * Martin Kinkelin * Dennis Korpel * Mathias Lang * Razvan Nitu * Mike Parker * Robert Schadek ## The summary ### Me I started with an update on DConf submissions, reporting the numbers and some of the details on who and what. At that point, we had a total of 11 submissions from 8 people. I suggested we could put a panel in one of the open slots if we needed to and asked everyone to think of some ideas. (We ended up with 39 submissions from 21 people, or 24 if you count the additional three members of the one team that submitted, and had no room at all for a panel). Next, I told everyone we had secured some [sponsorship funding from Ahrefs](https://ahrefs.com/) and noted that I planned to use it for BeerConf. I hoped to rent the same space we rented last year at The Fox, so I detailed how I was going to work out paying for it via our event planner. Last year, Funkwerk provided the funding to the DLF, Átila and Walter each paid one or more nights on their credit cards, and the DLF reimbursed them. (Unfortunately, pub hire rates this year have massively increased over last year, putting them well beyond our budget. We've fallen back to the old way of designating a hotel as the BeerConf location, this time Travelodge Central City Road. The sponsorship funding will go toward our speaker reimbursement budget.) Next, I gave an update on registrations. At that point, only one person had registered. I then talked about some email exchanges I'd had with some D shops about possible sponsorships. (Our current headcount as of June 23 is 43. I'm anticipating a final number in the neighborhood of 60-70, which would be in the same ballpark as last year.) Walter brought up [Sebastiaan Koppe's presentation from last year](https://youtu.be/hJhNhIeq29U) on structured concurrency. He said he'd like to see Sebastiaan there this year for an update on the project, preferably as a follow-up presentation. He was excited about the project and felt it was a big deal in general and a big deal for D. Even if Sebastiaan decided not to move the project forward, Walter felt we should find someone to take it over. He said the ideas behind it were big and would be a nice thing for us. (We subsequently confirmed with Sebastiaan that he didn't have enough material yet for a follow-up talk). I summed up by saying that DConf planning was on track and there were no issues so far. Later, I remembered to mention that I had Robert's GitHub to Bugzilla migration script in hand. Now it was just waiting on me to make time to test it out, so I was the blocker now rather than Robert. He warned me about a command line option I should leave off while testing. (You can read about the progress on that [in the General forum](https://forum.dlang.org/thread/pfpoeaoihsqpohumj...@forum.dlang.org) and track our progress [on our GitHub projects page](https://github.com/orgs/dlang/projects/23?pane=issue=29572916.)).) I asked about some issues that [had been migrated to the tools repository](https://github.com/dlang/tools/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc) from Bugzilla. Robert said that was not from him. Mathias jumped in to say that he had done it a long time ago when he took a stab at this. He had closed all of the Bugzilla issues he'd migrated, so there would be no duplications when migrating the open ones. ### Iain Iain opened what turned into a 25-minute segment by saying that he hadn't gotten much done since the middle of March as he'd spent several long weekends on holiday. He'd released D 2.103.0 in April and 2.103.1 on May 1. He had also pushed out the first beta of 2.104.0, and it was on track for release at the end of the month ([he announced it on June 2](https://forum.dlang.org/thread/waigfuztqsqlhzouj...@forum.dlang.org)). He said that GCC 13.1 had been released on April 26. That included version 2.103 of the D frontend in GDC. Walter thanked Iain for handling the releases for us. Martin asked how long the release process takes nowadays. Iain said it depends on if he hits an issue building the Windows release. The Windows box, and *only* the Windows box, seems to hit a file system sync issue. There's a D program, `copyimports.exe`, that had replaced several make recipes to copy files during the build. Sometimes when building the releases, `make` tries to call that program before the linker has created the executable. When that happens, it aborts and Iain has to run the release process from the start again. [He had filed an issue](https://issues.dlang.org/show_bug.cgi?id=23486) for it. If everything goes smoothly, it's about a two-hour process. The biggest part of that is waiting for the builds to
Re: GDC Compilation wtih Directory Present
On Friday, 16 June 2023 at 06:38:17 UTC, Murloc wrote: Thanks! That works well. I thought that `module pack.file1` is implicitly there by default :') The compiler will use the file name as a default module name if you don't provide one, but that's *just* the module name. It doesn't take into account any directories for package names.
Re: DConf '23 Early-Bird Registration Final Day
On Wednesday, 14 June 2023 at 14:33:48 UTC, Mike Parker wrote: Today, AOE (UTC-12), is the last chance to get the 15$ early-bird discount for DConf '23. Don't dawdle! http://dconf.org/2023/index.html#register
Re: GetInterfaceInfo function of win32 api
On Thursday, 8 June 2023 at 07:01:44 UTC, Benny wrote:
I got something! thank you.
now I need to understand how can I get the properties of the
GetInterfaceInfo
```
import core.sys.windows.iphlpapi;
import std.stdio;
import core.stdc.stdlib;
void main()
{
uint* i;
i = cast(uint*) malloc(10);
auto h = GetInterfaceInfo(null, i);
writefln("%s", h);
writeln("Hello, World!");
}
```
this got me 122
Alright. I've never used this function, so I referenced the
documentation here:
https://learn.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-getinterfaceinfo
First, you don't need to allocate i with malloc. Just declare it
as a uint and give the function a pointer to it.
Second, the function is intended to be called twice. The first
time with null for the first parameter as you've done here. After
that call, the value in i should be the size of the memory you
need to allocate for the first parameter on the second call. In
the second call, the data you want will be stored in that pointer.
Third, the first parameter is of type PIP_INTERACE_INFO, which in
Windows lingo means "pointer to IP_INTERFACE_INFO". That's
declared in the ipexport module.
Here's a working example. I chose to use the GC rather than
malloc.
```d
import core.sys.windows.windows, // For the error codes
core.sys.windows.iphlpapi,
core.sys.windows.ipexport;
import std.stdio,
std.string;
void main()
{
IP_INTERFACE_INFO* pinfo;
uint buflen;
// Get the size needed to alloc pinfo
uint ret = GetInterfaceInfo(null, );
if(ret == ERROR_INSUFFICIENT_BUFFER) {
// Allocate pinfo, but let's not use malloc
ubyte[] buf = new ubyte[](buflen);
pinfo = cast(IP_INTERFACE_INFO*)buf.ptr;
}
// Call the function a second time to get the data
ret = GetInterfaceInfo(pinfo, );
if(ret == NO_ERROR) {
writeln("Number of adapters: ", pinfo.NumAdapters);
for(size_t i = 0; iwritefln("Adapter Index[%s]: %s", i,
pinfo.Adapter[i].Index);
writefln("Adapter Index[%s]: %s", i,
fromStringz(pinfo.Adapter[i].Name));
}
}
else if(ret == ERROR_NO_DATA) {
writeln("No network adapters found");
}
else {
writeln("GetInterfaceInfo failure: ", ret);
}
}
```
Re: GetInterfaceInfo function of win32 api
On Thursday, 8 June 2023 at 05:52:43 UTC, Benny wrote: ``` ``` app.obj : error LNK2019: unresolved external symbol GetInterfaceInfo referenced in function _Dmain app.exe : fatal error LNK1120: 1 unresolved externals Error: linker exited with status 1120 ``` That's a linker error telling you that you aren't linking anything that contains the symbol for `GetInterfaceInfo`. You need to link `Iphlpapi.lib`.
DConf '23 Promotional Video -- Please Share!
In an effort to spread the word a bit more, I've put together a short video on DConf '23. Please help us out by sharing it where it makes sense to do so. Thanks! https://youtu.be/sG85BMGWPN4
The DConf '23 Schedule is Live!
Thanks again to everyone who submitted talks for DConf '23, and congratulations to those who were accepted. We've got what looks to be another solid lineup this year. Check it out: https://dconf.org/2023/index.html And remember, early-bird registration ends next week. Get your discounted rate while you still can! https://dconf.org/2023/index.html#register I've also updated the page with information about BeerConf. Unfortunately, pub hire rates in the area are well beyond our budget this year. Much, much higher than last year. So we've fallen back to what we did pre-2019 and tentatively designated a hotel as the BeerConf spot: Travelodge Central City Road I know from staying there last year that they've recently undergone renovations and have an enclosed restaurant/lounge space off of the lobby, where one of the front desk clerks can sell beverages (alcoholic and non-) and snacks after the restaurant closes. It's possible we could pick another spot, or (less likely) our event planner might find something to fit in our budget. I'll announce here and update the website if anything changes. See you in London!
Re: unittest under betterC
On Monday, 5 June 2023 at 14:29:35 UTC, Richard (Rikki) Andrew Cattermole wrote: On 06/06/2023 2:25 AM, Mike Parker wrote: On Monday, 5 June 2023 at 14:16:39 UTC, ryuukk_ wrote: In my book this is broken and needs to be fixed, as a user i don't care about under the hood things, it's a you problem, user should be able to unit test The docs say it should work: https://dlang.org/spec/betterc.html#unittests So either the docs are wrong or the implementation is bugged. If there's no issue yet, could you please file one? Yes that is what I recommended earlier in the thread. But automatic running requires druntime. Ah, I see now. It's working as expected then.
Re: unittest under betterC
On Monday, 5 June 2023 at 14:16:39 UTC, ryuukk_ wrote: In my book this is broken and needs to be fixed, as a user i don't care about under the hood things, it's a you problem, user should be able to unit test The docs say it should work: https://dlang.org/spec/betterc.html#unittests So either the docs are wrong or the implementation is bugged. If there's no issue yet, could you please file one?
Re: How does D’s ‘import’ work?
On Saturday, 3 June 2023 at 09:04:35 UTC, Dom DiSc wrote: You can replace your whole makefile by calling the compiler with -I (not always, but if you don't do funny things in your makefile). That would be `-i`. - This ability of the D compiler was just recently discovered (after -I was implemented for other reasons), but it relies on the fact that we have imports. Jonathan Marler implemented it in 2017 after a discussion in the forums. https://github.com/dlang/dmd/pull/7099
Re: How static link dll msvcr120.dll?
On Thursday, 1 June 2023 at 15:05:40 UTC, Marcone wrote: I linked msvcr120.lib, but the executable still ask for msvcr120.dll not found. msvcr120.lib is a "link library", not a static library. On other systems, you pass shared libraries directly to the linker and it will pull the information it needs from there to set up the exectuable with what it needs for the system loader to load the shared library at runtime. Windows works differently. The compiler puts all that information in a link library when it creates the DLL, and you pass that to the linker instead of the DLL. Windows system libraries are not distributed as static libraries as far as I know.
DConf '23 Early-Bird Registration: Two Weeks Remaining
General registration opens on June 15. Until then, you can still register at the early-bird rate. Don't miss the window! https://dconf.org/2023/index.html#register If you're a student, you have a permanent $100 rate ($120 with VAT). Just let me know and I'll get you sorted. If you're waiting to see what the talks look like, I'm hoping I can announce them this weekend and have the full schedule published next week. We've got some quality topics to choose from and several first-time submitters. I can't promise all of them will get in, but like last year, the schedule this year is shaping up to be more than just the same old familiar faces.
DConf '23 Submission Deadline Countdown
The deadline is 23:59 AOE today, May 31. If you haven't submitted a talk yet, now is the time to get one to us. We do have more talks than we need, which means there will be some rejections, but we welcome as many submissions as we can get. So don't let that stop you!
Re: DConf '23 Submission Deadline Countdown
On Wednesday, 31 May 2023 at 09:04:18 UTC, Mike Parker wrote: The deadline is 23:59 AOE today, May 31. If you haven't submitted a talk yet, now is the time to get one to us. We do have more talks than we need, which means there will be some rejections, but we welcome as many submissions as we can get. So don't let that stop you! Submission details can be found here: http://dconf.org/2023/index.html#schedule
DConf '23 Submission Deadline One Week Away
The deadline for DConf '23 submissions is May 31 AOE. Don't let it slip past you!
D Language Foundation April 2023 Monthly Meeting Summary
We held the monthly meeting for April 2023, on Friday the 14th at 14:00 UTC. It lasted just short of an hour and a half. We'd [had a quarterly meeting the previous week](https://forum.dlang.org/thread/yuewobigwhvrtfxlz...@forum.dlang.org). This was the first time wev'e held a monthly meeting in the month of a quarterly. Previously, we'd combined them, but [decided in our March meeting](https://forum.dlang.org/thread/aaebiekxqbwgxzkky...@forum.dlang.org) to split them up. The following people attended: * Walter Bright * Martin Kinkelin * Dennis Korpel * Mathias Lang * Átila Neves * Razvan Nitu * Mike Parker * Robert Schadek ## The summary ### Me I opened the meeting with an update on DConf preparations. Most of it was boring details. Other than that, the venue contract had been signed and a down payment sent a couple of weeks before, and Symmetry had reached an agreement with our event planner on the terms and conditions of their contract. I was waiting on word that it was signed (I have since received it). I noted that Sönke Ludwig had contacted me before I left for my trip in late March. He was doing some maintenance work on codemirror.dlang.org and asked if I wanted to redirect the URL to his new VPS or if he should move it onto a DLF server. Since this is one of the services we need to move over eventually anyway, I asked him to go ahead and do it. Vladimir Panteleev had already set up the documentation tester on a DLF server, so I reached out to him to see if we could move codemirror there or if we needed a new one. After discussing it with Sönke, he said we had enough resources for both services. So I set up Sönke with an account, then he and Vladimir got it up and running while I was on my trip. ### Dennis __CI failures__ Dennis started by saying that the CI was randomly failing again. He didn't have a Mac, so he'd been unable to chase down the problem. Random CI failures are a recurring problem. There are so many checks, and he doesn't know who created them or who knows exactly what the checks are doing. He wishes the tests had someone responsible for them who he could turn to when they fail. Walter asked who had previously been in charge of the tests. Razvan said he didn't recall if one person was ever in charge of them. At some point, someone decided it was a good idea to have a particular test and it got added to the pipeline. Dennis asked if we should only keep tests that have a maintainer. Martin and Mathias quickly rejected that. Martin said the tests are good. CI failures are usually caused by CI image bumps or a PR. CI image changes are a PITA for LDC's tests, and PR-related failures may not be easy to resolve, but failures are hardly ever the fault of a test. And there's never been any specific person responsible for any of DMD's CI systems. They just grew organically. Then someone who knew the details moved on and no one else knows them... it's a constant maintenance burden, but it's worth the effort. There was a bit more discussion about the maintenance burden, after which I noted that this is the story of our ecosystem. We're responsible now for things none of us set up, and we need to get a handle on it all. Dennis agreed and added that the CI is in a special position. When one of them is outdated, it doesn't just sit there out of the way, it becomes an annoyance to development. (NOTE: This is one of the many aspects of our ecosystem that we'll be working to improve [under our new workflow](https://forum.dlang.org/thread/avvmlvjmvdniwwxem...@forum.dlang.org).) __The -J compiler switch__ Next, Dennis said that, as he understood it, `-J` was added as a measure against [string imports](https://dlang.org/spec/expression.html#import_expressions) being used as a malware vector. As he sees it, string imports are no more risky than normal imports. Why can't they be handled the same way? Walter said the concern was that they could be used to read any file from the filesystem and bake it into the binary, and that could be used to steal data from the user's system. With normal imports, the compiler only reads D source files. It can't import arbitrary data. He then talked about some examples. What it comes down to is that there are so many clever ways to implement malware, he just doesn't want to open that door wide to the possibility. Martin talked a bit about how Symmetry uses `-J` in their codebase, and Átila told us how he used it a lot with reggae. Dennis proposed that any directory given to `-J` be treated as a root, and its subdirectories added to the search path. Martin and Átila both said that the compiler already allows string imports from subdirectories of any `-J` directory (when the full path is included in the import expression). __The DMD backend__ Dennis said that because the DMD backend was shared with the Digital Mars C and C++ compiler (DMC), there was a rule in place that changes to the backend
DConf '23 Guest Keynote Speaker
Recently, I announced that some D Language Foundation members and associates took part in an organizational development program called IVY, courtesy of Ucora. We were coached through the program by Saeed Sabeti, Ucora's Director of Organizational Development. Given the positive experience we had and the bond we established with Saeed, it was obvious to us that we should invite him to DConf '23 in London as our guest speaker. I'm happy to announce that he accepted! I'll publish the abstract of his talk once the full schedule is ready to go, but right now I can say that he'll be talking about IVY in the context of the D community. It should be of general interest to everyone, but it should be especially relevant for future and current contributors. https://dconf.org/2023/index.html We're accepting submissions until the last day of May. Remember, if your submission is accepted, you'll be eligible for reimbursement of your travel and lodging expenses. We're especially interested in hearing from first-time DConf speakers, so don't be shy! Check out the details here: https://dconf.org/2023/index.html#schedule If you aren't submitting anything, June 14 AOE is the last day of early-bird registration. What are you waiting for? https://dconf.org/2023/index.html#register
Re: A New Era for the D Community
On Friday, 5 May 2023 at 11:26:26 UTC, Ogi wrote: On Wednesday, 3 May 2023 at 11:13:34 UTC, Mike Parker wrote: … That’s a lot of words but little actual sense. What makes you think that this IVY™ program is the silver bullet that D desperately needs? And not just yet another load of crap invented by some “consulting” firm as a relatively honest way of taking money from businesses? Because it’s sounds like one. Because we went through the program and can see how it's going to benefit us. It's not automatically going to make things better. We have to do the work. But the point is, now we know how to do the work, whereas before we were just throwing things at the wall to see what stuck. People around here frequently complain about bad management. Through the IVY program we, all of us non-managers, learned an approach to management that makes sense to us. It's going to change the way we do things, and we're all confident the change will be for the better. Ucora's workflow is built around IVY as well. Saeed shared with us some of the ways they use it so that we could better see how we can employ it. He's also made himself available to help us as we go along. They're serious about it, and so are we. You'll hear more about it before and during DConf. After, I expect it will become part of the common lexicon in the D community.
Re: A New Era for the D Community
On Wednesday, 3 May 2023 at 11:37:31 UTC, Nicholas Wilson wrote: From memory that was merely an AGM at DConf, but sure, I'll take credit for that (despite knowing next to nothing about management)! The AGM was your idea, but so were the regular meetings. You pushed it to Ali in 2018. I have a second-hand email record!
A New Era for the D Community
At DConf '22, Roberto Ierusalimschy, the lead designer of [the Lua programming language](https://www.lua.org/), was [our guest keynote speaker](https://youtu.be/H3inzGGFefg). At the end of his talk, Robert Schadek [asked him how he organized the Lua community](https://youtu.be/H3inzGGFefg?t=3223). His answer: Is it too ugly if I say I don't? In [my talk at the same conference](https://youtu.be/gk_QjjxCGSY), I highlighted part of the history of the D community's evolution. I used the metaphor of a pioneer settlement that evolved into a village and then into a town. In those early pioneering days, Walter's approach to organizing the community was the same as Roberto's. He didn't need to do anything. The community organized itself and built from scratch the foundations of the ecosystem we have today. If you discovered D and expected only to be a user and never a contributor, then D just wasn't for you. Of course, as the community grew and evolved, and built up more of the ecosystem, there was increasing space for noncontributors. That, in turn, led to shifting expectations. At different points in D's history, Walter, Andrei, and motivated community members took steps to adapt to changing expectations. For several years they were able to keep up reasonably well. To give just one example, in the earliest days, users posted bug reports in the forums or by emailing Walter, and contributors emailed him patches. In response to calls for better bug management, a community member volunteered to maintain a Bugzilla instance. Then later, when people were wondering why they had to submit patches to Bugzilla when GitHub existed, Walter was persuaded to put the compiler's source on GitHub. By the time Walter and Andrei established the D Language Foundation in 2015, they had settled into a very loose management style. Motivated community members volunteered to create services, or take charge of something in the ecosystem, and Walter and Andrei would give their blessing. I can't speak to what their goals were with the Foundation, but they largely continued that approach to managing the ecosystem. Unfortunately, as the community continued to grow and expectations continued to evolve, that approach was unsustainable. Ten years ago, if the forums went down, everyone knew to contact Vladimir Panteleev. Today, many people don't know, and probably don't care, that he pays for and maintains the server on which the forums are hosted. The forums are on dlang.org, the official website of the D Language Foundation, so the DLF is responsible for getting things back up. When a bug report remains open for years, it doesn't matter that it's because it hasn't come to the attention of someone with the time, ability, and motivation to fix it. The DLF is responsible for organizing resources to address reported issues, and if we can't, that's on us. One of the biggest complaints I've heard over the past few years is some form of "lack of leadership/management/vision". It's painful to hear, as I know that everyone involved with the DLF is personally invested. We're here because we love what we're doing. Yet, the criticism is on the mark. Yes, there have been improvements over the past few years. The quarterly DLF meetings with industry representatives, initially proposed by Nicholas Wilson, have been productive. The monthly meetings that grew out of those have led to several positive changes. Symmetry's sponsorship of the Pull Request and Issue Manager positions held by Razvan Nitu and Dennis Korpel has been a huge boon. We've begun migrating some ecosystem services to DLF servers (it's going very slowly, but it's happening). We've done several good things that I could enumerate here. But collectively, it's the equivalent of being surrounded by small fires and running around to put them out at random. We simply do not have a structured system of management. Several times over the past couple of years, we discussed what to do about it. We read books, watched presentations, and asked for advice. We got nowhere. Then, in July of last year, Paul Toth of Ucora reached out with an offer. Had I known at the time that it was going to change everything, I would have put it at the top of my priority list. Alas, it wasn't until November that things started moving. Ucora’s long-term vision is [to change the way the world works](https://ucora.com/). As part of their mission, they provide organizations with the tools they need to transform the way they work. [IVY, their organizational development program](https://ucora.com/solutions/organizational-development/), is a simple but innovative approach to workflow. Ucora has been using D for several years. They're invested in D's success, and so they want the DLF to be successful. Paul offered to put the DLF team through the IVY program at no charge. We accepted, and every Friday for the past 14 weeks we've been having sessions
Tutorial on LDC's -ftime-trace
Dennis Korpel has a new tutorial out on the foundation's YouTube channel, showing how to employ LDC's -ftime-trace option to improve your project's compile times. This can come in handy if you're heavily using metaprogramming or CTFE. https://youtu.be/b8wZqU5t9vs
Re: A Programmer's Dilema: juggling with C, BetterC, D, Macros and Cross Compiling, etc.
On Monday, 1 May 2023 at 09:17:14 UTC, Eric P626 wrote:
This is a false dilemma: D has full C compatibility.
From what I understand, D can use C, but C cannot use D? It's
like C++: C++ can call C but C cannot call C++.
50% or more of my code will be put in re-usabled libraries. If
I want people to use those libs, I would need to compile them
in C or better C. Because betterC seems to create C libraries.
If D can make C libraries, then indeed, I could do everything
in D.
D is ABI-compatible with C. BetterC has nothing to do with it.
And if you're using BetterC just because you're linking with a C
library, you're crippling your D code. That's not really a good
use case for it.
Any D function marked as `extern(C)` can be called from C. As
long as you have a C header file defining the functions and the
appropriate C declarations any custom types you have, the C code
will have no idea it's calling into a D library.
In your D library:
```D
// This function can be called from C
extern(C) void functionForTheCAPI(const(char)* str) {
import std.conv : to;
doSomething(to!string(str));
}
// This is a D function that cannot be called from C
void doSomething(string s) { ... }
```
In the corresponding C header:
```C
extern void functionForTheCAPI(const char* str);
```
Just `#include` the C header in your C code, link with the D
library, and you're good to go. Make sure to include a function
somewhere in your D library's C API to initialize DRuntime:
```D
import core.runtime;
extern(C) int initialize() { return Runtime.initialize(); }
```
Add the declaration to a C header and you're good to go.
Re: A Programmer's Dilema: juggling with C, BetterC, D, Macros and Cross Compiling, etc.
On Monday, 1 May 2023 at 09:35:59 UTC, Dukc wrote: hard. Seems the C-linked functions in [core.runtime](https://dlang.org/phobos/core_runtime.html#.Runtime.initialize) ought to do the trick. If you're referring to `rt_init` and `rt_term` are the `extern(C)` functions in `core.runtime`. It's not necessary to call those from C. A D library with a C interface can provide an `extern(C)` initialization function that internally calls `Runtime.initialize`.
D Language Foundation April 2023 Quarterly Meeting Summary
The D Language Foundation's second quarterly meeting for 2023 took place on April 7 at 14:00 UTC. It lasted just over an hour. This was the first "standalone" quarterly meeting, where the foundation's monthly discussion was split into a separate meeting the following week. Two new members joined us this time, and we look forward to hearing more from them at future meetings. I was in transit at the time the meeting took place, so I want to thank Razvan for conducting it in my stead and Dennis for recording it so that I can write up this summary. ## The attendees * Mathis Beer (Funkwerk) * Walter Bright (DLF) * Andrea Fontana (2night) * Mathias Lang (DLF/Symmetry) * Martin Kinkelin (DLF/Symmetry/LDC) * Dennis Korpel (DLF) * Mario Kröplin (Funkwerk) * Vijay Nayar (Funnel-Labs.io) * Átila Neves (DLF/Symmetry) * Razvan Nitu (DLF) * Robert Toth (Ucora) * Bastiaan Veelo (SARC) ## The summary ### Mario Mario started by asking about the future of formatters in D. Funkwerk has put a lot of [effort into dfmt](https://github.com/dlang-community/dfmt), and they run it over all of their code, but pull requests for it have long waiting times and new releases are infrequent. Typically, when the Funkwerk programmer who contributes to dfmt makes a PR, it goes for weeks with no progress. There's also sdfmt (part of [the Snazzy D Compiler project](https://github.com/snazzy-d/SDC) maintained by Amaury Séchet) that seems to get more use. The question he was looking to answer: should Funkwerk keep putting effort into dfmt, or switch to sdfmt? dfmt was created and originally maintained by Brian Schott, but for some time now has been under the dlang-community group at GitHub, and no one at the meeting could say who was responsible for it now. Mathis Beer noted that Jan Jurzitza had mostly been the one merging things. This was followed by a 15-minute discussion that went off on a couple of related tangents, but ultimately came down to two conclusions: * Funkwerk should get increased access to the dfmt repository * Razvan will have a new crop of students next fall, and he can find one to work on integrating dmd as a library in dfmt The intervening discussion flowed as follows. Mathias Lang said that Symmetry uses sdfmt since the maintainer is also part of Symmetry's team. The perceived advantage it has over dfmt is that it's based on the compiler as a library. He posed two questions: do we want to have one formatter we endorse as the D Foundation and, if so, which one should it be? If we do endorse one, then we should distribute it with the compiler. Walter agreed that a formatter should be part of the compiler release. Mathias added that it would be much better if we have the compiler as a library. Razvan agreed and said that if we could convert dfmt to use dmd as a library [rather than libdparse](https://github.com/dlang-community/libdparse), that would be a step forward. Dennis questioned that point. The formatter only needs the parser. libdparse takes everything into account for syntax handling, but the dmd parser skips over some things (such as comments and unit tests). And even if the dmd parser is changed to account for more, how is it a better option than libdparse? This prompted a brief side discussion that resulted in general agreement that the main problem with a third-party parser is that it falls behind (some recent examples were cited) and will rarely be in sync with the latest compiler release. Átila added that even when it is current with the latest language features, the fact that it's a separate implementation means there are bound to be differences that manifest as bugs. Razvan said that another issue with libdparse is anything using it that needs semantics, [like dsymbol](https://github.com/dlang-community/dsymbol), has to come up with something mimicking the compiler's behavior. He has a student currently working on replacing the use of libdparse and dsymbol [in D-Scanner](https://github.com/dlang-community/D-Scanner) (see Lucian Danescu's DConf '22 talk, [Integrating the D Compiler as a Library in D-Scanner](https://youtu.be/JYkb3PjIn4c). Walter noted that he had spent some time converting dmd's lexer and parser into standalone components. At the time of the meeting, the lexer was fully independent and the parser was mostly independent. There was still some work to be done to remove the parser's dependencies. He said he could get back on that and then it would be better suited to replace libdparse. That won't solve the semantic issues, but at least then the lexer and parser could be the same as what the compiler uses. ([He posted in the forums](https://forum.dlang.org/thread/u0vqo6$1bc6$1...@digitalmars.com) a couple of days later that the lexer, parser, and ImportC parser were now all independent.) Walter then suggested that, down the road, we would ideally have only one formatter. We can continue to update dfmt, but if
Re: Making a D library for a C executable
On Thursday, 27 April 2023 at 20:32:24 UTC, Jan Allersma wrote:
```
Apparently foo isn't found from the CPP source file. Anyone
some ideas on how to solve this? :)
That's a compilation error, not a linker problem. You need to
tell the compiler about the function with a prototype:
```C++
#include
int foo();
int main() {
std::cout << "deede" << foo() << std::endl;
}
```
DIP1044---"Enum Type Inference"---Formal Assessment
I submitted DIP1044, "Enum Type Inference", to Walter and Atila
on April 1. I received the final decision from them on April 18.
They have decided not to accept this proposal.
https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1044.md
The said the proposal was well done and an interesting read, but
found it to be too complex for insufficient benefit. They
provided the following list of concerns that led them to their
decision:
* Given that D already has `with`, `alias`, and `auto`, it does
not seem worthwhile to add a special case for enums.
* Semantic analysis in D is strictly bottom-up. This proposal
would add top-up type inference on top of that. This presents
problems in handling function and template overloads, as well as
variadic parameter lists.
* The proposal only allows ETI in some contexts. This is
potentially confusing for the programmer, particularly in the
presence of mixin templates (which draw symbols from the
instantiation context) and function overloads.
* Symbol tables can get very large. Lookups are done via hash
table for max speed, but this will not work for ETI. There may be
a very large number of "enums in scope", and each one will have
to be searched to resolve a member.
* ETI is similar to ADL (Argument Dependent Lookup) in C++.
Walter implemented ADL in the Digital Mars C++ compiler and is
strongly against allowing anything like it in D. He finds it slow
and complex, and few people really know how it's going to work.
Regarding enums in switch statements, Walter suggested we could
shorten the `with final switch` syntax such that the `with` is
implicitly applied to the type of the switch variable:
```D
auto myEnum = MyEnum.a;
with final switch (myEnum) { }
```
Alternatively, we could make the `with` implicit for case
statements, but that would break existing code.
