Re: D Language Foundation January 2024 Monthly Meeting Summary

[Dukc via Digitalmars-d-announce]

Mike Parker kirjoitti 14.5.2024 klo 16.23:
The D Language Foundation's monthly meeting for January 2024 was held on 
Friday the 12th. There were two things of particular note about this 
meeting.




Thanks for the write-up once again! Always nice to know what is cooking, 
even when the news come a bit late.

Re: D Language Foundation January 2024 Monthly Meeting Summary

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

Wow I see I was mentioned at a lot at this meeting!

In saying that I do have some points to add about Item 2 data structures.

Data structures come in one of two forms generally: owning and non-owning.

### Non-owning

Non-owning is the simplest, its an index.
It doesn't own any memory that isn't internal.

Takes in a single memory allocator for its internal state.

For its memory safety you are pretty limited to concerns surrounding 
read-only-ness of its internal state. Which only exist because the GC 
allocator might be in use.


You pass a value in, you get a value out. No references.

### Owning

Owning data structures come with two subsets which may be mixed to form 
a third combined subset.


 Cleans up

Takes in two memory allocators, one for its internal state, one for its 
deallocation of values.


Will deallocate any memory given to it, which also means that once 
memory is placed into it, it now owns it and is responsible for its cleanup.


As for memory safety you have only one (as long as you don't use 
references out).


Owner escape analysis, this is a DIP Walter has required for me to work 
on before reference counting. So its going in anyway.


 References out

I'll assume here that it does not clean up any memory passed in, that 
you handle this manually, that the data structure is merely an index.


In almost all ways its similar to non-owning, one memory allocator, 
still has the memory safety concerns of the owner.


An you also have to worry about borrows typically from a struct 
acting as a reference. Which once again is resolved with owner escape 
analysis (noticing a trend yet?).




What this tells us is that non-owning data structures can go in pretty 
much immediately, although there will need to be some remedial work once 
we get reference counting and with that a solution to read only memory.


But of course because Walter wants owner escape analysis first, it 
doesn't matter, both owning and non-owning will need to go together.


Note: concurrent data structures will need the read only memory solution 
due to the locks (notice a trend yet?) as well.


We'll likely want to use long names to differentiate all these behaviors 
unfortunately. As it could be quite desirable to have all the different 
variations.

Re: D Language Foundation January 2024 Monthly Meeting Summary

[jmh530 via Digitalmars-d-announce]

On Tuesday, 14 May 2024 at 14:01:28 UTC, Hipreme wrote:

[snip]
### Item 8

There was a project which is basically rdmd but faster out 
there, done by Jonathan Marler.

- https://github.com/dragon-lang/rund
Sometime ago I thought about just pushing to d tools, but since 
no one cared about, I simply abandoned the idea, but there it 
is:


I was thinking the same thing! I had used it a few times, but I 
just don't use rdmd enough to want to use an alternative to it. 
If the improved functionality were built-in, then that would be a 
positive.

Re: D Language Foundation January 2024 Monthly Meeting Summary

[Hipreme via Digitalmars-d-announce]

On Tuesday, 14 May 2024 at 13:23:17 UTC, Mike Parker wrote:
The D Language Foundation's monthly meeting for January 2024 
was held on Friday the 12th. There were two things of 
particular note about this meeting.


[...]


I have some things to feedback on those points

### Item 6
I had done my DIP thinking mostly about intermediate values on 
mixin template. That would make the value not included in mixin 
template, but yes, static foreach also needs that, so a good 
solution would be one that solves them both.



### Item 7
Redub is a tool that is basically a dub clone which improves what 
dub is not doing very smartly: building. Recently I've done a 
simple, yet major UX improvement: if dmd is not found, it tries 
ldc.


But the apex of UX I've done is inside my engine, but I've shared 
a plenty of times: build selector.


This tool is focused into:

All the items ending with a `*` are optionally done by the user.

- Downloads a D compiler if none is found on the user system
- Downloads and installs git [only on Windows that is automatic. 
Other systems it shows an error requiring that to be done]
- [Windows] - Installs MSVC and vcruntime so D is able to build 
it on systems that doesn't have this option (I needed that when 
running with a VM).
- Download Android SDK/NDK [based on the user system], with the 
supported LDC compiler and sets up the DFLAGS required to build 
for Android.*
- Sets up a custom D runtime which supports building to WASM, 
sets up the DFLAGS required to build it. May also get a supported 
compiler.*

- Sets the DFLAGS required for being able to build for iOS.*

### Item 8

There was a project which is basically rdmd but faster out there, 
done by Jonathan Marler.

- https://github.com/dragon-lang/rund
Sometime ago I thought about just pushing to d tools, but since 
no one cared about, I simply abandoned the idea, but there it is:

D Language Foundation January 2024 Monthly Meeting Summary

[Mike Parker via Digitalmars-d-announce]

The D Language Foundation's monthly meeting for January 2024 was 
held on Friday the 12th. There were two things of particular note 
about this meeting.


First, Jonathan Davis joined us for the first time and is now a 
permanent member. We're very happy to have him aboard.


Second, this was the first meeting where we adopted a new format. 
Previously, we'd go around the "room" to give each participant a 
turn to say everything they needed to say or as much as they 
could say before we had to move on in the interest of time. 
Sometimes people had problems they wanted to solve, other times 
they just had status updates or progress reports. When our 
membership was small, it all worked well, but as the invitation 
list grew, we could end up with long meetings in which important 
topics got cut short because they didn't get brought up until 
later in the meeting.


For the new process, I ask everyone to send me any agenda items 
they'd like to discuss that are not progress reports or status 
updates. At the meetings, I'll go round-robin through the lists 
in the order I receive them: first item from each list, second 
item, etc, until either there are no more items or we've hit the 
hour-and-a-half mark. If we get through the items early, then 
I'll open the floor to anyone who has something to report. If we 
still have agenda items at the hour-and-a-half mark, I'll ask if 
we should continue for another 30 minutes or call it.


This new approach has worked well for us since. It's also going 
to change how I write the monthly summaries. Each section heading 
is a topic of discussion rather than a participant's name.


The only agenda items I received from the members for this 
meeting came from Timon. He had quite a list, and we went through 
pretty much the whole thing. But I did give the floor to Robert 
at the beginning for a very brief update. I also had one item 
that came in the form of a request on the Discord server.


## The Attendees

The following people attended the meeting:

* Andrei Alexandrescu
* Walter Bright
* John Colvin
* Jonathan M. Davis
* Timon Gehr
* Martin Kinkelin
* Dennis Korpel
* Mathais Lang
* Razvan Nitu
* Mike Parker
* Robert Schadek
* Steven Schveighoffer
* Adam Wilson

## The Summary

### Item 1: Bugzilla to GitHub migration
As I noted in the [November meeting 
summary](https://forum.dlang.org/post/lywqaaibghfinljxo...@forum.dlang.org), some potential issues had come up regarding the effect of the Bugzilla to GitHub migration on the dlang bot. Robert had said he'd investigate them.


As an update, he'd discovered some changes needed to be made to 
the changelog generator and had made good progress on that. He 
said Vladimir Panteleev had been working on some changes to the 
dlang bot related to how it closed solved issues. When that was 
all completed, they'd be able to test it. He wanted to put it 
through multiple tests to make sure it held up and worked as 
intended.


### Item 2: D data structures
Monkyyy asked me on the Discord server to bring his article on [D 
data 
structures](https://monkyyyscience.substack.com/p/d-data-structures?r=99zq_campaign=post_medium=web) to the meeting. I emailed a link to everyone before the meeting. I received a little bit of feedback in the email thread. In summary:


* Monkyyy's complaint that allocators are "unmerged" highlights 
why Átila wants them out of `std.experimental`.
* The article doesn't specify any specific data structures he'd 
like to see in the standard library.
* Any redesign of Phobos needs to consider containers at some 
point, but how comprehensive should it be? How high of a priority?
* Some simple containers can easily be built on top of arrays. 
Should we add that kind of thing to Phobos, or only more complex 
ones?
* Would it be better to have a comprehensive container library in 
the dub registry?


I asked if anyone had any more feedback that they hadn't raised 
in the email thread. Timon suggested that someone should do what 
Paul did with the sumtype package: write a container library and 
then we could put it in Phobos if it was good enough.


Adam said he'd been having discussions about containers with 
Rikki and others. He told us that Rikki felt that we needed to 
focus on allocators first, then once that was solved we could 
start looking at containers. Adam said he didn't know if that was 
necessary or not, but based on that and other conversations he'd 
had on Discord, he thought that was the point of the article.


Steve said he agreed with Timon: if we were going to have 
something that was going into Phobos, it should be put up on dub 
first to prove that it was worth including. There were so many 
different opinions around containers and their APIs that it 
wasn't something we should just say, "Here's some space in 
Phobos, now put them in." Put it in dub first, work out the API 
we wanted, make sure it all works, and then put it in Phobos.


Razvan wondered what the procedure would be. There were a 

Re: D Language Foundation July 2023 Quarterly Meeting Summary

[Lynn Davenport via Digitalmars-d-announce]

On Saturday, 29 July 2023 at 14:37:32 UTC, Mike Parker wrote:
I mistakenly posted the summary in the General forum. You can 
find it here:


https://forum.dlang.org/thread/jzlympfqmwckaiuhq...@forum.dlang.org [geometry 
dash world](https://geometrydashworld.net)



Good, I'm looking forward to it. I appreciate all of your effort!

Re: D Language Foundation January 2024 Quarterly Meeting Summary

[Hipreme via Digitalmars-d-announce]

On Wednesday, 3 April 2024 at 16:25:49 UTC, Mike Parker wrote:
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.


One update is that by now, Luna is now maintaining with me the 
Objective-C meta library which is a framework for developing 
extern(Objective-C) bindings in a way that it doesn't depends on 
compiler support. Although it is less flexible than what a 
compiler can do ( you can't create your own objective-C classes 
on it, you still can create bindings to Apple's library.


Those are for reference:

https://code.dlang.org/packages/objc_meta
https://code.dlang.org/packages/d-metal-binding
https://code.dlang.org/packages/avaudioengine

Re: D Language Foundation January 2024 Quarterly Meeting Summary

[jmh530 via Digitalmars-d-announce]

On Wednesday, 3 April 2024 at 16:25:49 UTC, Mike Parker wrote:
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.

[snip]


Thanks for the write-up, as always.



__Question about Ddoc__

Second, when documenting template parameters vs. regular 
paramters, was there a separate segment for template 
parameters? In the language and the code, they were distinct, 
but in Ddoc there was only `Params:`. Mathias said that putting 
them all in `Params:` handled it.


Vijay asked if grouping them together was the right choice 
given that they were distinct in the language and the code. 
Mathias thought so. He said that at Sociomantic (where they had 
maintained their own fork of the compiler), they'd implemented 
`Template_Params:` at one point. He said from his experience 
with that, there wasn't much value in it. If we really wanted 
to separate them, the compiler could figure it out and we could 
just display them separately. But he didn't see the value in it.


Átila agreed. He said that you knew the names, the names 
weren't going to repeat, so you could probably tell them apart.




I haven't found myself needing a separate section for template 
parameters, but I've come across a number of bugs associated with 
ddoc (or ddox, I can't recall the difference) [1] and some are 
related to how it handles more complicated templates.


[1] 
https://issues.dlang.org/buglist.cgi?email2=john.michael.hall%40gmail.com_to2=1=1=1=1=substring_format=advanced=---_desc=ddoc_desc_type=allwordssubstr

D Language Foundation January 2024 Quarterly Meeting Summary

[Mike Parker via Digitalmars-d-announce]

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: D Language Foundation December 2023 Monthly Meeting Summary

[Anonymouse via Digitalmars-d-announce]

On Wednesday, 27 March 2024 at 20:32:16 UTC, Mike Parker wrote:

[...]


Thank you for summarising these!

D Language Foundation December 2023 Monthly Meeting Summary

[Mike Parker via Digitalmars-d-announce]

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: D Language Foundation November 2023 Monthly Meeting Summary

[Steven Schveighoffer via Digitalmars-d-announce]

On Monday, 4 March 2024 at 11:07:07 UTC, Mike Parker wrote:


### 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."


Sorry, I can't remember what I talked about in that timeframe. 
Lost to history I guess.


(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).)


The spec is updated (that link is dead because I deleted the 
branch, always good to use the `y` button on github to get a link 
to the direct commit). You can still see the PR here: 
https://github.com/dlang/dlang.org/pull/3768


To see the spec, just go to [the current 
spec](https://dlang.org/spec/istring.html), for some reason we 
publish the master branch of the spec as the current release.


-Steve

Re: D Language Foundation November 2023 Monthly Meeting Summary

[jmh530 via Digitalmars-d-announce]

On Monday, 4 March 2024 at 11:19:57 UTC, Mike Parker wrote:

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.


Regardless, they make for good reading. Thanks!

D Language Foundation October/November 2023 Planning Updates

[Mike Parker via Digitalmars-d-announce]

## 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

[Mike Parker via Digitalmars-d-announce]

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.

Re: D Language Foundation November 2023 Monthly Meeting Summary

[Sergey via Digitalmars-d-announce]

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..

D Language Foundation November 2023 Monthly Meeting Summary

[Mike Parker via Digitalmars-d-announce]

# 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: D Language Foundation October Monthly Meeting Summary

[Mike Shah via Digitalmars-d-announce]

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

[ryuukk_ via Digitalmars-d-announce]

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

[Konstantin via Digitalmars-d-announce]

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

[ryuukk_ via Digitalmars-d-announce]

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

[zjh via Digitalmars-d-announce]

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

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

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

[Mike Parker via Digitalmars-d-announce]

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 

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[monkyyy via Digitalmars-d-announce]

On Wednesday, 6 December 2023 at 16:28:08 UTC, Mike Parker wrote:


## The Next Meetings
We had our October monthly meeting one week after this meeting. 
The next quarterly should happen on January 5, 2024. We had no 
regular planning sessions in October, but two workgroup 
meetings took place regarding DMD-as-a-library. The monthly 
meeting summary is coming next, then I'll publish an update 
about the workgroup meetings.


https://monkyyyscience.substack.com/p/d-data-structures

please add this to the agenda

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Dukc via Digitalmars-d-announce]

On Monday, 11 December 2023 at 19:55:38 UTC, Timon Gehr wrote:
There is the following trick. Not ideal since the length cannot 
be inferred, but this successfully injects alloca into the 
caller's scope.


Wow, what a great hack - I'd have never came up with that!

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Bastiaan Veelo via Digitalmars-d-announce]

On Monday, 11 December 2023 at 19:55:38 UTC, Timon Gehr wrote:

... this successfully injects alloca into the caller's scope.

```d
import core.stdc.stdlib:alloca;
import std.range:ElementType;
import core.lifetime:moveEmplace;

struct VLA(T,alias len){
T[] storage;
this(R)(R initializer,return void[] 
storage=alloca(len*T.sizeof)[0..len*T.sizeof]){

this.storage=cast(T[])storage;
foreach(ref element;this.storage){
assert(!initializer.empty);
auto init=initializer.front;
moveEmplace!T(init,element);
initializer.popFront();
}
}
ref T opIndex(size_t i)return{ return storage[i]; }
T[] opSlice()return{ return storage; }
}

auto vla(alias len,R)(R initializer,void[] 
storage=alloca(len*ElementType!R.sizeof)[0..len*ElementType!R.sizeof]){

return VLA!(ElementType!R,len)(initializer,storage);
}

void main(){
import std.stdio,std.string,std.conv,std.range;
int x=readln.strip.to!int;
writeln(vla!x(2.repeat(x))[]);
}
```


You guys are great!

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Nicholas Wilson via Digitalmars-d-announce]

On Monday, 11 December 2023 at 08:24:55 UTC, Bastiaan Veelo wrote:
On Sunday, 10 December 2023 at 22:59:06 UTC, Nicholas Wilson 
wrote:
Or you could use grep with `--output-ll` as noted by Johan 
https://github.com/ldc-developers/ldc/issues/4265#issuecomment-1376424944 although this will be with that `workaroundIssue1356` applied.


Thanks for highlighting this, as I must have forgotten. I 
should be able to create a CI job that checks this as part of 
the release. This will give us the confidence that we need.


I should note that regex will need some updating for the most 
recent LLVMs that have opaque pointers enabled:


`ptr byval\(%[a-zA-Z_][a-zA-Z0-9_\.]*\) align`

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Sergey via Digitalmars-d-announce]

On Monday, 11 December 2023 at 22:04:34 UTC, Nicholas Wilson 
wrote:
And please do get in touch with Bruce Carneal if you want some 
tips and insight with the practical and applied side of 
dcompute (also with auto-vectorisation) as he has used it a lot 
more than I have.


dcompute needs some love: 
https://github.com/libmir/dcompute/pull/74



Cheers, I look forward to some large speed increase reports.


it will be amazing to see such reports

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Nicholas Wilson via Digitalmars-d-announce]

On Monday, 11 December 2023 at 08:24:55 UTC, Bastiaan Veelo wrote:
On Sunday, 10 December 2023 at 22:59:06 UTC, Nicholas Wilson 
wrote:
Always happy to help if you're interested in looking into 
using dcompute.


Thank you, I'll let you know!


And please do get in touch with Bruce Carneal if you want some 
tips and insight with the practical and applied side of dcompute 
(also with auto-vectorisation) as he has used it a lot more than 
I have.


Or you could use grep with `--output-ll` as noted by Johan 
https://github.com/ldc-developers/ldc/issues/4265#issuecomment-1376424944 although this will be with that `workaroundIssue1356` applied.


Thanks for highlighting this, as I must have forgotten. I 
should be able to create a CI job that checks this as part of 
the release. This will give us the confidence that we need.


-- Bastiaan.


Cheers, I look forward to some large speed increase reports.

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Timon Gehr via Digitalmars-d-announce]

On 12/11/23 20:55, Timon Gehr wrote:


There is the following trick. Not ideal since the length cannot be 
inferred, but this successfully injects alloca into the caller's scope.




I see Nick already brought it up.

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Timon Gehr via Digitalmars-d-announce]

On 12/6/23 17:28, Mike Parker wrote:



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.


There is the following trick. Not ideal since the length cannot be 
inferred, but this successfully injects alloca into the caller's scope.


```d
import core.stdc.stdlib:alloca;
import std.range:ElementType;
import core.lifetime:moveEmplace;

struct VLA(T,alias len){
T[] storage;
this(R)(R initializer,return void[] 
storage=alloca(len*T.sizeof)[0..len*T.sizeof]){

this.storage=cast(T[])storage;
foreach(ref element;this.storage){
assert(!initializer.empty);
auto init=initializer.front;
moveEmplace!T(init,element);
initializer.popFront();
}
}
ref T opIndex(size_t i)return{ return storage[i]; }
T[] opSlice()return{ return storage; }
}

auto vla(alias len,R)(R initializer,void[] 
storage=alloca(len*ElementType!R.sizeof)[0..len*ElementType!R.sizeof]){

return VLA!(ElementType!R,len)(initializer,storage);
}

void main(){
import std.stdio,std.string,std.conv,std.range;
int x=readln.strip.to!int;
writeln(vla!x(2.repeat(x))[]);
}
```

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Guillaume Piolat via Digitalmars-d-announce]

On Sunday, 10 December 2023 at 15:08:05 UTC, Bastiaan Veelo wrote:


We are looking forward to being able to safely use LDC, because 
tests show that it has the potential to at least double the 
performance.




Yes, and that's before you its excellent SIMD capabilities :)

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Bastiaan Veelo via Digitalmars-d-announce]

On Sunday, 10 December 2023 at 22:59:06 UTC, Nicholas Wilson 
wrote:
Always happy to help if you're interested in looking into using 
dcompute.


Thank you, I'll let you know!

Or you could use grep with `--output-ll` as noted by Johan 
https://github.com/ldc-developers/ldc/issues/4265#issuecomment-1376424944 although this will be with that `workaroundIssue1356` applied.


Thanks for highlighting this, as I must have forgotten. I should 
be able to create a CI job that checks this as part of the 
release. This will give us the confidence that we need.


-- Bastiaan.

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Bastiaan Veelo via Digitalmars-d-announce]

On Sunday, 10 December 2023 at 18:16:05 UTC, Nick Treleaven wrote:
You can call `alloca` as a default argument to a function. The 
memory will be allocated on the caller's stack before calling 
the function:

https://github.com/ntrel/stuff/blob/master/util.d#L113C1-L131C2

I've just tested and it seems it works as a constructor default 
argument too.


Clever!

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Nicholas Wilson via Digitalmars-d-announce]

On Sunday, 10 December 2023 at 16:08:45 UTC, Bastiaan Veelo wrote:
On Sunday, 10 December 2023 at 15:31:55 UTC, Richard (Rikki) 
Andrew Cattermole wrote:


It will be interesting to hear how dcompute will fare in your 
situation, due to it being D code it should be an incremental 
improvement once you're ready to move to D fully.


Yes, dcompute could mean another leap forward. There are so 
many great things to look forward to.


-- Bastiaan.


Always happy to help if you're interested in looking into using 
dcompute. I can't remember if we've talked about it before, but 
if you were wanting to use it you'd need OpenCL 2.x (explicitly 
the 2.x version series, or make sure the 3.x implementation 
supports SPIRV) running on that 20 logical core box (or if it has 
GPUs attached to it, CUDA (any version should do) for NVidia GPUs 
or OpenCL 2.x (as above) on any other GPUs).


With regards to the stack corruption there is 
https://github.com/ldc-developers/ldc/blob/master/gen/abi/x86.cpp#L260 which has been there for some time. It would be fairly simple to issue a diagnostic there (although getting source location from there might be a bit tricky) for when there is both a `byval` and an alignment specified.


Or you could use grep with `--output-ll` as noted by Johan 
https://github.com/ldc-developers/ldc/issues/4265#issuecomment-1376424944 although this will be with that `workaroundIssue1356` applied.

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Nick Treleaven via Digitalmars-d-announce]

On Wednesday, 6 December 2023 at 16:28:08 UTC, Mike Parker wrote:
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.


You can call `alloca` as a default argument to a function. The 
memory will be allocated on the caller's stack before calling the 
function:

https://github.com/ntrel/stuff/blob/master/util.d#L113C1-L131C2

I've just tested and it seems it works as a constructor default 
argument too.

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Bastiaan Veelo via Digitalmars-d-announce]

On Sunday, 10 December 2023 at 17:11:04 UTC, Siarhei Siamashka 
wrote:
On Sunday, 10 December 2023 at 15:08:05 UTC, Bastiaan Veelo 
wrote:
The compiler can check if `scope` delegates escape a function, 
but it only does this in `@safe` code --- and our code is long 
from being `@safe`. So it was a bit of a puzzle to find out 
which arguments needed to be `scope` and which arguments 
couldn't be `scope`.


This reminded me of 
https://forum.dlang.org/thread/myiqlzkghnnyykbyk...@forum.dlang.org
LDC has a special GC2Stack IR optimization pass, which is a 
lifesaver in many cases like this.


Interesting.

Are there some known blocker bugs, which prevent a safe usage 
of LDC in production?


This one: https://github.com/ldc-developers/ldc/issues/4265

Mike has summarized it:
LDC unfortunately had an issue that caused stack corruption on 
32-bit Windows. 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.


-- Bastiaan.

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Siarhei Siamashka via Digitalmars-d-announce]

On Sunday, 10 December 2023 at 15:08:05 UTC, Bastiaan Veelo wrote:
1) Missing `scope` storage class specifiers on `delegate` 
function arguments. This can be chalked down as a beginner 
error, but also one that is easy to miss. If you didn't know: 
without `scope` the compiler cannot be sure that the delegate 
is not stored in some variable that has a longer lifetime than 
the stack frame of the (nested) function pointed to by the 
delegate. Therefore, a dynamic closure is created, which means 
that the stack is copied to new GC-allocated memory. In the 
majority of our cases, delegate arguments are simple callbacks 
that are only stored on the stack, but a select number of 
delegates in the GUI are stored for longer. The compiler can 
check if `scope` delegates escape a function, but it only does 
this in `@safe` code --- and our code is long from being 
`@safe`. So it was a bit of a puzzle to find out which 
arguments needed to be `scope` and which arguments couldn't be 
`scope`.


This reminded me of 
https://forum.dlang.org/thread/myiqlzkghnnyykbyk...@forum.dlang.org
LDC has a special GC2Stack IR optimization pass, which is a 
lifesaver in many cases like this.


So now all cores are finally under full load, which is a 
magnificent sight! Speed of DMD `release-nobounds` is on par 
with our Pascal version, if not slightly faster. We are looking 
forward to being able to safely use LDC, because tests show 
that it has the potential to at least double the performance.


Are there some known blocker bugs, which prevent a safe usage of 
LDC in production?

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Bastiaan Veelo via Digitalmars-d-announce]

On Sunday, 10 December 2023 at 15:31:55 UTC, Richard (Rikki) 
Andrew Cattermole wrote:


It will be interesting to hear how dcompute will fare in your 
situation, due to it being D code it should be an incremental 
improvement once you're ready to move to D fully.


Yes, dcompute could mean another leap forward. There are so many 
great things to look forward to.


-- Bastiaan.

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

That is awesome to hear!

If the move towards ldc has the potential to half your run time, that is 
quite a significant improvement for your customers.


It will be interesting to hear how dcompute will fare in your situation, 
due to it being D code it should be an incremental improvement once 
you're ready to move to D fully.


Based upon the estimates here already, it seems like acquiring an LDC 
developer in house might be well worth it.

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Bastiaan Veelo via Digitalmars-d-announce]

On Wednesday, 6 December 2023 at 16:28:08 UTC, Mike Parker wrote:

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.


I have an update on this issue. But first let me clarify how 
grave this situation is (was!) for us. There are certain tasks 
that we, and our customers, need to perform that involves a 20 
logical core computer to crunch numbers for a week. This is 
painful, but it also means that a doubling of that time is 
completely unacceptable, let alone a 20-fold increase. It is the 
difference between in business and out of business.


Aside from the allocation issue, there are several other 
properties that our array implementation needs to replicate from 
Extended Pascal: being able to have non-0 starting indices, 
having value semantics, having array limits that can be 
compile-time and run-time, and function arguments that must work 
on arrays of any limits, also for multi-dimensional arrays. So 
while trying to solve one aspect, care had to be taken not to 
break any of the other aspects.


It turned out that thread contention had more than one causes, 
which made this an extra frustrating problem because just as we 
thought to have found the culprit, it did not have the effect 
that we expected.


These were the three major reasons we were seeing large thread 
contention, in no particular order:


1) Missing `scope` storage class specifiers on `delegate` 
function arguments. This can be chalked down as a beginner error, 
but also one that is easy to miss. If you didn't know: without 
`scope` the compiler cannot be sure that the delegate is not 
stored in some variable that has a longer lifetime than the stack 
frame of the (nested) function pointed to by the delegate. 
Therefore, a dynamic closure is created, which means that the 
stack is copied to new GC-allocated memory. In the majority of 
our cases, delegate arguments are simple callbacks that are only 
stored on the stack, but a select number of delegates in the GUI 
are stored for longer. The compiler can check if `scope` 
delegates escape a function, but it only does this in `@safe` 
code --- and our code is long from being `@safe`. So it was a bit 
of a puzzle to find out which arguments needed to be `scope` and 
which arguments couldn't be `scope`.
2) Allocating heap memory in the array implementation, as 
discussed in the meeting. We followed Walter's advice and now use 
`alloca`. Not directly, but using string mixin's and static 
member functions that generate the appropriate code.
3) Stale calls to `GC.addRange` and `GC.removeRange`. These were 
left over from an experiment where we tried to circumvent the 
garbage collector. Without knowing these were still in there, we 
were puzzled because we even saw contention in code that was 
marked `@nogc`. It makes sense now, because even though 
`addRange` doesn't allocate, it does need the global GC lock to 
register the range safely. Because the stack is already scanned 
by default, these calls were now superfluous and could be removed.


So now all cores are finally under full load, which is a 
magnificent sight! Speed of DMD `release-nobounds` is on par with 
our Pascal version, if not slightly faster. We are looking 
forward to being able to safely use LDC, because tests show that 
it has the potential to at least double the performance.


A big sigh of relief from us as we have solved the biggest hurdle 
(hopefully!) on our way to full adoption of D.


-- Bastiaan.

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[Sergey via Digitalmars-d-announce]

On Wednesday, 6 December 2023 at 16:28:08 UTC, Mike Parker wrote:

### Bastiaan
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.


I am kindly invite Bastiaan and his team to participate in this 
competition :) https://github.com/jinyus/related_post_gen


fixed-sized arrays will suit perfectly for the task, and it also 
has multithreading comparison! Pascal should be good over there

Re: D Language Foundation October 2023 Quarterly Meeting Summary

[ryuukk_ via Digitalmars-d-announce]

This needs to be taken out of DRuntime because DRuntime is 
distributed pre-compiled, and that ties it to a specific 
compiler API, which isn't good. Instead, we should distribute 
it as a package. It's something he'd brought up before.


Why not directly distribute DRuntime as a source? or rather, 
simplify how it can be used as a source


``dmd -i`` does the magic already, it'll be able to pick what 
ever module on the fly


That's how i use my custom runtime, as source, makes things much 
smoother to use, however, in the case of druntime, it might 
highlight some compilation speed issues


What was the rational behind distributing the runtime as a 
compiled library?

D Language Foundation October 2023 Quarterly Meeting Summary

[Mike Parker via Digitalmars-d-announce]

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: D Language Foundation August 2023 Monthly Meeting Summary

[FeepingCreature via Digitalmars-d-announce]

On Saturday, 2 September 2023 at 20:27:04 UTC, Bonarc wrote:
On Wednesday, 30 August 2023 at 14:19:03 UTC, FeepingCreature 
wrote:
When you want to react to ~every keypress in a language server 
impl with updated coloring, it starts to be problematic. Think 
in terms of "UI feedback" rather than "project compilation".


You only need an AST for this though right? Not a full 
compilation?


Depends if you want language server info, ie. types, docs, etc. 
You can do very clever things here like caching symbols between 
runs, but the *naive* way is to run the frontend at least all the 
way through to sema2.

Re: D Language Foundation August 2023 Monthly Meeting Summary

[Bonarc via Digitalmars-d-announce]

On Wednesday, 30 August 2023 at 14:19:03 UTC, FeepingCreature 
wrote:
When you want to react to ~every keypress in a language server 
impl with updated coloring, it starts to be problematic. Think 
in terms of "UI feedback" rather than "project compilation".


You only need an AST for this though right? Not a full 
compilation?

Re: D Language Foundation August 2023 Monthly Meeting Summary

[harakim via Digitalmars-d-announce]

On Wednesday, 30 August 2023 at 14:19:03 UTC, FeepingCreature 
wrote:

On Friday, 25 August 2023 at 02:10:25 UTC, harakim wrote:
I'm also curious why a 500ms compile time would be generally 
recognized as way too long. Is it because it has potential to 
be faster or does it cause some legitimate problem? That's a 
question at large, not for Matheus.


When you want to react to ~every keypress in a language server 
impl with updated coloring, it starts to be problematic. Think 
in terms of "UI feedback" rather than "project compilation".


Thanks. That makes a lot of sense.

Re: D Language Foundation August 2023 Monthly Meeting Summary

[FeepingCreature via Digitalmars-d-announce]

On Friday, 25 August 2023 at 02:10:25 UTC, harakim wrote:
I'm also curious why a 500ms compile time would be generally 
recognized as way too long. Is it because it has potential to 
be faster or does it cause some legitimate problem? That's a 
question at large, not for Matheus.


When you want to react to ~every keypress in a language server 
impl with updated coloring, it starts to be problematic. Think in 
terms of "UI feedback" rather than "project compilation".

Re: D Language Foundation August 2023 Monthly Meeting Summary

[harakim via Digitalmars-d-announce]

On Friday, 25 August 2023 at 01:20:28 UTC, matheus wrote:
Reading over about other languages CT problems I wonder how 
this half second is too terrible.  =]

I barely see any difference between 500ms to 1000ms.


I love the fast compile time of D. It feels so freeing.

Contrast that to a Visual Studio solution I have with over 700 
projects and it takes 5 minutes to compile. Just compiling one 
project takes around 30s. That doesn't include the 75000 tests. 
It does bother me, but it's not so far outside the norm.


I'm also curious why a 500ms compile time would be generally 
recognized as way too long. Is it because it has potential to be 
faster or does it cause some legitimate problem? That's a 
question at large, not for Matheus.

Re: D Language Foundation August 2023 Monthly Meeting Summary

[matheus via Digitalmars-d-announce]

On Tuesday, 22 August 2023 at 12:59:12 UTC, Mike Parker wrote:

...
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.

...


Reading over about other languages CT problems I wonder how this 
half second is too terrible.  =]


I mean I'm not against Robert's complain, I don't know how 
complex his software is, and CT maybe is really a problem for him.


But for example where I work we use C# and so on, and CT is not 
great either, and if it is a web project, well just to start a 
local server and so on takes much more than 1 second, in fact I'd 
trade many things to have this 1 second or anything closer to 
that.


Of course if you measure things and keep watching you will see 
the difference, but in daily basis, while changing code, 
compiling etc. I barely see any difference between 500ms to 
1000ms.


Matheus.

PS: I'm ESL please if anything sound rough, forgive me! I'm just 
sharing a thought.

Re: D Language Foundation August 2023 Monthly Meeting Summary

[Adam D Ruppe via Digitalmars-d-announce]

On Tuesday, 22 August 2023 at 21:36:49 UTC, An Pham wrote:
1. DMD does not have consistent way of defining system 
attribute which can cause conflict with user attribute (DMD 
system attribute should start with underscore character, "_")


Not true, these attributes follow module namespacing rules. This 
is how ldc and gdc do all their special extensions too.


2. If old DMD version can not handle new pragma identifier, it 
is because the list is hardcoded. Should have/add ignore pragma 
identifier list defined in sc.ini so that it can be updated at 
will without rebuild


Even if you changed this, it wouldn't matter, since the change 
wouldn't be present in the old compilers you want to support!


3. DMD has attribute soup problem because it does not have 
negate setting.


This is true but doesn't apply here.

Re: D Language Foundation August 2023 Monthly Meeting Summary

[An Pham via Digitalmars-d-announce]

### 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.




Please use "pragma" to be consistent with other static 
constructors. There are few reasons to do so
1. DMD does not have consistent way of defining system attribute 
which can cause conflict with user attribute (DMD system 
attribute should start with underscore character, "_")
2. If old DMD version can not handle new pragma identifier, it is 
because the list is hardcoded. Should have/add ignore pragma 
identifier list defined in sc.ini so that it can be updated at 
will without rebuild
3. DMD has attribute soup problem because it does not have negate 
setting. If top module has
"@nogc:" and later a function that supports garbage collect 
should just use its negate form "@!nogc"
4. DMD attribute should/must not use negate word form so @nogc -> 
@!gc 


Cheers

Re: D Language Foundation August 2023 Monthly Meeting Summary

[max haughton via Digitalmars-d-announce]

On Tuesday, 22 August 2023 at 12:59:12 UTC, Mike Parker wrote:


### 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.


Follow the memory. I don't think the exceptions will make any 
difference at all. The compiler allocates soo much 
unnecessary memory and lays out what it does use very badly. 
This, and doing less work, is to way to make an algorithm whose 
complexity you can't change faster. I have recently started using 
a tool called bytehound which can show you some nice metrics from 
allocations via LD_PRELOAD-ing a magic .so rather than emulation 
or recompilation, we should generate (I will do this during dconf 
perhaps) reports at CI time to find hotspots where possible.


Using some kind of copy-on-write would be interesting because the 
compiler preemptively allocates a lot during semantic analysis.


Also please check that using the new -nothrow doesn't break the 
ICE error messages and so on when its enabled for the compiler.


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.


A lot of this time is actually just linking druntime (approx 2/3 
of the ~.3s on my machine), for the record, rather than literally 
object.d being compiled.



### 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 

D Language Foundation August 2023 Monthly Meeting Summary

[Mike Parker via Digitalmars-d-announce]

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 

Re: D Language Foundation July 2023 Monthly Meeting Summary

[Martin Tschierschke via Digitalmars-d-announce]

On Friday, 11 August 2023 at 13:37:57 UTC, Mike Parker wrote:
The D Language Foundation's monthly meeting for July 2023 took 
place on the 14th.

[...]

The idea was that once a library works in D and is debugged, it 
will stay working in D unless it's something we can't live with 
in older code.


I am very happy, that the basic idea behind an LTS Version was 
discussed, with a/this outcome!


Thank you, to the DLF Team!

Best regards EmTee

Re: D Language Foundation July 2023 Monthly Meeting Summary

[Dukc via Digitalmars-d-announce]

On Friday, 11 August 2023 at 13:37:57 UTC, Mike Parker wrote:

__void initialing Booleans__

Dennis wasn't yet finished. The last item he had for us was [a 
PR he had submitted](https://github.com/dlang/dmd/pull/15362) 
that marks as `@system` the void initialization of a `bool`, or 
anything that contains a Boolean, under the system variables 
preview. The compiler likes to avoid bounds checks if you index 
with a bool because it knows it can only be zero or one, but 
when the bool is void initialized, it might be something bigger 
than that and can corrupt memory. (The PR is attempting [to fix 
an issue](https://issues.dlang.org/show_bug.cgi?id=20148) 
brought up in [our Gripes & Wishes 
campaign](https://github.com/dlang/vision-document/blob/main/gripes-wishes-feedback.md)).


He said there were a few different opinions on what should 
happen here. One is for every void initialization to be 
`@system`, but that's a bigger breaking change that he doesn't 
think is going to happen.


Would not be recommended anyway. It'd mean any union with `bool` 
would have to be `@system`.


It might be helpful to consider `bool` a type that has unsafe 
bit patterns. Walter said he would have to think about it, and 
thanked Dennis for bringing it up.


I think `bool` other than 0 or 1 should be allowed, but have 
implementation defined behaviour:


```D
if(*cast(bool) new byte(2)) // implementation defined whether 
executed

// true or false, implementation defined
auto x = *cast(bool) new byte(2) && *cast(bool) new byte(2)
// true or false, implementation defined
auto y = *cast(bool) new byte(2) == *cast(bool) new byte(2)
// same as bool z = void
auto z = *cast(bool) new byte(2) & *cast(bool) new byte(2)
// not implementation defined anymore
z = true;
```

This unfortunately means that dmd has to stop assuming bool bit 
pattern of bool.

Re: D Language Foundation July 2023 Monthly Meeting Summary

[harakim via Digitalmars-d-announce]

Addressing deprecations, I think deprecation messages are good if 
we are writing code that will break things. I would be surprised 
if anyone wanted these off by default for *new* code they write.


I can see a case for suppressing new deprecations in existing 
code so you don't lose the warns/errors in the noise and so you 
can stop the bleeding by catching deprecations in new code. I 
think it would be interesting to see what the demand is for this. 
If it is enough demand (although I assume still not a lot) I 
think the compiler could actually be changed to do a shoddy job 
of this fairly easily, so long as there is a common function 
called to output a warn/error/deprecation. It would involve 2 
changes to that/those functions: 1. if they want to suppress all 
existing warn|error|deprecation, output to the file instead. 2. 
If they specified a file of suppressions, check that before 
output. I feel like this is a temporary solution to a temporary 
problem that probably doesn't affect a lot of people.


I know this idea will not be popular, but I think deprecations 
should be on by default and this solution as a temporary measure 
would be better than turning off deprecations by default. More 
feedback would be needed to determine what the extent and 
severity of this deprecation message issue is.


The DIP 1000 deprecations are different because they probably 
should not exist based on the discussion. It is no fault of the 
developers and there is nothing reasonable they should do.


On Friday, 11 August 2023 at 13:37:57 UTC, Mike Parker wrote:
He said he was aware of discussions of how rapid our releases 
were and that people wanted to slow down, but he didn't think 
making a decision based on a forum post would be appropriate, 
and this meeting wasn't the right forum to decide whether we 
should change our release schedule.


As one of the strongest proponents of backwards compatibility, I 
agree that I would like a sustainable solution to this problem. 
The language has to change over time and breaking changes will 
have to happen. If the solution is not sustainable, it will get 
pushed aside. I think the issue is making the changes affect 
users an acceptable amount, not all or nothing.


I have been thinking off and on why this is such a large problem 
in D for me and has barely even registered as an issue in other 
languages. Four of the reasons that come up each time are:
1. D is still in the hobby phase for me. I put my projects down 
for longer periods of time.
2. I compile all my D dependencies from source. Other than 
Javascript*, I use pre-compiled libraries for projects in all 
other languages.
3. In other languages, there are enough developers that a few 
dozen or hundred well-maintained libraries exist to cover the 
basics.
4. D seems to change here and there where other languages have 
clearly defined roadmaps.


I think 1, 3 and probably 4 will become non-issues if D becomes a 
popular language.


For now, I do wonder why we can't change from building all 
dependencies to just including libraries. If that binary 
interface was stable, the language could change quite a bit and 
maybe it's less of an issue. There is always the option to build 
from source, but if third parties included the compiled library, 
it could keep working long after it stopped compiling.


Another option would be having the library maintainer version 
their library and the compiler compile old versions to link. 
Again, this is based off the assumption that maintaining the 
backwards compatibility of a binary interface is simpler than 
maintaining it in the source.


That wouldn't help with user's immediate projects not compiling, 
but with an upgrade tool or guide, that would be less of an issue 
because you usually know the code. It could also be solved by LTS 
versions or just using an old compiler version. In any case, I 
see any solution to stability as a temporary solution to a 
problem that will not be as big in 5 or 10 years.


*Javascript is an all around pile of garbage and it also rarely 
changes in a significant way. Also, some python libraries I use 
probably come as source.

Re: D Language Foundation July 2023 Monthly Meeting Summary

[Brian Callahan via Digitalmars-d-announce]

On Friday, 11 August 2023 at 13:37:57 UTC, Mike Parker wrote:

### Walter
Walter said we had already covered most of what he'd wanted to 
talk about. Aside from that, he was focused on bug fixes, going 
through the deprecation list, and looking into [adding support 
for the ENDBR 
instructions](https://github.com/dlang/dmd/pull/15415) to the 
DMD backend (as requested [in a forum post from Brian 
Callahan](https://forum.dlang.org/thread/ertsopsczhtgstoqu...@forum.dlang.org) so that the compiler could continue to work on OpenBSD). That was all he had for us.


And a big thank you to Walter and the LDC team for moving quickly 
on this. I've updated all the OpenBSD D packages and all is well.

Re: D Language Foundation July 2023 Monthly Meeting Summary

[jmh530 via Digitalmars-d-announce]

On Monday, 14 August 2023 at 12:20:50 UTC, Dom DiSc wrote:

On Monday, 14 August 2023 at 08:42:17 UTC, claptrap wrote:
Maybe if the compiler detects that deprecated features are 
being used it could add a line to the output...


"To check for usage of deprecated features use the '-wo' 
switch"


A simple 1 line "friendly reminder" instead of pages of 
warnings, surely people could live with that?


Jup, that's a very good idea.


Yup. It would be nice if the message would only appear if 
deprecated features are actually being used.

Re: D Language Foundation July 2023 Monthly Meeting Summary

[Ogi via Digitalmars-d-announce]

On Monday, 14 August 2023 at 08:42:17 UTC, claptrap wrote:
A simple 1 line "friendly reminder" instead of pages of 
warnings, surely people could live with that?


Well, given that D compiler is also a unittesting tool, codecov 
analyzer, documentation generator, profiler, static analyzer, 
build system, and nowadays also a C compiler, it could also be a 
linter.

Re: D Language Foundation July 2023 Monthly Meeting Summary

[Dom DiSc via Digitalmars-d-announce]

On Monday, 14 August 2023 at 08:42:17 UTC, claptrap wrote:
Maybe if the compiler detects that deprecated features are 
being used it could add a line to the output...


"To check for usage of deprecated features use the '-wo' switch"

A simple 1 line "friendly reminder" instead of pages of 
warnings, surely people could live with that?


Jup, that's a very good idea.

Re: D Language Foundation July 2023 Monthly Meeting Summary

[claptrap via Digitalmars-d-announce]

On Friday, 11 August 2023 at 13:37:57 UTC, Mike Parker wrote:

The D Language Foundation's monthly meeting for July 2023 took

### Nick
Nick had nothing new for us but did have some comments on the 
`-wo` switch. He thought it was great. However, since there's 
no indication by default if code is using an obsolete feature, 
he felt it would be great if people could just get in the habit 
of using the new switch. That could be a sort of cultural thing.


Walter agreed it should be cultural. He had noticed this in 
GCC. There are some really bad features of C, but GCC doesn't 
warn about them by default. Users have to turn on the warnings. 
That seems okay to him and it seems to work for GCC.


Maybe if the compiler detects that depreciated features are being 
used it could add a line to the output...


"To check for usage of depreciated features uses the "-wo" swicth"

A simple 1 line "friendly reminder" instead of pages of warnings, 
surely people could live with that?

D Language Foundation July 2023 Monthly Meeting Summary

[Mike Parker via Digitalmars-d-announce]

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

[Mike Parker via Digitalmars-d-announce]

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() {
 

D Language Foundation July 2023 Quarterly Meeting Summary

[Mike Parker via Digitalmars-d-announce]

I mistakenly posted the summary in the General forum. You can 
find it here:


https://forum.dlang.org/thread/jzlympfqmwckaiuhq...@forum.dlang.org

Re: D Language Foundation June 2023 Monthly Meeting Summary

[Paul Backus via Digitalmars-d-announce]

On Thursday, 13 July 2023 at 14:00:49 UTC, Mike Parker wrote:
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.


Last time this topic came up, I did some research and found a 
proposal for slices in C23 that was ultimately rejected:


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

If they have not already, the author of this new proposal may 
wish to familiarize themself with N2660 and its reception by WG 
14.

Re: D Language Foundation June 2023 Monthly Meeting Summary

[Mike Parker via Digitalmars-d-announce]

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

[Mike Parker via Digitalmars-d-announce]

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: D Language Foundation Monthly Meeting Summary for May 2023

[harakim via Digitalmars-d-announce]

On Tuesday, 27 June 2023 at 14:18:52 UTC, Mike Parker wrote:
I still will put at least three or four weeks between the 
meetings and the summaries.


I appreciate your summary here. This was very insightful!

Re: D Language Foundation Monthly Meeting Summary for May 2023

[Mike Parker via Digitalmars-d-announce]

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: D Language Foundation Monthly Meeting Summary for May 2023

[Sergey via Digitalmars-d-announce]

On Friday, 23 June 2023 at 14:32:51 UTC, Mike Parker wrote:
The monthly meeting for May 2023 took place on Friday the 5th 
at 14:00 UTC. It lasted about an hour and a half.


Hi Mike.
Does anyone consider some automatization and application of 
modern technologies for the process of meeting summarization?


Like NN that:
* record the sound from the call
* make sound to text (with different speakers)
* make text summarization
* generate report

After that real person could verify result and make small 
corrections. It should significantly reduce effort and decrease 
time-to-market :)

Re: D Language Foundation Monthly Meeting Summary for May 2023

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

If you feel up to doing a practice talk, you're welcome to join us on 
BeerConf!

Re: D Language Foundation Monthly Meeting Summary for May 2023

[Sebastiaan Koppe via Digitalmars-d-announce]

On Friday, 23 June 2023 at 14:32:51 UTC, Mike Parker wrote:

[...]

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).


[...]


For anyone interested, this is still very much alive.

In fact, the lovely folks at https://github.com/NVIDIA/stdexec 
have validated several ideas I had for improving things, and I 
have been using any spare time I have left - which isn't much 
sadly - to incorporate these concepts.


I hope to find some time to do a lighting talk.

Re: D Language Foundation Monthly Meeting Summary for May 2023

[Dmitry Olshansky via Digitalmars-d-announce]

On Friday, 23 June 2023 at 14:32:51 UTC, Mike Parker wrote:
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.


Nice to read on what you guys are doing!

—
Dmitry Olshansky
CEO at Glow labs
https://sponsr.ru/glow
https://patreon.com/dmitry_glow_labs

D Language Foundation Monthly Meeting Summary for May 2023

[Mike Parker via Digitalmars-d-announce]

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: D Language Foundation April 2023 Monthly Meeting Summary

[bachmeier via Digitalmars-d-announce]

On Monday, 15 May 2023 at 18:15:54 UTC, jmh530 wrote:

On Monday, 15 May 2023 at 18:02:49 UTC, ryuukk_ wrote:

[snip]



It can be frustrating when you are are neck deep in some 
complicated problem to explain to people who haven't spent the 
same amount of time with it as you have.


That poster turns conversation after conversation into the same 
toxic cesspool. If human interaction is that frustrating, they 
should refrain from posting.

Re: D Language Foundation April 2023 Monthly Meeting Summary

[jmh530 via Digitalmars-d-announce]

On Monday, 15 May 2023 at 18:02:49 UTC, ryuukk_ wrote:

[snip]



It can be frustrating when you are are neck deep in some 
complicated problem to explain to people who haven't spent the 
same amount of time with it as you have.

Re: D Language Foundation April 2023 Monthly Meeting Summary

[ryuukk_ via Digitalmars-d-announce]

On Monday, 15 May 2023 at 17:44:20 UTC, Dany12L wrote:

On Monday, 15 May 2023 at 14:26:52 UTC, ryuukk_ wrote:

On Sunday, 14 May 2023 at 21:47:51 UTC, Dany12L wrote:

On Sunday, 14 May 2023 at 18:59:52 UTC, ryuukk_ wrote:

I'll end up just sticking to C if nobody understand


Fine but what do you solve? If you need memcpy you will in 
any case have to implement it yourself or use some already 
made library.

The same thing happens on D.


Please read the linked issue, all it does is it makes it 
painful for me to debug, when the solution i provide is both 
pragmatic and simple


Not only my solution works for WASM but for everytime one 
needs to port D to an esoteric platform, the WASI solution 
only work for people who use WASM AND WASI


https://github.com/ldc-developers/ldc/issues/4324


I've seen but this has been fixed so I don't understand what is 
your problem


If whoever decided to template that function overnight, without 
notes on the changelog btw, not call into libc for just memcpy:


- i wouldn't get random segfault
- i wouldn't waste days trying to figure out why my project 
wouldn't compile anymore overnight



It's not that "you don't understand", it's you CHOOSE to not 
understand


The issue is fixed, great, at what cost? that you chose to ignore

And the problem i have is, according to this Monthly Meeting, the 
issue is about to be repeated in the future, who cares about 
having a portable runtime? who cares about the users?!


The goal is still pay as you go? or am i the only one who care 
about that?

Re: D Language Foundation April 2023 Monthly Meeting Summary

[Dany12L via Digitalmars-d-announce]

On Monday, 15 May 2023 at 14:26:52 UTC, ryuukk_ wrote:

On Sunday, 14 May 2023 at 21:47:51 UTC, Dany12L wrote:

On Sunday, 14 May 2023 at 18:59:52 UTC, ryuukk_ wrote:

I'll end up just sticking to C if nobody understand


Fine but what do you solve? If you need memcpy you will in any 
case have to implement it yourself or use some already made 
library.

The same thing happens on D.


Please read the linked issue, all it does is it makes it 
painful for me to debug, when the solution i provide is both 
pragmatic and simple


Not only my solution works for WASM but for everytime one needs 
to port D to an esoteric platform, the WASI solution only work 
for people who use WASM AND WASI


https://github.com/ldc-developers/ldc/issues/4324


I've seen but this has been fixed so I don't understand what is 
your problem

Re: D Language Foundation April 2023 Monthly Meeting Summary

[ryuukk_ via Digitalmars-d-announce]

On Sunday, 14 May 2023 at 21:47:51 UTC, Dany12L wrote:

On Sunday, 14 May 2023 at 18:59:52 UTC, ryuukk_ wrote:

I'll end up just sticking to C if nobody understand


Fine but what do you solve? If you need memcpy you will in any 
case have to implement it yourself or use some already made 
library.

The same thing happens on D.


Please read the linked issue, all it does is it makes it painful 
for me to debug, when the solution i provide is both pragmatic 
and simple


Not only my solution works for WASM but for everytime one needs 
to port D to an esoteric platform, the WASI solution only work 
for people who use WASM AND WASI


https://github.com/ldc-developers/ldc/issues/4324

Re: D Language Foundation April 2023 Monthly Meeting Summary

[Dany12L via Digitalmars-d-announce]

On Sunday, 14 May 2023 at 23:53:41 UTC, max haughton wrote:

On Sunday, 14 May 2023 at 12:47:59 UTC, Mike Parker wrote:


[...]


Some thoughts on testing:

1. This (MacOS) failure has been fixed (by me). It apparently 
also occurred with some other LibCs out there prior to that 
too. In future these kinds of failures must be prioritized a 
little more aggressively, this didn't just mean "Oh well, we'll 
ignore that pipeline for a while", it meant that Phobos 
effectively didn't work on MacOS (Oops).


[...]


Please yes OMF and legacy Digital Mars tools should burn in hell.
Every time one uses DMD on Windows it's a confusion mess of these 
old things that should never be used

Re: D Language Foundation April 2023 Monthly Meeting Summary

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 15/05/2023 11:53 AM, max haughton wrote:
2. At a bigger scale: We probably have too many CI pipelines. The main 
ones that I have
in mind that really could go are the OMF pipelines --- In OMF we have 
some ancient baggage which we don't need and shouldn't want to support 
anymore: [Microsoft barely mention OMF 
anymore](https://learn.microsoft.com/en-us/search/?terms=OMF=C%2B%2B), its not the default from dmd on 32bit windows anymore, and having it in the testsuite ties us to the
Digital Mars ecosystem for likely zero benefit (Would you, reader, use 
Digital Mars if you were building C code on Windows today?)


This bit from Walter says it all I think:

> Walter said he had given up on maintaining DMC. The DMD backend had 
already diverged, and he saw no further point in maintaining DMC.


Time for OMF stuff to become optional in CI.

Re: D Language Foundation April 2023 Monthly Meeting Summary

[max haughton via Digitalmars-d-announce]

On Sunday, 14 May 2023 at 12:47:59 UTC, Mike Parker wrote:


__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).)




Some thoughts on testing:

1. This (MacOS) failure has been fixed (by me). It apparently 
also occurred with some other LibCs out there prior to that too. 
In future these kinds of failures must be prioritized a little 
more aggressively, this didn't just mean "Oh well, we'll ignore 
that pipeline for a while", it meant that Phobos effectively 
didn't work on MacOS (Oops).


2. At a bigger scale: We probably have too many CI pipelines. The 
main ones that I have
in mind that really could go are the OMF pipelines --- In OMF we 
have some ancient baggage which we don't need and shouldn't want 
to support anymore: [Microsoft barely mention OMF 
anymore](https://learn.microsoft.com/en-us/search/?terms=OMF=C%2B%2B), its not the default from dmd on 32bit windows anymore, and having it in the testsuite ties us to the
Digital Mars ecosystem for likely zero benefit (Would you, 
reader, use Digital Mars if you were building C code on Windows 
today?)


3. The testing process could also use some love in terms of 
exactly how they're setup. Does everything that should/could use 
the host compiler use that compiler? Although I think its partly 
his own doing in not exerting much control over the compiler 
codebase other than when others try to organize it, Walter is 
right that the test suite should ideally be segmented into tests 
ordered by some measure of the number of features they depend 
upon.


4. We should have either digger or something like digger (likely 
a shell script, shooting from the hip I think digger is a very 
good idea but too complicated, myself and others have all had it 
not work in mysterious ways) being checked on every PR to make 
sure its easy to reproduce.


5. Automatic bisect? When github issues are done this could be an 
interesting use of richer integration with the concept of an 
issue to make developers productive. When a bug report is filed 
it, finding the commit that caused the issue can and should be 
done by a bot.

Re: D Language Foundation April 2023 Monthly Meeting Summary

[Dany12L via Digitalmars-d-announce]

On Sunday, 14 May 2023 at 18:59:52 UTC, ryuukk_ wrote:

I'll end up just sticking to C if nobody understand


Fine but what do you solve? If you need memcpy you will in any 
case have to implement it yourself or use some already made 
library.

The same thing happens on D.

Re: D Language Foundation April 2023 Monthly Meeting Summary

[Dennis via Digitalmars-d-announce]

On Sunday, 14 May 2023 at 19:38:38 UTC, ryuukk_ wrote:

Now you suggest me to depend on WASI by default

Unbelievable

It's getting hard to maintain composure


Then I'll leave it here. There's apparently a big problem with 
the solutions I provided that I'm supposed to know, but I don't, 
and that frustrates you. I would try to inquire more, but I'm 
afraid you will only get more upset, so I won't.

Re: D Language Foundation April 2023 Monthly Meeting Summary

[ryuukk_ via Digitalmars-d-announce]

On Sunday, 14 May 2023 at 19:13:50 UTC, Dennis wrote:

On Sunday, 14 May 2023 at 18:59:52 UTC, ryuukk_ wrote:
WASI is not WASM, please don't suggest that as a solution, 
it's not, this is frustrating to read what you suggest when i 
bring to you problems


I've literally had the same problem as you (missing references 
to libc symbols when targeting WebAssembly), and solved it by 
compiling and linking wasi-libc. I can't help you when you 
reject solutions simply by calling them 'not a solution' and no 
further details.



I'll end up just sticking to C if nobody understand


How would you do array copies when using C targeting 
WebAssembly?


Do you understand what you are saying?

"Can you target WASM? no, you need WASI"

When the solution i suggested was as simple as to make that 
tempalted hook not call libc, and instead just do the memcpy 
yourself


Now you suggest me to depend on WASI by default

Unbelievable

It's getting hard to maintain composure

Re: D Language Foundation April 2023 Monthly Meeting Summary

[Dennis via Digitalmars-d-announce]

On Sunday, 14 May 2023 at 18:59:52 UTC, ryuukk_ wrote:
WASI is not WASM, please don't suggest that as a solution, it's 
not, this is frustrating to read what you suggest when i bring 
to you problems


I've literally had the same problem as you (missing references to 
libc symbols when targeting WebAssembly), and solved it by 
compiling and linking wasi-libc. I can't help you when you reject 
solutions simply by calling them 'not a solution' and no further 
details.



I'll end up just sticking to C if nobody understand


How would you do array copies when using C targeting WebAssembly?

Re: D Language Foundation April 2023 Monthly Meeting Summary

[ryuukk_ via Digitalmars-d-announce]

On Sunday, 14 May 2023 at 18:51:38 UTC, Dennis wrote:

Then my project no longer compile, thanks a lot!


When you use a custom druntime, you can't expect stability when 
you upgrade the compiler but not your druntime. The real issue 
here is that there is no proper support for WebAssembly in 
upstream druntime.


I don't expect "stability", i expect things to not require things 
it shouldn't require


depending on libc for memcpy, sorry for the word, but it's 
stupid, if you say that's stability, then i should perhaps move 
away

Re: D Language Foundation April 2023 Monthly Meeting Summary

[ryuukk_ via Digitalmars-d-announce]

On Sunday, 14 May 2023 at 18:51:38 UTC, Dennis wrote:

On Sunday, 14 May 2023 at 16:02:00 UTC, ryuukk_ wrote:
I wanted to target WASM, if your hooks call into libC, i can't 
target WASM..


Good news, there's implementations of libc for WASM


WASI is not WASM, please don't suggest that as a solution, it's 
not, this is frustrating to read what you suggest when i bring to 
you problems


I'll end up just sticking to C if nobody understand

Re: D Language Foundation April 2023 Monthly Meeting Summary

[Dennis via Digitalmars-d-announce]

On Sunday, 14 May 2023 at 16:02:00 UTC, ryuukk_ wrote:
I wanted to target WASM, if your hooks call into libC, i can't 
target WASM..


Good news, there's implementations of libc for WASM (example: 
https://archlinux.org/packages/community/any/wasi-libc/), and 
linking them doesn't even increase build time or binary size that 
much in my experience. I did this for 
[ctod](https://github.com/dkorpel/ctod/tree/master) because I had 
to (the tree-sitter library I use depends on it), but I also 
incorporated it in my other WASM projects to get a better 
`malloc/free` implementation.


You keep tell us that the plan is "pay as you go", well, sir, 
that kind of issue goes against your plan, so again, what's the 
plan?


The "pay as you go" plan relates to druntime, not libc. Not that 
we deliberately depend on libc when it's not needed (don't need 
`itoa`, we have `unsignedToTempString`), but certain libc calls 
are so standard, common, and optimized, that there's not much 
benefit in trying to roll our own implementation for it. I'm 
talking about memset, memcpy, memcmp, malloc, free, realloc, off 
the top of my head.


Even when there's not a single mention of `memcpy` in druntime, 
LDC might still even emit it causing your WASM project to fail to 
link. Just check the asm for this code:


```D
struct S { char[1000] x; }

void c()
{
S s = S.init; // emits a `memcpy` (-O0) or `memset` (-O3)
f();
}

void f(S* s);
```

There might be an obscure compiler flag to disable this, but it's 
a lot easier to just include an implementation of `memcpy`, 
`memset` and `memcmp` yourself.



Then my project no longer compile, thanks a lot!


When you use a custom druntime, you can't expect stability when 
you upgrade the compiler but not your druntime. The real issue 
here is that there is no proper support for WebAssembly in 
upstream druntime.



https://github.com/dlang/dmd/pull/14910


Nobody care anymore.


I fixed that for you: https://github.com/dlang/phobos/pull/8726

Re: D Language Foundation April 2023 Monthly Meeting Summary

[ryuukk_ via Digitalmars-d-announce]

Razvan next brought up Teodor Dutu's work on converting 
DRuntime hooks to templates. An intended side effect of this 
effort is that it should make things more usable in BetterC, 
but sometimes, getting real work done in one of these templates 
means calling into the C library (memset, memcpy, etc). This is 
an issue when there's no standard C library.


Walter said BetterC was never intended to be used without a 
standard C library, so relying on the presence of those 
functions is fine.



Mistake mistake mistake. betterC != betterLiBC

It means better C

I wanted to target WASM, if your hooks call into libC, i can't 
target WASM..


I'm pretty sure i reported an issue about this

Nobody understand the implication when they do stuff with the 
compiler


Then we end up with GC everywhere and the only way to workaround 
things is to subscribe to -betterC


You keep tell us that the plan is "pay as you go", well, sir, 
that kind of issue goes against your plan, so again, what's the 
plan?




Dependency on libC just for memcpy.

Then my project no longer compile, thanks a lot!

https://github.com/dlang/dmd/pull/14910


That reminds me of a dependency on std.exception just to do: 
``return result.array``


https://github.com/dlang/phobos/pull/8723

Nobody care anymore.

Then people wonder things are the way it is

Re: D Language Foundation April 2023 Monthly Meeting Summary

[Richard (Rikki) Andrew Cattermole via Digitalmars-d-announce]

On 15/05/2023 12:47 AM, Mike Parker wrote:
Átila said he'd been thinking about copying Herb Sutter's idea for 
zero-overhead C++ exceptions. He said the basic idea is that you get rid 
of exceptions while keeping the syntax. (Here's a link to the PDF 
).


Design work is already done.

https://github.com/rikkimax/DIPs/blob/value_type_exceptions/DIPs/DIP1xxx-RC.md

I kinda think sumtypes should go first so we can do catch all.

D Language Foundation April 2023 Monthly Meeting Summary

[Mike Parker via Digitalmars-d-announce]

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 

Re: D Language Foundation April 2023 Quarterly Meeting Summary

[Joseph Rushton Wakeling via Digitalmars-d-announce]

On Friday, 28 April 2023 at 19:50:55 UTC, max haughton wrote:
1. The conversation about formatters is not quite on the money 
wrt internals, sdfmt doesn't work as written. I will write 
something explaining the two both architecturally (politically 
really for the purposes of this debate) and also which I think 
is better.


That would be good to see.  Is `sdfmt` actually documented 
anywhere?  I can't find anything obvious, including in the source 
code.

Re: D Language Foundation April 2023 Quarterly Meeting Summary

[max haughton via Digitalmars-d-announce]

On Friday, 28 April 2023 at 14:29:47 UTC, Mike Parker wrote:
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 notes:

1. The conversation about formatters is not quite on the money 
wrt internals, sdfmt doesn't work as written. I will write 
something explaining the two both architecturally (politically 
really for the purposes of this debate) and also which I think is 
better.


2. -ftime-trace has been around for a while now. It's very good.
dmd will have it at some point (PRs already there for a good 
chunk of it's implementation). I will have time to pick it up 
again in June.

Re: D Language Foundation April 2023 Quarterly Meeting Summary

[jmh530 via Digitalmars-d-announce]

On Friday, 28 April 2023 at 16:25:03 UTC, Steven Schveighoffer 
wrote:

On 4/28/23 11:42 AM, jmh530 wrote:
2) It would be cool to have a built-in way to profile 
unittests by module. So for instance, the output would be how 
long it took the unit tests to run, broken out by module and 
then with a total.


This is a runtime thing. You can customize it:

https://dlang.org/phobos/core_runtime.html#.Runtime.extendedModuleUnitTester

-Steve


Cool.

Re: D Language Foundation April 2023 Quarterly Meeting Summary

[Steven Schveighoffer via Digitalmars-d-announce]

On 4/28/23 11:42 AM, jmh530 wrote:
2) It would be cool to have a built-in way to profile unittests by 
module. So for instance, the output would be how long it took the unit 
tests to run, broken out by module and then with a total.


This is a runtime thing. You can customize it:

https://dlang.org/phobos/core_runtime.html#.Runtime.extendedModuleUnitTester

-Steve

Re: D Language Foundation April 2023 Quarterly Meeting Summary

[jmh530 via Digitalmars-d-announce]

On Friday, 28 April 2023 at 14:29:47 UTC, Mike Parker wrote:
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.

[snip]


Thanks for these, as always.

He next brought up the persistent issue of slower compile 
times. He noted that LDC now has > a "very, very snazzy" 
command-line option, -ftime-trace, that outputs profiles of LDC 
compile times in the Chrome Trace Event format, which can then 
be seen as a flame graph in a viewer. [snip]


Two points:
1) I feel like LDC has a lot of cool features that I'm not really 
sure how to use properly
2) It would be cool to have a built-in way to profile unittests 
by module. So for instance, the output would be how long it took 
the unit tests to run, broken out by module and then with a total.

D Language Foundation April 2023 Quarterly Meeting Summary

[Mike Parker via Digitalmars-d-announce]

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