www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D Language Foundation Monthly Meeting for February 2022

reply Mike Parker <aldacron gmail.com> writes:

The D Language Foundation's monthly meeting for February 2022 
took place on February 4 and lasted around 1.5 hours. The 
following foundation members, contractors, and contributors 
attended:

Walter Bright
Iain Buclaw
Ali Çehreli
Max Haughton
Martin Kinkelin
Mathias Lang
Átila Neves
Razvan Nitu
Vladimir Panteleev
Mike Parker


I opened the meeting with a question for Walter. After [a recent 
forum 
discussion](https://forum.dlang.org/post/aarigbnntabwbcuqsuzg forum.dlang.org),
someone had [submitted a DIP](https://github.com/dlang/DIPs/pull/222) that
would change the runtime behavior of the default `toString` implementation in
the `Exception` class such that it generates stack trace output only when an
environment variable is set. Should this be a DIP or an enhancement request in
Bugzilla? We had a brief discussion.

Vladimir pointed out that stack trace output is only useful when 
debug symbols are enabled.

Ali suggested that perhaps it could be configurable for 
`Exception`, but `Error` should always print. Átila and Mathias 
noted that anyone who wants this can just catch all `Exception`s 
in `main`. This doesn't handle static constructors, but they both 
said that static constructors that aren't `nothrow` are probably 
wrong anyway.

Walter said a DIP isn't needed---it's fine to post it in Bugzilla 
as an enhancement request.

Later, at the end of the meeting, Martin said he had looked into 
the DRuntime source. The stack trace handler is configurable by 
the user, so there may be no need for an enhancement request. It 
should be sufficient for the user to set the trace handler to a 
function that returns null.


Martin said he was eager to see news about the 2.099 release. He 
felt it was the right time for the stable branch to be updated as 
some important breaking changes had recently made it into the 
compiler. This brought about a discussion about the number of the 
next version after 2.099: should it be 2.0100 or 2.100? The 
latter would match what we did with the pre-1.0 releases, which 
[went up to 
0.178](https://digitalmars.com/d/1.0/changelog2.html). We moved 
on quickly from this discussion without any definitive statement, 
but my impression is that we're leaning toward 2.100.

The beta for 2.099 [was announced on February 
17](https://forum.dlang.org/thread/vlyynedwupodqcytjptn forum.dlang.org).

Martin later reported that he has worked on template emission in 
unit test mode. When compiling with `-unittest`, it used to 
behave similarly to `-allinst`, but now emissions have been 
significantly reduced. The best benchmark of ~20 projects from 
Átila showed a 36% reduction in memory usage and compile time. 
There are still some things that can be culled even more.


Iain said the most productive thing he'd done over the previous 
month was removing ~5,000 LOC from DRuntime in the form of 
redundant bindings. Other than that, he agreed with Martin about 
the stable branch.


Vladimir opened with a progress report. Back in December, [we 
discussed migrating our Bugzilla issues to 
Github](https://forum.dlang.org/post/wnnwxyjtizvhyswwqehz forum.dlang.org). An
alternative solution is to [upgrade to Bugzilla
Harmony](https://github.com/bugzilla/harmony), a project Vladimir had been
contributing to for some time. After that meeting, we agreed that Robert
Schadek would move forward with implementing his migration script, while
Vladimir would get the new Bugzilla instance set up so we can test it out in
the interim.

Unfortunately, he reported that he has encountered a blocker. He 
needs the configuration files for our active Bugzilla instance, 
but the maintainer has so far been unresponsive. For now, he will 
continue working on Bugzilla and will keep trying to get the 
configuration files. (On a side note, this is one reason why we 
plan to get all of the services in our ecosystem under one roof 
with access for multiple admins. We're thankful for all of the 
work the volunteers in our community have put into maintaining 
services for us, but we've grown well beyond the point where we 
can live with having a single point of failure for every service 
in the ecosystem.)


Ali reported that he finished his [Programming in 
D](https://ddili.org/ders/d.en/index.html) edits, saying that the 
physical book is updated as well.


Razvan gave us a report on the status of [the leaderboard for the 
Bugzilla rewards](https://bot.dlang.io/contributor_stats. He 
added asterisks next to the names of those ineligible to receive 
rewards, and he also added another page: 
https://bot.dlang.io/contributor_stats shows overall stats, and 
https://bot.dlang.io/contributor_stats_cycle shows the stats for 
the current cycle. He told us he was thinking of theming the page 
based on the DConf logo and colors from 2016/17 in Berlin, and he 
has since done so.

He also brought up the vision document.

In [the discussion thread of our September 2021 meeting 
summary](https://forum.dlang.org/post/yybthlissupxlgsgjupl forum.dlang.org), I
said the following in response to a question about the vision document:

 ...in the process of revising it, I realized it needs a 
 complete rewrite. The document we ended up with isn't what we 
 said we wanted.

 The rewrite will be a high priority for me once I wrap up the 
 DConf Online Q & A videos and get the DIP queue moving again
At the time of the meeting, I was still working on the last DConf Online video (the AUA), so I wasn't quite ready to turn my attention to it yet. I had intended at some point to propose a special meeting to discuss it, but since Razvan brought it up I suggested we hold that meeting on February 18. Everyone agreed. We did have the meeting, and you'll find a brief summary of it below. Átila had nothing to report. Mathias brought up [a PR he had submitted to dmc](https://github.com/DigitalMars/Compiler/pull/13) a year ago. It adds CI. He asked if Walter could provide feedback on it. Walter asked him to send him an email with the link, and Mathias said he would do so as soon as he rebased the PR. While putting together this summary, I followed up with Mathias. He has now rebased the PR, and I've sent Walter the link. **ImportC** Walter told us how he thinks ImportC is going to be a big deal for D. He wants to get us "over the hump" with getting it working properly. He thinks his C extension to allow importing D files in C is working out far better than he expected, and he's considering proposing it to the C committee. The biggest difficulty with ImportC is compiler extensions that we either have to implement or give up on. Walter asked Iain and Martin if they were going to implement ImportC in GDC and LDC. Iain explained that it will be used when importing a C header into a D program, but any C files passed on the command line will go through the GCC driver and be handed off to the C compiler. Walter asked if GDC could get a command-line flag to bypass the driver and pass C files to ImportC instead of GCC, and Iain said that's not possible. He and Walter brainstormed ways to do it, but Iain said GDC has no control over the `main` function. He also noted that GCC is already a good C compiler, so he doesn't see a reason to bypass it. Martin said you can currently import C headers and compile C source with ImportC in LDC, but he hasn't yet implemented the two new AST nodes that Walter implemented for ImportC in DMD's backend (initializer lists and bitfields). He hopes to handle those in the glue layer and output errors saying LDC currently has limited ImportC support. Implementing bitfields is going to take a bit of work. Walter said he now thinks having the C initializers flowing through to the backend in a new AST node was a mistake. He plans to change the implementation so that the frontend semantic routines translate them into D initializers. **Bitfields** Walter then brought up bitfields in D. He had expected it was going to be an obvious, uncontroversial feature, and was surprised by the resistance to it. The number one objection he's seen is that it would break the reflection API. He noted that bitfields will work with the reflection API without breaking anything (callers will get a field that is a union of the bitfields, so its address can be taken, and it will have a name derived from "bitfields"). We can add a traits feature that specifically fetches a bitfield. Martin said he was satisfied with that solution, but wondered what would happen when taking the address of a bitfield. Walter said that would fail to compile. Martin feels this hurts the elegance of the language just for the sake of a rare case for which there has been no big demand and for which we already have a library solution ("not great", but it works). This went into a long discussion about opportunities for compression of data structures (particularly in DMD), whether or not that's beneficial for DMD, compatibility with C, library vs. language solutions, experience reports (Mathias described how his company handled bitfields in bindings not using the library solution), improving the library solution so that it's more elegant, the bitfield implementation in ImportC, C compiler bitfield layouts, and quite a bit more. **128-bit integers** Finally, Walter said he has looked at implementing 128-bit integers (cent and ucent), but implementing them in DMD would be a nightmare. After more thought, he has decided it's probably better to implement them as a library type. He mentioned how complex numbers were ripped out of the compiler and implemented as a library feature. The work that has already been done on `cent`/`ucent` will not be wasted, as it can still be built on to implement the library type. Max on a whim began implementing the string interpolation of [the DIP under development](https://github.com/John-Colvin/YAIDIP) (not yet submitted) by Andrei and John. He asked if it's okay to go ahead and finish it up and put it behind a preview switch. Walter hadn't seen the DIP yet but noted that he was strongly opposed to any complicated string interpolation feature. The implementation of string interpolation should be easy to explain to anyone. Anything that is complicated to explain just isn't going to work. He will need to review the DIP before deciding on allowing a preview switch. I suggested finishing the named arguments implementation should be a higher priority right now, and Walter agreed. Walter stressed that named arguments need to be interchangeable with struct initializers. We'll have to keep struct initializers around for backward compatibility, but he wants named arguments to replace them generally. The vision meeting took place on February 18 at 15:00 UTC. The following members attended: Walter Bright Iain Buclaw Ali Çehreli Max Haughton Mathias Lang Átila Neves Razvan Nitu Vladimir Panteleev Mike Parker Robert Schadek One of the things we were missing from our initial conversations about the vision document last year was an overarching Vision Statement. This is the elevator pitch that describes where D is going. It isn't down at the level of specific details, but far up above. It's a broad, general statement about our long-term goals for the language. This will sit at the top of the vision document. While the rest of the document will change as priorities shift and tasks are completed, the vision statement should remain fairly constant. The more specific details in the rest of the document should all be there because they are sending us on the path described by the vision statement. I asked everyone present to brainstorm. What do you want for D? Where are we going with it? If there were an end goal, what would it be? No idea, no matter how broad or how specific, was off-limits. The more information I have to draw from, the better. Each person has their own ideas about the specifics of where we need to go, but I was confident we could find a consensus at a higher level. I'm not going to copy here every item on the list or summarize the entire discussion. The meeting lasted over an hour and we covered quite a bit of ground. However, many of the items fall under broader categories related to the usability of the language and the quality of the overall user experience (i.e., the ecosystem, Phobos). I haven't gotten to it yet, but the next step is on me. I'll draft three or four different vision statements, then we'll hone in on something that makes us happy. Once we have that, I can start assembling the details for the rest of the document. My current plan is to lay it out in three sections: **Current Focus**: This describes where Walter and Átila are currently directing their attention and what their end goals are. It also serves as a guide for volunteer contributors looking to fix bugs or make other contributions, e.g., bug categories related to Walter and Átila's work, suggestions for how to test related language features, ideas for projects that can help reach their end goals, etc. **Future Focus**: This describes possible directions toward which Walter and Átila would like to turn their attention in the future, also with suggestions for volunteer contributors. Those who feel their skills are better applied toward one of these areas than those of the current focus can do so knowing that their work will move us toward the desired goal. **Wishlist**: This is a grab bag of ideas ranging from small tasks to large projects. Some of them will be things that would be nice to have, but that Walter and Átila will never have time to work on. Some may be important tasks that don't fit into the broader focus categories above, things that either Walter or Átila will have to do at some point if no one else does. Some of these may be set up as paid contract work. I can't say with any certainty how long it will take us to get all of this together. I know many in the community are eager to see it. Speaking for myself, it's not my highest priority at the moment. I'm sure that's true for everyone else whose input will be required to get to the final version. But I *am* making sure it gets done, step-by-step, section-by-section. My loose goal is to have it completed before DConf. I'm quite late putting this summary out, so it's already almost time for our next meeting. We're scheduled to hold it on March 4 at 15:00 UTC. I plan to put forward a proposal about the next step in getting our services under one roof with multiple admins. If you have an idea or issue you'd like to bring to us at this or a future meeting, please contact me at social dlang.org and I'll see about getting it on the agenda.
Feb 27
next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote:
 **128-bit integers**
 Finally, Walter said he has looked at implementing 128-bit 
 integers (cent and ucent), but implementing them in DMD would 
 be a nightmare. After more thought, he has decided it's 
 probably better to implement them as a library type. He 
 mentioned how complex numbers were ripped out of the compiler 
 and implemented as a library feature. The work that has already 
 been done on `cent`/`ucent` will not be wasted, as it can still 
 be built on to implement the library type.
128-bit soft cent/ucent here: https://github.com/d-gamedev-team/gfm/blob/master/integers/gfm/integers/wideint.d
Feb 27
prev sibling next sibling parent Paul Backus <snarwin gmail.com> writes:
On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote:
 **ImportC**
 Walter told us how he thinks ImportC is going to be a big deal 
 for D. He wants to get us "over the hump" with getting it 
 working properly. He thinks his C extension to allow importing 
 D files in C is working out far better than he expected, and 
 he's considering proposing it to the C committee.
The idea that the legendarily-conservative C committee would be willing to consider something like `__import` for standardization strikes me as...extremely optimistic, to say the least.
Feb 27
prev sibling next sibling parent __StarCanopy <starcanopy protonmail.com> writes:
On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote:
 implementation of string interpolation should be easy to 
 explain to anyone.
I'm a very unimpressive programmer, and I have a reasonable understanding of the referenced DIP, so I hope Walter will give his blessing. Leveraging D's strengths such as the DIP does is quite cool, and if a user wants something that's similar to the typical implementation used by some other languages, then invoking `text` with an interpolated string is easy, and it will produce the expected result.
Feb 27
prev sibling next sibling parent reply meta <meta gmail.com> writes:
On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote:

 Vladimir opened with a progress report. Back in December, [we 
 discussed migrating our Bugzilla issues to 
 Github](https://forum.dlang.org/post/wnnwxyjtizvhyswwqehz forum.dlang.org). An
alternative solution is to [upgrade to Bugzilla
Harmony](https://github.com/bugzilla/harmony), a project Vladimir had been
contributing to for some time. After that meeting, we agreed that Robert
Schadek would move forward with implementing his migration script, while
Vladimir would get the new Bugzilla instance set up so we can test it out in
the interim.
I was looking forward the Github migration.. I'm not liking the constant switch from Github/bugzilla, referencing/looking for issues is also a major pain.. LLVM recently migrated fully to Github/Github Issues, that's is the way to go in my opinion.. Can't beat the nice integration and ease of access Github provides, we need stay fresh to attract new younger souls
Feb 28
parent reply bauss <jj_1337 live.dk> writes:
On Monday, 28 February 2022 at 08:52:37 UTC, meta wrote:
 On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote:

 Vladimir opened with a progress report. Back in December, [we 
 discussed migrating our Bugzilla issues to 
 Github](https://forum.dlang.org/post/wnnwxyjtizvhyswwqehz forum.dlang.org). An
alternative solution is to [upgrade to Bugzilla
Harmony](https://github.com/bugzilla/harmony), a project Vladimir had been
contributing to for some time. After that meeting, we agreed that Robert
Schadek would move forward with implementing his migration script, while
Vladimir would get the new Bugzilla instance set up so we can test it out in
the interim.
I was looking forward the Github migration.. I'm not liking the constant switch from Github/bugzilla, referencing/looking for issues is also a major pain.. LLVM recently migrated fully to Github/Github Issues, that's is the way to go in my opinion.. Can't beat the nice integration and ease of access Github provides, we need stay fresh to attract new younger souls
I sort of agree with that. I usually don't bother reporting anything because I don't like bugzilla, it would just be much more convenient to use Github.
Mar 01
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 1 March 2022 at 08:12:43 UTC, bauss wrote:
 Can't beat the nice integration and ease of access Github 
 provides, we need stay fresh to attract new younger souls
I sort of agree with that. I usually don't bother reporting anything because I don't like bugzilla, it would just be much more convenient to use Github.
New Bugzilla is much nicer (preview: https://dbugs.k3.1azy.net/), but I agree that it's not possible to beat GitHub's integration with GitHub (and GitHub does not provide the opportunity for better integration either unlike some libre competitors). On the other hand with Bugzilla we are fully in control and own our data, which allows doing a few things not possible with GitHub. This is why we're doing both approaches in parallel (Bugzilla work is currently waiting on obtaining the issues.dlang.org configuration files).
Mar 03
parent reply Arun <aruncxy gmail.com> writes:
On Thursday, 3 March 2022 at 14:33:54 UTC, Vladimir Panteleev 
wrote:
 On Tuesday, 1 March 2022 at 08:12:43 UTC, bauss wrote:
 [...]
I sort of agree with that. I usually don't bother reporting anything because I don't like bugzilla, it would just be much more convenient to use Github.
New Bugzilla is much nicer (preview: https://dbugs.k3.1azy.net/), but I agree that it's not possible to beat GitHub's integration with GitHub (and GitHub does not provide the opportunity for better integration either unlike some libre competitors). On the other hand with Bugzilla we are fully in control and own our data, which allows doing a few things not possible with GitHub. This is why we're doing both approaches in parallel (Bugzilla work is currently waiting on obtaining the issues.dlang.org configuration files).
Just curious if we looked at GitLab as an alternative to both GitHub and Bugzilla.
Mar 03
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 4 March 2022 at 06:00:06 UTC, Arun wrote:

 Just curious if we looked at GitLab as an alternative to both 
 GitHub and Bugzilla.
We're happy on GitHub and have no plans to move to GitLab.
Mar 03
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 4 March 2022 at 07:10:05 UTC, Mike Parker wrote:
 On Friday, 4 March 2022 at 06:00:06 UTC, Arun wrote:

 Just curious if we looked at GitLab as an alternative to both 
 GitHub and Bugzilla.
We're happy on GitHub and have no plans to move to GitLab.
Quoting Vladimir, "On the other hand with Bugzilla we are fully in control and own our data, which allows doing a few things not possible with GitHub". GitLab il free software, available and installable on a private server, like Bugzilla, so both the chicken and the eggs. But I fully understand that a migration to GilHub is just fine right now.
Mar 04
prev sibling parent reply Arun <aruncxy gmail.com> writes:
On Friday, 4 March 2022 at 07:10:05 UTC, Mike Parker wrote:
 On Friday, 4 March 2022 at 06:00:06 UTC, Arun wrote:

 Just curious if we looked at GitLab as an alternative to both 
 GitHub and Bugzilla.
We're happy on GitHub and have no plans to move to GitLab.
Sure. You mean, GitHub + Bugzilla?
Mar 04
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 4 March 2022 at 21:44:56 UTC, Arun wrote:
 On Friday, 4 March 2022 at 07:10:05 UTC, Mike Parker wrote:
 On Friday, 4 March 2022 at 06:00:06 UTC, Arun wrote:

 Just curious if we looked at GitLab as an alternative to both 
 GitHub and Bugzilla.
We're happy on GitHub and have no plans to move to GitLab.
Sure. You mean, GitHub + Bugzilla?
No, I mean GitHub. We're not happy with the our version of Bugzilla anymore, which is why we want to either move the issues to GitHub or see if the Bugzilla Harmony is good for us. But we have no reason to move the D projects away from GitHub to GitLab. GitLab has never entered the conversation.
Mar 04
parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Saturday, 5 March 2022 at 01:21:06 UTC, Mike Parker wrote:
 But we have no reason to move the D projects away from GitHub 
 to GitLab. GitLab has never entered the conversation.
Two reasons would be that 1) It already offers [an integration with bugzilla](https://docs.gitlab.com/ee/user/project/integrations/bugzilla.html). 2) Being open source it can be installed on your own hardware, which is the main argument being made for using bugzilla. It also has integrated CI. — Bastiaan.
Mar 05
parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 5 March 2022 at 12:39:39 UTC, Bastiaan Veelo wrote:
 On Saturday, 5 March 2022 at 01:21:06 UTC, Mike Parker wrote:
 But we have no reason to move the D projects away from GitHub 
 to GitLab. GitLab has never entered the conversation.
Two reasons would be that 1) It already offers [an integration with bugzilla](https://docs.gitlab.com/ee/user/project/integrations/bugzilla.html). 2) Being open source it can be installed on your own hardware, which is the main argument being made for using bugzilla. It also has integrated CI. — Bastiaan.
benefit. We're aiming to integrate all of our services. As I see it, the less we have to manage ourselves, the better. If we did for some reason want to migrate to GitLab, my vote would be to let them host us. But my point was, GitHub has worked well for us for years. There's no desire to move away that I'm aware of. If it ain't broke, don't fix it!
Mar 05
next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Saturday, 5 March 2022 at 14:03:38 UTC, Mike Parker wrote:
 On Saturday, 5 March 2022 at 12:39:39 UTC, Bastiaan Veelo wrote:
 On Saturday, 5 March 2022 at 01:21:06 UTC, Mike Parker wrote:
 But we have no reason to move the D projects away from GitHub 
 to GitLab. GitLab has never entered the conversation.
Two reasons would be that 1) It already offers [an integration with bugzilla](https://docs.gitlab.com/ee/user/project/integrations/bugzilla.html). 2) Being open source it can be installed on your own hardware, which is the main argument being made for using bugzilla. It also has integrated CI. — Bastiaan.
a benefit. We're aiming to integrate all of our services. As I see it, the less we have to manage ourselves, the better. If we did for some reason want to migrate to GitLab, my vote would be to let them host us. But my point was, GitHub has worked well for us for years. There's no desire to move away that I'm aware of. If it ain't broke, don't fix it!
Definitely. Personally I think moving the tickets to GitHub is a good idea, I just felt these points needed to be made for completeness. — Bastiaan.
Mar 05
prev sibling next sibling parent bauss <jj_1337 live.dk> writes:
On Saturday, 5 March 2022 at 14:03:38 UTC, Mike Parker wrote:
 On Saturday, 5 March 2022 at 12:39:39 UTC, Bastiaan Veelo wrote:
 On Saturday, 5 March 2022 at 01:21:06 UTC, Mike Parker wrote:
 But we have no reason to move the D projects away from GitHub 
 to GitLab. GitLab has never entered the conversation.
Two reasons would be that 1) It already offers [an integration with bugzilla](https://docs.gitlab.com/ee/user/project/integrations/bugzilla.html). 2) Being open source it can be installed on your own hardware, which is the main argument being made for using bugzilla. It also has integrated CI. — Bastiaan.
a benefit. We're aiming to integrate all of our services. As I see it, the less we have to manage ourselves, the better. If we did for some reason want to migrate to GitLab, my vote would be to let them host us. But my point was, GitHub has worked well for us for years. There's no desire to move away that I'm aware of. If it ain't broke, don't fix it!
I agree, I personally only use Github, so for me it's preferable that D stays on Github.
Mar 05
prev sibling parent reply forkit <forkit gmail.com> writes:
On Saturday, 5 March 2022 at 14:03:38 UTC, Mike Parker wrote:
 But my point was, GitHub has worked well for us for years. 
 There's no desire to move away that I'm aware of. If it ain't 
 broke, don't fix it!
"If it ain't broke, don't fix it!" Well.. There's 'fixing it' and there's 'improving it'. They are not the same thing.
Mar 07
parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 7 March 2022 at 08:07:11 UTC, forkit wrote:

 "If it ain't broke, don't fix it!"

 Well.. There's 'fixing it' and there's 'improving it'.

 They are not the same thing.
In my opinion, gitlab is not an improvement.
Mar 07
parent reply forkit <forkit gmail.com> writes:
On Monday, 7 March 2022 at 08:47:00 UTC, Mike Parker wrote:
 On Monday, 7 March 2022 at 08:07:11 UTC, forkit wrote:

 "If it ain't broke, don't fix it!"

 Well.. There's 'fixing it' and there's 'improving it'.

 They are not the same thing.
In my opinion, gitlab is not an improvement.
I agree ;-) I just wanted to point out, that using 'if it ain't broke, don't fix it' is not a useful rebuttal to suggestions for 'improvement'.
Mar 07
parent bauss <jj_1337 live.dk> writes:
On Monday, 7 March 2022 at 09:58:32 UTC, forkit wrote:
 On Monday, 7 March 2022 at 08:47:00 UTC, Mike Parker wrote:
 On Monday, 7 March 2022 at 08:07:11 UTC, forkit wrote:

 "If it ain't broke, don't fix it!"

 Well.. There's 'fixing it' and there's 'improving it'.

 They are not the same thing.
In my opinion, gitlab is not an improvement.
I agree ;-) I just wanted to point out, that using 'if it ain't broke, don't fix it' is not a useful rebuttal to suggestions for 'improvement'.
A lot of things wouldn't have to be added to D if D followed that philosophy for everything.
Mar 07
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote:

Just letting you know that it is posts like these that I look forward to the most, and I very much appreciate the work that goes into them. Thanks! — Bastiaan.
Feb 28
parent Mike Parker <aldacron gmail.com> writes:
On Monday, 28 February 2022 at 22:00:09 UTC, Bastiaan Veelo wrote:
 On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote:

Just letting you know that it is posts like these that I look forward to the most, and I very much appreciate the work that goes into them. Thanks! — Bastiaan.
Thank you. I'll try to get back on with my original intent to publish them a week after the meetings.
Mar 02