Re: SAOC 2022 Projects
On Monday, 29 August 2022 at 11:46:49 UTC, Mike Parker wrote: The first milestone for this year's Symmetry Autumn of Code kicks off on September 15. We have three participants this year: [...] Congratulations to all participants. I think it is a great decision to allow a long-term project to span two SAOC editions. Good luck to all the projects!
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: SAOC 2022 Projects
On 29/08/2022 11:46 PM, Mike Parker wrote: ### Lucian Danescu Lucian gave [his first DConf talk this year](https://youtu.be/ksNGwLTe0Ps?t=21650) on the subject of integrating DMD as a library with D-Scanner. And that's the project that he submitted, and that the judges accepted, for SAOC. To Lucian: If you need someone to ping for dlang-community side of things, I'm available @rikkimax for admin-y stuff.
SAOC 2022 Projects
The first milestone for this year's Symmetry Autumn of Code kicks off on September 15. We have three participants this year: ### Teodor Dutu Teo is a repeat offender. In SAOC 2021, he was one of two participants to be awarded the final payment and the trip to DConf '22 (the other being Luís Ferreira), where he gave an excellent talk on his SAOC project, [Replacing D Runtime Hooks with Templates](https://youtu.be/ksNGwLTe0Ps?t=21649). He's been making progress on it since SAOC ended, and the judges were happy to accept his proposal to continue it under SAOC 2022. This is the first time we've had someone work on the same project in two editions of SAOC. We're glad to see he's still making progress. Razvan Nitu and Eduard Staniloiu are his mentors. ### Lucian Danescu Lucian gave [his first DConf talk this year](https://youtu.be/ksNGwLTe0Ps?t=21650) on the subject of integrating DMD as a library with D-Scanner. And that's the project that he submitted, and that the judges accepted, for SAOC. Razvan Nitu and Eduard Staniloiu are his mentors. ### Vlăduț Chicoș Vlăduț based his proposal on [an idea in our projects repository](https://github.com/dlang/projects/issues/84): implementing the QUIC protocol for D. The original suggestion, and hence the proposal, was to build on top of vibe.d's `UDPConnection`. Two of the judges suggested an independent package with no hard dependency on vibe.d would be more interesting, and Vlăduț agreed to work in that direction. Vlăduț does not yet have a mentor, though he has ideas about whom to approach. In the meantime, if you're willing to participate as a mentor, please let me know and I'll put you on the list of people Vlăduț can contact. ### Planning phase Each participant is now in the project planning phase. This is the time when they're finalizing their milestones and task lists for the work they're going to do between September and January. We wish each of them the best of luck!
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`.
