Re: D Language Foundation October Monthly Meeting Summary
On Sunday, 31 December 2023 at 11:12:23 UTC, Mike Parker wrote: 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. [...] I also would have reminded everyone that one of our major goals right now is to strengthen the ecosystem. We're absolutely willing to throw some money at code-d and any other important projects in our ecosystem where that money can help get something done. We have over $11,000 sitting in our OpenCollective account that can be used for this sort of thing. Jan or anyone working on a key D project is welcome to reach out to me to discuss possibilities: bug bounties, contract work for specific tasks, etc. Some of the important ecosystem projects when I teach D are code-d, IntelliJ support, and fixing issues for MacOS (e.g. Having to type out 'export MACOSX_DEVELOPMENT=13.0' or something similar for the tools is tricky for students). The current Symmetry of Code projects (Dfmt, C++ Interop, etc.) and d-scanner are also very valuable tools for adoption in my opinion -- appreciate the efforts for those contributing to the tooling ecosystem!
Re: D Language Foundation October Monthly Meeting Summary
On Monday, 1 January 2024 at 10:50:22 UTC, Konstantin wrote: On Sunday, 31 December 2023 at 11:12:23 UTC, Mike Parker wrote: Finally, he brought up code-d, [the Visual Studio Code extension for D](https://github.com/Pure-D/code-d) maintained by Jan Jurzitza (Webfreak). Steve said that it was great when it worked, but there were a lot of weird things that caused it to break. And what about https://code.dlang.org/packages/dlangide/0.8.18 or https://gitlab.com/basile.b/dexed? They are both not extensions, but full IDEs. I tried to install both of them (dlangide does not compile with dmd 2.097), dexed has working executables and looks good. DCD is the project that empower them all Improvements to DCD = improvements to both serve-d, dlangide and dexed But it's a waste of effort if DMD as library project becomes usable for a language server So who ever is working on DMD as library should get the funding to speed it up Funding for fixing serve-d crashing is useless if it still can't work with D's features (mixin/template) Funding should to towards having these features that is missing - good mixin support - good template support - good debugger support Anything else is just distraction I tried but it didn't got any steam,and github fucked up by deleting the branch, i still have it locally, so whoever wants to pursue this work, let me know https://github.com/dlang-community/DCD/pull/714
Re: D Language Foundation October Monthly Meeting Summary
On Sunday, 31 December 2023 at 11:12:23 UTC, Mike Parker wrote: Finally, he brought up code-d, [the Visual Studio Code extension for D](https://github.com/Pure-D/code-d) maintained by Jan Jurzitza (Webfreak). Steve said that it was great when it worked, but there were a lot of weird things that caused it to break. And what about https://code.dlang.org/packages/dlangide/0.8.18 or https://gitlab.com/basile.b/dexed? They are both not extensions, but full IDEs. I tried to install both of them (dlangide does not compile with dmd 2.097), dexed has working executables and looks good.
Re: D Language Foundation October Monthly Meeting Summary
On Sunday, 31 December 2023 at 11:12:23 UTC, Mike Parker wrote:
(__UPDATE__: Both [the Bugzilla
issue](https://issues.dlang.org/show_bug.cgi?id=24153) and [the
pull request](https://github.com/dlang/dmd/pull/15627) have
since been closed, as the issue is no longer reproducible.)
I just tested, and the issue happens again, i don't know what
yielded it to disapear previously, maybe a mistake on my end (i
probably forgot -inline)
Anyways, here is the code that reproduces the issue:
```D
struct InvBoneBindInfo
{
}
struct Test(Value)
{
void test()
{
auto t = Value.init; // <--- it's because of this
}
}
extern(C) void main()
{
Test!(InvBoneBindInfo[32]) test;
test.test();
}
```
Compile it with:
``dmd -betterC -inline -run test.d``
You will get:
```
test.d(1): Error: `TypeInfo` cannot be used with -betterC
```
The issue remains because of the ``Value.init``, wich is a static
array, dmd for some reasons require the typeinfo
Re: D Language Foundation October Monthly Meeting Summary
On Sunday, 31 December 2023 at 11:12:23 UTC, Mike Parker wrote: 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. [chinese version](https://fqbqrr.blog.csdn.net/article/details/135319694)
Re: D Language Foundation October Monthly Meeting Summary
On 01/01/2024 12:12 AM, Mike Parker wrote: Next, he said he'd discovered that a one-line file with |import std.file| takes 200ms to compile, and that was nuts. He needed to figure out at some point exactly what the problem was. It was just semantic analysis just from the import. He wasn't even generating the object file. On the same machine, he also tried a C++ compile with just |#include | and that took 400ms. He said that twice as fast as C++ was nowhere good enough. Walter agreed. It's 2024, so lets hunt down what the problem is with ``std.file``. On my machine compiling it using ldc2 1.35.0, it took ~500ms (frontend only). That is quite a long time. So lets go hunting! I've found a bunch of cost associated with ``std.uni``, specifically from ``std.windows.charset``. Which imports ``std.uni`` via ``std.string``, and ends up imports the unicode tables which take 117ms to sema2 (no surprises there). Why does it import ``std.string``? To call toStringz. What did I replace it with in my test code? ``return cast(typeof(return))(s ~ "\0").ptr;``. Bye bye 117ms. Next up ``std.datetime.timezone`` 40ms of that is from ``std.string``, but alas that actually is needed. Now on to sema2 for ``std.datetime.systime``, again into ``std.datetime.timezone``, nothing we can do there as above. For all 111ms of it. All and all, I can't find anything to really prune for this. There won't be any easy wins here. The Unicode tables would need to be completely redone to improve it and if done may only decrease the sema2 from ~100ms.
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
