digitalmars.D.announce - D Language Foundation Monthly Meeting, December 2021
- Mike Parker (155/155) Dec 26 2021 This meeting was originally supposed to take place on the fourth
- Anton Korobeynikov (7/12) Dec 27 2021 I was the one whom one must blame for LLVM Bugzilla => GitHub
- Dennis (2/4) Dec 27 2021 Is this something good or bad?
- Mike Parker (2/7) Dec 28 2021 It not a bad thing.
- =?ISO-8859-1?Q?Lu=EDs?= Ferreira (16/16) Dec 27 2021 Great news that we are moving forward with Bugzilla migration.
- bachmeier (10/25) Dec 28 2021 This would be a big step forward. I've been testing various
This meeting was originally supposed to take place on the fourth Friday in November, but given that the day before that was Thanksgiving Day in America (and is so every November), we moved it to the first Friday in December. Then given that the fourth Friday in December this year was Christmas Eve, we agreed to just stick with the first Friday each month going forward. Most of us are busy with holiday stuff in late December anyway even when the fourth Friday isn't Christmas Eve. The big item on the agenda was intended to be a discussion about moving our issue management from Bugzilla to our GitHub repositories. A couple of different initiatives to do that in recent years by different contributors ultimately stalled. You can see [this thread in the D projects repository](https://github.com/dlang/projects/issues/43) for some background. Now, Robert Schadek is eager to make this happen. So we invited him to the meeting along with Vladimir Panteleev, whose objections you can see in the link above and who is maintaining a fork of Bugzilla with enhanced features. Vladimir was set to attend, but had to pull out the day of the meeting. And so it became a two-parter. Part One took place on December 3, 2021, at 15:00 UTC and lasted just under an hour. In attendance were: Andrei Alexandrescu Walter Bright Iain Buclaw Max Haughton Martin Kinkelin Razvan Nitu Mike Parker Robert Schadek First, I proposed we either postpone the Bugzilla to GH discussion until our next meeting in January, or schedule another meeting ASAP. We agreed to the latter, and after subsequent communication with Vladimir we decided to meet on Saturday, December 11, at 15:00 UTC. The remainder of the meeting consisted of status updates from each member, some of which prompted further discussion. I asked for volunteers for a content review of a blog post I had edited (the one by Georges Toutoungis [that I published a week after the meeting](https://dlang.org/blog/2021/12/11/i-wrote-a-high-frequency-trad ng-platform-in-d/). Max volunteered. I then let everyone know that I had taken a week off after DConf Online, had begun editing the Q & A videos, and that doing so would keep me occupied for the rest of the month. (Speaking of which, Walter's video is almost ready.) One of Razvan's SAOC 2021 mentees (Teodor Dutu, working on replacing DRuntime hooks with templates) [had posted in the forums](https://forum.dlang.org/thread/hajlsppmugslhinluzos forum.dlang.org) about a performance issue he encountered in replacing the `__d_arrayctor` hook with a template, and a "hack" that is faster. Razvan summarized the performance issue in the meeting. Martin outlined a potential approach to solving it. Rather than put this on Teodor and delay his progress on his SAOC project, we agreed that Teodor should go ahead and implement his "hack" solution for now, then Razvan will explore a refactor later. Max said that he and Iain had nearly completed fixing the problems preventing DMD from working on the latest OS X. He then talked about a discovery he had made when playing around with the DMD internals which he isn't yet ready to publicize. He closed by raising questions that started a brief discussion about the performance benchmarks in Teodor's forum post (linked above). Robert was there for the Bugzilla->GH migration discussion and had nothing else new for us. Prior to the official start of the meeting, while we were waiting for everyone to appear, he initiated a discussion about some details of the migration process. Iain provided us with an update on his progress in getting the D version of the frontend into GDC. Major thorns have been Solaris and other "archaic platforms". He also discovered a problem with Walter's ImportC implementation of `__builtin_va_list` ([see https://issues.dlang.org/show_bug.cgi?id=21974)), [and he reported it in Issue https://issues.dlang.org/show_bug.cgi?id=22558). There was a bit of discussion about the problem, and it has been fixed since the meeting. Martin has been working on increasing LDC linker support. They've been defaulting to gold on Linux. LLD will become important because at work they've seen performance increases using it. He's had to make some LDC-specific DRuntime changes regarding how `ModuleInfo`s are registered. LDC will now use a special precompiled module that will be linked into every module and will register itself with DRuntime. Andrei is pleased that someone is tackling the difficult task of converting DRuntime hooks to templates for SAOC. His exploration of versioning Phobos has exposed some problems in the compiler that need to be fixed before a prototype of Phobos v2 can work. Minimizing the issues is proving difficult to do. This is currently at the top of his list. Walter talked about a refactor he had to make in the compiler because of ImportC involving tokens and expression nodes, the details of which he described [in the initial pull request](https://github.com/dlang/dmd/pull/13360). He resolved a long-standing ambiguity problem with DIP 1000. [The PR for it is still open](https://github.com/dlang/dmd/pull/13357) as I write this. He said that the issues that people raise with DIP 1000 appear to be issues with the implementation, not the concept, and he still thinks the concept is good. His major problem with ImportC right now is with the proliferation of header files that depend on C compiler extensions. He isn't sure yet what to do about it. His priority with ImportC at the moment is to fix issues with its C11 conformance. When that is ironed out, he'll get started on looking into issues like how to handle C compiler extensions. Iain used this opportunity to bring attention to [a header file he maintains](https://github.com/ibuclaw/importC/blob/main/src/keywords.c.in) to resolve some such issues. Walter suggested that this, or something like it, should be a part of the D compiler release. This prompted a discussion about how to do that and the pros and cons of dmd invoking the C preprocessor vs. incorporating Warp. Walter suggested it's just about time for dmd to start invoking the C preprocessor. Part Two took place on December 11, 2021, at 15:00 UTC. In attendance were: Walter Bright Iain Buclaw Mathias Lang Vladimir Panteleev Mike Parker Robert Schadek This meeting was exclusively focused on the question of whether we should migrate from Bugzilla to GitHub. Walter had already given his stamp of approval to the two previous initiatives, but given Vladimir's work on his Bugzilla fork, we wanted his input. Robert's primary argument is that this is a social issue, not a technical one. GitHub is where the developers are and if we want more of them working on D, we can't continue to require them to go to a separate web site and create a separate account on our Bugzilla. Migrating our issues to GH will open the door for more developers to participate. Vladimir disagrees. He says there *are* technical reasons not to migrate. He has been working on using [Bugzilla Harmony](https://github.com/bugzilla/harmony) as a replacement and has upstreamed patches to Mozilla. This version of Bugzilla accepts GitHub logins, so can allow all GH users to participate. The discussion revolved around pros and cons, as well some technical details of the migration. Problems the LLVM team encountered in their migration came up. Ultimately, Vladimir is not against moving to GitHub issues in principle and had several suggestions on how to get it done. But he believes we should give the new Bugzilla version a fair shake before making the effort. Robert estimated that he would need just over five months to prepare for the migration. Vladimir estimated that he would need around two months to get his Bugzilla version ready for production. So we all agreed to the following compromise: Robert will begin preparing for a migration to GitHub. Vladimir will go live with Bugzilla Harmony and we will evaluate it through June 15th. After that, we'll determine if it does what we want it to, or if Robert should pull the trigger on the migration. With our new first Friday schedule, our next meeting will take place on January 7, 2022. This will be a Quarterly Meeting, which means representatives from industry will attend. If you work for a company using D that doesn't currently have a regular quarterly representative, please let me know and we can invite someone from your company to join us.
Dec 26 2021
Anton Korobeynikov <anton.korobeynikov llvm.org> Dear All, On Monday, 27 December 2021 at 06:40:30 UTC, Mike Parker wrote:Robert will begin preparing for a migration to GitHub. Vladimir will go live with Bugzilla Harmony and we will evaluate it through June 15th. After that, we'll determine if it does what we want it to, or if Robert should pull the trigger on the migration.I was the one whom one must blame for LLVM Bugzilla => GitHub migration :) I will be happy to share our experience and all issues here and there. I'm not subscribed so, please CC me. -- Anton
Dec 27 2021
On Monday, 27 December 2021 at 06:40:30 UTC, Mike Parker wrote:He then talked about a discovery he had made when playing around with the DMD internals which he isn't yet ready to publicize.Is this something good or bad?
Dec 27 2021
On Monday, 27 December 2021 at 20:36:01 UTC, Dennis wrote:On Monday, 27 December 2021 at 06:40:30 UTC, Mike Parker wrote:It not a bad thing.He then talked about a discovery he had made when playing around with the DMD internals which he isn't yet ready to publicize.Is this something good or bad?
Dec 28 2021
Great news that we are moving forward with Bugzilla migration. Would be great to be in sync with the LLVM team, especially with Anton Korobeynikov, which is who was behind the whole process. You can find him on aKor_ at libera.chat IRC or #llvm channel. You can find his email on the llvm-dev mailing list or on his website=C2=A0http://anton.korobeynikov.info/. Here are some threads about the whole process that might be interesting and worth sharing: https://lists.llvm.org/pipermail/llvm-dev/2020-July/143274.html https://groups.google.com/g/llvm-dev/c/QKhiIGi79_s/m/2PPzgjqmHAAJ https://groups.google.com/g/llvm-dev/c/KunpM8Gl28g/m/nZPEXuQIAwAJ https://groups.google.com/g/llvm-dev/c/wTHkEpSeWR0/m/OHHbR_qdBAAJ https://groups.google.com/g/llvm-dev/c/szKXwikwH10/m/5oHYiSWJAQAJ https://github.com/llvm/llvm-iwg/issues/56 --=20 Sincerely, Lu=C3=ADs Ferreira lsferreira.net
Dec 27 2021
On Monday, 27 December 2021 at 06:40:30 UTC, Mike Parker wrote:This meeting was originally supposed to take place on the fourth Friday in November, but given that the day before that was Thanksgiving Day in America (and is so every November), we moved it to the first Friday in December. Then given that the fourth Friday in December this year was Christmas Eve, we agreed to just stick with the first Friday each month going forward. Most of us are busy with holiday stuff in late December anyway even when the fourth Friday isn't Christmas Eve.[...]Iain used this opportunity to bring attention to a header file he maintains to resolve some such issues. Walter suggested that this, or something like it, should be a part of the D compiler release. This prompted a discussion about how to do that and the pros and cons of dmd invoking the C preprocessor vs. incorporating Warp. Walter suggested it's just about time for dmd to start invoking the C preprocessor.This would be a big step forward. I've been testing various libraries with ImportC in an attempt to identify bugs, limitations, and workarounds. I've gotten a lot of mileage from Iain's file, in the sense that it was sufficient to get most of those files to compile. What it can't solve is duplicate function definitions across preprocessed files. That's where a compiler solution would be valuable. I assume their solution will address this.
Dec 28 2021