Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: This summary is quite a bit overdue. Sorry for the delay. Thanks for this, and for keeping all the details. Good work! — Bastiaan.
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 11:04:45 UTC, Steven Schveighoffer wrote: On 8/28/22 6:37 AM, Mike Parker wrote: SARC has marked a major milestone in that their 500KLOC Extended Pascal codebase has been completely transcompiled to D This is awesome! I remember that talk, and it was very interesting. Congratulations! -Steve Thank you! The process takes several times longer than anticipated, but we are not giving up :-) Although it is an important milestone, it doesn’t mean we can now all code in D. Almost all commits still happen in Pascal. I have started transpiling every commit separately, to create a commit history in D that overlaps the Pascal history for some period. Next week we plan on using the D versions of our software internally, to expose a larger surface area to testing and scrutiny. This is arguably a bigger milestone. What we all look forward to the most is the last milestone though, where we’ll freeze the Pascal repository and switch from programming in Pascal to programming in D overnight. — Bastiaan.
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: Since the meeting, Iain and I have set up a new server for the archived downloads. We've moved away from AWS and are now using Backblaze (with free bandwidth, thanks to the Bandwith Alliance and our use of Cloudflare). All 235.2 GB of DMD downloads have been moved. Iain can correct me if I'm wrong, but I believe this is active right now, so anything you download from downloads.dlang.org will come from there. As for the code-signing certificate, we're trying to decide on an option that's best for us. In the meantime, the last I heard, Martin Nowak was going to put out a release of 2.100.1 without signing the Windows executable. The new download archive on Backblaze is still on stand-by for now. After the 2.100.2 release proper has gone out, we'll make the switch. What is active right now on Backblaze is the revival of https://docarchives.dlang.io
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: ### Bastiaan SARC has marked a major milestone in that their 500KLOC Extended Pascal codebase has been completely transcompiled to D (if you aren't aware of this project, you might enjoy Bastiaan's talks from DConf 2017, [Extending Pegged to Parse Another Programming Language](https://youtu.be/NoAJziYZ4qs), and DConf 2019, [Transcompilation into D](https://youtu.be/HvunD0ZJqiA)). Congratulations! ### Mathias Mathias had a few things to bring up. The first was [Issue 23164](https://issues.dlang.org/show_bug.cgi?id=23164), which he encountered when preparing his DConf talk. In short, it looks like dmd is moving structs that have copy constructors. Isn't this exactly what [`opPostMove`](https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1014.md) is for?
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: with Martin noting that this isn't a problem if you're properly encapsulating your types. While ignoring the issues/drawbacks that has been brought up when involving certain solutions to achieve this. I can't argue against a wall here. - Alex
Re: D Language Foundation July 2022 Quarterly Meeting Summary
Dennis brought up a discussion about reducing the size of
object.d that came up in a PR thread. Specifically, moving
things into separate modules, then making object.d a list of
public imports would make it easier to maintain a custom
object.d.
It is unfortunate that my suggestion was used to push an other
idea
A public import, is the same problem
My issue with `object.d` is it is shadowing symbols
`destroy` for example
If i want a `destroy` function, i call destroy, but if i made a
typo in my function or forgot to actually create it, then it'll
silently call `destroy` from `object.d` without letting you know
about it, that's what prompted me to make the PR
I now banned the `destroy` name, and instead use `dispose` as
people on the IRC suggested me to do, wich in restrospec is a
better word indeed
But i figured i should not expect such changes, so instead i now
compile with `-betterC` and a custom `object.d` for all of my
projects
The other unfortunate thing is i now have to deal with issues
like this, and incorporate hacks into my codebases for LDC:
https://github.com/ldc-developers/ldc/issues/2425#issuecomment-1193330845
The consensus was that with D's built-in ability to
differentiate symbols (FQN, static imports), this isn't a
problem. Iain closed the PR after the meeting, noting that we
agreed something needs to be done about object.d, "but not
this".
The worst part is that file should not be needed at all to begin
with
You can't do simple ptr/slice casting without it, and you can't
use enums without it
If `destroy` is essential to D, then it should be upgraded to a
builtin and reserved keyword, if it is just an utility function,
then it shouldn't be in the global scope, or it should be
prefixed `__destroy`
There needs a way to differentiate functions used for language
support like `switch` and `cast` with other utility functions, 2
different concerns
This is what i have to carry to opt out this specific thing
(luckily i do not use any other features): (see at the end of the
post)
And one recent issue i had, because of the custom `object.d`
route:
https://i.imgur.com/Ye9ewJP.png
I couldn't figure out what caused the issue, thanks to Adam,
compiling with `dmd -v` pointed out the problematic import:
`import core.sys.windows.threadaux;`
Pay as you go is the way to go, but the experience should be
drastically improved imo
```D
module object;
alias size_t = typeof(int.sizeof);
alias ptrdiff_t = typeof(cast(void*)0 - cast(void*)0);
alias sizediff_t = ptrdiff_t; // For backwards compatibility only.
/**
* Bottom type.
* See $(DDSUBLINK spec/type, noreturn).
*/
alias noreturn = typeof(*null);
alias hash_t = size_t; // For backwards compatibility only.
alias equals_t = bool; // For backwards compatibility only.
alias string = immutable(char)[];
alias wstring = immutable(wchar)[];
alias dstring = immutable(dchar)[];
bool __equals(T1, T2)(scope const T1[] lhs, scope const T2[] rhs)
@nogc nothrow pure @trusted
if (__traits(isScalar, T1) && __traits(isScalar, T2))
{
if (lhs.length != rhs.length)
return false;
static if (T1.sizeof == T2.sizeof
// Signedness needs to match for types that promote to
int.
// (Actually it would be okay to memcmp bool[] and byte[]
but that is
// probably too uncommon to be worth checking for.)
&& (T1.sizeof >= 4 || __traits(isUnsigned, T1) ==
__traits(isUnsigned, T2))
&& !__traits(isFloating, T1) && !__traits(isFloating, T2))
{
if (!__ctfe)
{
// This would improperly allow equality of integers
and pointers
// but the CTFE branch will stop this function from
compiling then.
import core.stdc.string : memcmp;
return lhs.length == 0 ||
0 == memcmp(cast(const void*) lhs.ptr, cast(const
void*) rhs.ptr, lhs.length * T1.sizeof);
}
}
foreach (const i; 0 .. lhs.length)
{
static if (__traits(isStaticArray, at(lhs, 0))) // "Fix"
for -betterC
{
if (at(lhs, i)[] != at(rhs, i)[]) // T1[N] != T2[N]
doesn't compile with -betterC.
return false;
}
else
{
if (at(lhs, i) != at(rhs, i))
return false;
}
}
return true;
}
bool __equals(T1, T2)(scope T1[] lhs, scope T2[] rhs)
if (!__traits(isScalar, T1) || !__traits(isScalar, T2))
{
if (lhs.length != rhs.length)
{
return false;
}
if (lhs.length == 0)
return true;
static if (useMemcmp!(T1, T2))
{
if (!__ctfe)
{
static bool trustedMemcmp(scope T1[] lhs, scope T2[]
rhs) @trusted @nogc nothrow pure
{
pragma(inline, true);
import core.stdc.string : memcmp;
return memcmp(cast(void*) lhs.ptr, cast(void*)
rhs.ptr, lhs.length * T1.sizeof) == 0;
}
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Monday, 29 August 2022 at 03:32:08 UTC, Ruby The Roobster wrote: The whole point of a struct in an OOP Language is to allow user defined types that prohibit inheritance. Why do someone like `C++`, because it gives you freedom, no matter `what you do`.
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Monday, 29 August 2022 at 03:04:15 UTC, zjh wrote: On Monday, 29 August 2022 at 02:58:33 UTC, zjh wrote: On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: and how some people would prefer that it be private-to-the-class instead. Encapsulation by class can quickly determine the `problem`. The smaller the `encapsulate`, the better. It would be better if `struct` could also be inherited. The whole point of a struct in an OOP Language is to allow user defined types that prohibit inheritance.
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Monday, 29 August 2022 at 02:58:33 UTC, zjh wrote: On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: Compilation speed is less dependent on file size and more dependent on the `number of files`. Isn't that `strange`? If so, split the files for `editing` and merge them for `compiling`.
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Monday, 29 August 2022 at 02:58:33 UTC, zjh wrote: On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: and how some people would prefer that it be private-to-the-class instead. Encapsulation by class can quickly determine the `problem`. The smaller the `encapsulate`, the better. It would be better if `struct` could also be inherited.
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: Compilation speed is less dependent on file size and more dependent on the `number of files`. Isn't that `strange`?
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: This summary is quite a bit overdue. Sorry for the delay. One of the most interesting posts! Thank you for sharing that, Mike. And for the work of all participants and committers.
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: This summary is quite a bit overdue. Sorry for the delay. [...] Thanks for the detailed update.
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On 8/28/22 6:37 AM, Mike Parker wrote: SARC has marked a major milestone in that their 500KLOC Extended Pascal codebase has been completely transcompiled to D This is awesome! I remember that talk, and it was very interesting. Congratulations! -Steve
D Language Foundation July 2022 Quarterly Meeting Summary
This summary is quite a bit overdue. Sorry for the delay. The July 8 D Language Foundation meeting was one of our quarterly meetings. In the first part of these meetings, representatives from industry join us to provide us with updates, notify us of issues they're experiencing, and provide us with feedback and ideas. The second part is the typical monthly meeting addressing foundation business. The industry reps are always invited to stick around for it and usually do. For this meeting, we had two new faces join us: Paul and Robert Toth of Ucora. [They let us know back in June](https://forum.dlang.org/post/oxapxadxxkrujnhfe...@forum.dlang.org) that the company has been using D for years. We invited them to join us for our quarterlies, and they accepted. We hope we can help resolve any D issues they may face, and we welcome their feedback on the D user experience. ## The meeting The meeting took place on July 8 at 14:00 UTC. The following people attended: Walter Bright (DLF) Iain Buclaw (DLF/GDC) Ali Çehreli (DLF/Mercedes Benz R & D North America) Max Haughton (DLF/Symmetry) Martin Kinkelin (DLF/LDC) Dennis Korpel (DLF) Mario Kröplin (Funkwerk) Mathias Lang (DLF/Symmetry) Razvan Nitu (DLF) Robert Schadek (Symmetry) Paul Toth (Ucora) Robert Toth (Ucora) Bastiaan Veelo (SARC) Joseph Rushton Wakeling (Frequenz) ### Mario Funkwerk had a problem [with Issue #23234](https://issues.dlang.org/show_bug.cgi?id=23234). There was a little discussion about the issue, and that Funkwerk has a workaround for now, but Razvan put it on his list of priority issues and subsequently resolved it. Mario said they sometimes run into issues like this when they update the compiler after a long time, or when Mathis when they try something weird (i.e., when Mathis has ideas and they find new areas in the compiler that don't work as expected). On the other hand, they've been using D for well over a decade. They have their own set of libraries and the solutions to their problems are usually straightforward. D has been a big help in their work. ### Bastiaan SARC has marked a major milestone in that their 500KLOC Extended Pascal codebase has been completely transcompiled to D (if you aren't aware of this project, you might enjoy Bastiaan's talks from DConf 2017, [Extending Pegged to Parse Another Programming Language](https://youtu.be/NoAJziYZ4qs), and DConf 2019, [Transcompilation into D](https://youtu.be/HvunD0ZJqiA)). Now they are increasing their testing and working out other steps they need to take before going into production. One of those steps is internationalization. For that, they're using GNU getext, and a couple of weeks before the meeting had released [their D package for interfacing it on dub](https://code.dlang.org/packages/gettext). He said they would soon be releasing a package for string extraction, and that with that we'd have comprehensive support for gettext in D. He said everything is looking good, though they do have a couple of nasty bugs for which he hopes to find a solution. ### Robert S. Here I can quote Robert in full: Not much to report. The compiler's too slow. Other than that, D is the best language. ### Joe And I can quote Joe in full following Robert: What he said I think. Nothing to add from my side. ### Paul & Robert T. Robert noted that one of their new programmers has had a hard time getting up to speed with D via the existing documentation. Ucora have been working with D for about 7 years, and their primary product is written in D, so they are heavily invested. Paul's interest is in the accessibility of D to the wider programming community. He was pleased with the response to [the post he made in June](https://forum.dlang.org/thread/xpykboajqfwpbpzgf...@forum.dlang.org) with a suggestion for the D documentation. Being new to the community, for now he's just observing, but they are interested in helping out in any way they can. Bastiaan noted that in Paul's forum thread he requested that Ucora be added to the Orgs Using D page. [Max had opened a PR](https://github.com/dlang/dlang.org/pull/3326), but then got busy with other things (and has since been unable to build the website). The PR hasn't yet been merged, but I'll see about making that happen as soon as I publish this summary. Paul said that for his own purposes, the documentation is well-written and he can find what he needs. But there is an initial hurdle to get over to be able to use the documentation effectively. New programmers rely on a programming language's manual when learning the language, so he's interested in ways of making D's documentation more accessible for new users. Enabling comments on documentation pages was the only concrete suggestion he had now. Walter suggested this could be done by creating a forum thread for each page in the documentation where people can post comments. I noted that we have previously discussed overhauling the website
