Re: North Korean Hackers Developing Malware in Dlang Programming Language
On Monday, 27 May 2024 at 16:17:07 UTC, aberba wrote: By Ionut Arghire: The North Korea-linked hacking group Lazarus has been observed deploying Dlang malware in attacks against organizations in the manufacturing, agriculture, and physical security sectors, Cisco’s Talos security researchers report. https://www.securityweek.com/north-korean-hackers-developing-malware-in-dlang-programming-language/ This does not belong to "Announce".. c'mon, this is a garbage article and is FUD
Re: Sokol now has official D bindings
LDC yet again is proving how essential it is for D, now that more OS are embracing ARM, having LDC available and maintained to support latest version of LLVM and all kind of platforms is a blessing The maintainer is using macOS, and his library targets many platforms including the web with WASM, both supported by LDC out of the box DMD for fast iteration time (on x86, hopefully ARM in the future) And LDC for everything else It's a deadly combo, thanks to everyone working hard on maintaining both projects
Re: Sokol now has official D bindings
It'll be interesting to know what the experience was for the maintainer to play around with D (for the first time?) From what i could gather, problems encountered: - rvalue ref params (wich led to someone telling him to use -preview=all wich led to other issues) - attributes soup - float nan default - no warning on use of uninitialized floats I think it is time to decide what to do with all these -previews, rvalue ref params should be a feature already imo For float nan default, i personally think everything should be consistent therefore 0 initialized
Sokol now has official D bindings
I just saw this yesterday, and i haven't see anybody talk about it here, so i decided to share this great news for D here Sokol is a popular gamedev library https://github.com/floooh/sokol It now officially supports D, thanks to the work led by https://github.com/kassane https://github.com/floooh/sokol/blob/master/CHANGELOG.md#13-may-2024 https://twitter.com/FlohOfWoe/status/1790043272385114421
Re: Phobos 3 Development is Open!
https://github.com/dlang/phobos/pull/8925/files#diff-647aa2ce9ebedd6759a2f1c55752f0279de8ae7ba55e3c270bd59e1f8c1a5162R131 Why can't D have its own types? Just importing this introduces dependencies on other system modules ```D import core.stdc.config; import core.stdc.stddef; // for wchar_t import core.stdc.signal; // for sig_atomic_t import core.stdc.wchar_; // for wint_t ``` Wich makes phobos harder to use on platforms without these I think Phobos as a base shouldn't depend on libc, only specific parts eg: network/event modules for example, so it becomes easier to port when required
Re: Fluid 0.6.0 — UI library for D
On Wednesday, 7 February 2024 at 15:27:34 UTC, cookiewitch wrote: On Wednesday, 7 February 2024 at 12:49:31 UTC, ryuukk_ wrote: On Wednesday, 7 February 2024 at 07:43:58 UTC, cookiewitch wrote: Windows: * Static Windows libraries for Freetype have been replaced with dynamic ones, which makes it a lot easier to compile. I am working on a PR that makes working with static libraries easier https://github.com/dlang/dmd/pull/15479 That's good to know! Sadly the issue with Freetype static libraries is something with the C/C++ Microsoft runtime. I forgot to mention it's specific to LDC — as DMD has no trouble at all. I am statically linking freetype in my game too, and have no issues, what's the issue exactly?
Re: Fluid 0.6.0 — UI library for D
On Wednesday, 7 February 2024 at 07:43:58 UTC, cookiewitch wrote: Windows: * Static Windows libraries for Freetype have been replaced with dynamic ones, which makes it a lot easier to compile. I am working on a PR that makes working with static libraries easier https://github.com/dlang/dmd/pull/15479
Re: A Conversation with Martin Kinkelin on LDC
On Sunday, 28 January 2024 at 18:11:24 UTC, Mike Parker wrote: Some of you may recall the two conversations I had with Walter a while back, part of what I called the 'D Community Conversations' series. I've long planned to get that going as a regular, monthly thing. Finally, the time has come. I want to thank Martin Kinkelin for agreeing to sit down with me to chat about his road to programming and to the D language, how he ended up as the lead maintainer of LDC, and some of the details about the role. I very much enjoyed our conversation. I hope you do, too. You can find it here: https://youtu.be/XpPV5OBJEvg The full playlist is here: https://youtube.com/playlist?list=PLIldXzSkPUXXEL-2gfragUgNC2P2Yw6au=jih87SW_4A7jwRt5 Look for the next episode on the last weekend in February. LDC is one of the most, if not THE most important project for D, it produces very fast and competitive executables, not only that but makes it possible to target all kind of platforms, including WebAssembly! Other languages dream of having this DMD + LDC combo, very fast iteration time with debug builds thanks to DMD and very fast production code thanks to LDC! It's super interesting to be able to listen to Martin's story, i keep hear about how LLVM is painful to work with, mostly during version upgrades.. I admire you, thanks!
Re: Would this be a useful construct to add to D? auto for constructor call.
On Tuesday, 23 January 2024 at 06:30:08 UTC, Jonathan M Davis wrote: That being said, I expect that it would be pretty easy to write a mixin to do something like that if you really wanted to. Also, if you're simply looking to not have to name the type, you could do dataGrid = new typeof(datagrid)(15); - Jonathan M Davis You like to turn off people before they get the chance to develop further, this is bad You should try more languages, it'll be eye opener ``dataGrid = new typeof(datagrid)(15);`` is both, verbose and ugly Besides, you seem to have missed this: https://github.com/dlang/DIPs/blob/e2ca557ab9d3e60305a37da0d5b58299e0a9de0e/DIPs/DIP1044.md https://github.com/dlang/dmd/pull/14650 It could be expanded with structs/classes So your "it can't be done" argument is already wrong
Re: Redub: A faster build system promising 90% compatibility with dub
On Saturday, 20 January 2024 at 15:25:35 UTC, Renato wrote: On Saturday, 20 January 2024 at 14:14:10 UTC, Hipreme wrote: - I have tried contributing to dub's project on parallelization, I waste 1 week trying that and could not get it working, so, I decided it would be a better use of my time into rewriting a completely new dub which would focus on being easy to read -- An example of that is how easily someone was able to integrate an experimental support to building C with it. Could you expand on that? Perhaps someone else could continue your work. While I understand you preferred to write your own system (we all probably prefer greenfield development, after all that means it's fully yours, and you can fully understand it, own it, and change it as you see fit which is a very attractive proposition), I'm afraid your project will only be alive while you have interest in maintaining it (I've seen similar projects in other languages before, often they have one or two releases before the author moves on to the next greenfield project) - unless you manage to create an active community around it, which is exceedingly difficult and might be more than you're signing up for once a lot of people join in and start demanding features - while dub, even if it's so "buggy" as you claim, is the official tool everyone is likely to continue to use, and consequently improvements to it would be highly welcome. This quote says it all: A full rebuild on Hipreme Engine reduced its compilation time from 14 seconds to 3 dub is over engineered We should encourage more of these projects, they defy the stalled status quo in D
Re: Beta 2.107.0
A string literal as an assert condition is deprecated Thanks, caught one in my project!
Re: D Language Foundation October Monthly Meeting Summary
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
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: raylib wasm soon^tm
On Saturday, 30 December 2023 at 07:13:25 UTC, monkyyy wrote: https://monkyyy.itch.io/test-wasm-missle-command https://github.com/crazymonkyyy/raylib-2024 (press f9 to change color scheme) Nearly done with my alpha todo list, schvelguy got it working on windows, so thats 3 platforms, windows(wishywashy rn), linux, wasm For what its worth I live-streamed some of it https://www.youtube.com/watch?v=ogFI2hu98wI; see examples folder for target syntax and style see readme contributing on contributing Its a mess, its pre-alpha, but its nearing the point of useful wasm Cool to see more WASM with D, i'm a bit late on my game project, but hopefully i'll be able to see progress soonish, with WASM too!
Re: NuMem - safe(r) nogc memory managment
We plan to add more memory management utilities, thereby making writing completely GC-less D code a lot more user-friendly. I'd be happy to help What D really is missing _right now_, and will hopefully get _before_ phobosv3 is a good and minimalistic Allocator API, i modeled mine around zig's, no RAII, just a simple struct with 3 function ptr
Re: NuMem - safe(r) nogc memory managment
Nice, thanks for sharing, it'll be very useful for the C++ developers who want to give D a try
Re: D Language Foundation October 2023 Quarterly Meeting Summary
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?
Re: SAOC 2023 Projects
Replace libdparse with the DMD Library in dfmt That's awesome to see tooling getting some love! thanks
Re: SerpentOS departs from Dlang
On Sunday, 17 September 2023 at 00:55:22 UTC, Richard (Rikki)
Andrew Cattermole wrote:
On 17/09/2023 11:46 AM, Adam Wilson wrote:
Kidding aside. If you do this, you might as well turn them on
everywhere. After that it's a easy stroll to a non-blocking
moving GC, which would end most complaints about the GC
(nobody complains about the .NET GC anymore).
The scope of each doesn't match up, and you'd still need the RC
specific write barriers.
So when I say write barrier what I mean is:
```d
class MyRoot : void {
void opRCWriteBarrier(size_t fieldOffset, void* pointer) {
myCyclicDetector.set(cast(void*)this, fieldOffset, pointer);
}
void opRCSub() {
if (atomicOp!"-="(this.refCount, 1) > 0)
myCyclicDetector.collect(cast(void*)this);
}
}
class Child : MyRoot {
Array!int array;
void func() {
array = new Array!int();
// this.opRCWriteBarrier(array.offsetof, cast(void*)array);
}
}
```
Only needs to support classes + structs (I think), so its
surface area is pretty small.
Oh and Walter has approved anyone to experiment with write
barriers ages ago, although nobody has.
I hope we'll see tagged union + tuple come first before that mess
you are describing, because to me this sound like a giant waste
of effort, time and opportunity
You'll never attract more people if you focus on OOP / GC, that
kind of code is repulsive to be honest
Tagged Union alone will help build libraries that doesn't require
that OOP crap and help reduce the need of a GC significantly,
more structs, less class, more values less heap allocated garbage
for a collector to stop the world
D has ton of features that help avoid GC completely, let's focus
on more of that
Atila, didn't you say "allocator good", so where are they?
leadership is also frozen?
Re: SerpentOS departs from Dlang
On Friday, 15 September 2023 at 17:39:41 UTC, M.M. wrote:
In February there were some exciting news on the usage of dlang
within serpent-os linux distribution, quite a large open source
project of Ikey Doherty and the team around him.
Unfortunately, the project decided to leave dlang behind, and
to embrace golang and rust instead... in part due to some
hiccups in dlang and due to contributors pushing for more
mainstream languages:
https://serpentos.com/blog/2023/09/06/oxidised-moss/
Pity that it did not succeed. It would be a great showcase for
the marvelous dlang.
That's unfortunate..
Ikey seems to still want to use D, so the main driving factor is
the contributors, i wonder what are the exact reasons, pseudo
memory safety can't be the only reason
To be honest, I wouldn't blame contributors for looking at more
mainstream languages, who still want to do their switch cases
this way:
```D
switch (it)
{
case MySuperLongEnum.MySuperLongValueA:
result = do_something_a();
break;
case MySuperLongEnum.MySuperLongValueB:
result = do_something_b();
break;
case MySuperLongEnum.MySuperLongValueC:
result = do_something_c();
break;
}
```
When other languages have it cleaner:
```D
result = switch (it)
{
.MySuperLongValueA: do_something_a();
.MySuperLongValueB: do_something_b();
.MySuperLongValueC: do_something_c();
}
```
Improving ergonomics won't necessarily attract people, probably
not, but i'm pretty sure that'll make contributors of existing
projects not request to change language because the ergonomics
are so poor
Even C# understand that and made the appropriate changes across
their language and even improve their compiler to avoid the urge
to switch to Go (NativeAOT), even Java made appropriate language
changes in hope to stay relevant, why only D should be frozen?
Acting like the world depend on D
D has many benefits, but some areas need lot of love, this
reminds me of this dude in an online chat, he said the reason why
he stick to Rust was because of Rust's enum.. not because of
memory safety
Hopefully more wake up calls like this one will resonate with the
D foundation
Re: Warning for anyone who was at DConf.
On Saturday, 2 September 2023 at 20:41:33 UTC, Dukc wrote: Just a while ago I was hit by some sort of a violent ailment. I first noticed it like an hour ago, and I'm shivering as I stand in a well-heated house, despite having had a sauna just a while ago. Temperature already high. I wouldn't rule out having contracted it at DConf, and could well be the Covid. Please watch your health for a few days if you were at DConf or related events. Covid incubation time is days/weeks after contracting the virus So sounds like you had Covid before the event..
Re: LDC 1.34.0
On Sunday, 27 August 2023 at 09:10:14 UTC, drock wrote:
On Saturday, 26 August 2023 at 13:08:14 UTC, kinke wrote:
Glad to announce LDC 1.34.0. Major changes:
* Based on D 2.104.2.
* Support for LLVM 16, incl. v16.0.6 for the prebuilt
packages. Support for v9 and v10 was dropped.
* 64-bit RISC-V: Enable ISA extensions ('rv64gc') by default
when targeting an operating system.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.34.0
Thanks to all contributors & sponsors!
Thanks for the great work.
LDC team procuce the most important compiler with such less
manpower.
Unlike other new player (rust, zig, ponylang), they are focus
on llvm only backend and make great success.
The most dangerous crisis for dlang is keep loss users and
developers, there can be a thousand reasons for that. not
focus at one backend and imrpove it to the best is one reason.
for example Coroutines in LLVM can be add into dlang and work
with C++, there is simple no manpower for it.
These languages are stuck with LLVM and as a result are known for
having very bad build speed
The day D looses DMD will be the day i stop using D, DMD gives me
fast build speed
I don't understand the narrative that is being pushed to get rid
of DMD, this sound like sabotage rather than improvement
LDC is great for portability release/prod builds, for debug/fast
iteration, DMD is unmatched, it's a competitive advantage only
few languages have, having a fast compiler + LLVM based compiler
is a killer combo, nobody should try to shut down DMD, it's
beyond stupid
Fun fact: Zig people are working on getting rid of LLVM and they
are building their own backend, must be telling something, don't
you think?
ARM support for DMD would help making it future proof
Re: Evolving the D Language
On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote: 1. continue to evolve the language I'm super excited about this! - Tagged Union? :D - Pattern Matching? :D () - Built-in Tuple with deconstructing? :D
Re: #27 | in, out, inout type qualifiers | Let's learn Dlang game dev | [video]
On Sunday, 4 June 2023 at 12:53:39 UTC, Ki Rill wrote:  Here is the [link](https://youtu.be/bY7MYykaahk). Thanks for your tutorials, gamedev is an area where D shines!
Re: D Language Foundation April 2023 Monthly Meeting Summary
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
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
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
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
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
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: A New Era for the D Community
On Saturday, 13 May 2023 at 15:58:12 UTC, ryuukk_ wrote: On Friday, 5 May 2023 at 11:26:26 UTC, Ogi wrote: Or it perhaps doesn't need that list and i am wrong in my analysis, wich is probably the case
Re: A New Era for the D Community
On Friday, 5 May 2023 at 11:26:26 UTC, Ogi wrote: On Wednesday, 3 May 2023 at 11:13:34 UTC, Mike Parker wrote: … That’s a lot of words but little actual sense. What makes you think that this IVY™ program is the silver bullet that D desperately needs? And not just yet another load of crap invented by some “consulting” firm as a relatively honest way of taking money from businesses? Because it’s sounds like one. I agree with that, it sounds like consulting propaganda D doesn't need more bureaucracy, it actually doesn't need at all, D needs developers who care about enhancing the language, and people with a vision for the future, so we can write proper stuff - better enums - tagged union - pattern matching - async - nullable - tuple/multiple return (deconstruction) - allocators (don't do them as classes/interface for the love of god) - implement GC as an allocator What will IVY do about that list? other than suck up time and resources Bunch of new languages coming, and the C part of D is still as old as C, untouched, and the Java/C# part of D is now behind Java/C#
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Friday, 12 May 2023 at 03:11:49 UTC, ryuukk_ wrote:
On Thursday, 11 May 2023 at 23:00:03 UTC, epilogue wrote:
On Thursday, 11 May 2023 at 00:56:03 UTC, ryuukk_ wrote:
Don't you find this code easier to read and review?
```D
if (target.os == .Windows)
{
item("windows");
}
else
{
item("posix");
if (target.os == .linux)
item("linux");
else if (target.os == .OSX)
item("osx");
else if (target.os == .FreeBSD)
{
item("freebsd");
item("bsd");
}
else if (target.os == .OpenBSD)
{
item("openbsd");
item("bsd");
}
else if (target.os == .Solaris)
{
item("solaris");
item("bsd");
}
}
arrayEnd();
```
No, I find this harder to review.
`.` is the module scope operator, which is already going to be
difficult for new dlang coders to learn about given that they
would end up searching for the meaning of the `.` character (I
speak from *my* experience learning D).
I haven't reviewed the DIP in full, but a quick search of the
DIP for "module scope operator" does indicate that overloading
the module scope operator was already called out as
undesirable, so I'm not sure why you would use `.` again here
when trying to defend the rejected DIP.
Having read the conversation, but not the DIP, I think the
repetition issue is known, but the examples offered don't
demonstrate (to me, a random nobody reading this thread) a
clear improvement of the language or the code in question.
I will add that this particular case of repetition the DIP
seems to be intended to solve reminds me of brace-expansion in
bash, where `foo.iso{,.sig}` expands to `foo.iso foo.iso.sig`
allowing bashers to avoid repetition in some cases of
repetitive strings, but it should be evident to anyone
subjected to reading someone else's bash script that that
reducing repetition with brace expansion does not
unconditionally improve reviewability of the code in question.
The syntax doesn't matter, i could have used # or :, what ever,
let's focus on the idea first
It's am improvement to me, hence why i advocate for it, i'm not
a compiler developper, i can't think of everything, all i can
think of is it's going to improve the way i write my code
All it took me to appreciate it was to discover it when i was
using a language that happen to support it, as simple as that,
i'm not good at english, not even at programming, but i can
appreciate things makes me write nice code
```D
switch (action.type)
{
case .Attack: do_attack(); break;
case .Jump: do_jump(); break;
}
```
this is simple and readable, if i can't convice you, then there
is nothing i can do
Steve Jobs came up with the iPhone when everyone was saying
"touching your screen with your fingers is a stupid idea", and
look at us now..
All it takes is to try it
that switch could be further improved with pattern matching, but
that's a discussion for a different DIP
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 11 May 2023 at 23:00:03 UTC, epilogue wrote:
On Thursday, 11 May 2023 at 00:56:03 UTC, ryuukk_ wrote:
Don't you find this code easier to read and review?
```D
if (target.os == .Windows)
{
item("windows");
}
else
{
item("posix");
if (target.os == .linux)
item("linux");
else if (target.os == .OSX)
item("osx");
else if (target.os == .FreeBSD)
{
item("freebsd");
item("bsd");
}
else if (target.os == .OpenBSD)
{
item("openbsd");
item("bsd");
}
else if (target.os == .Solaris)
{
item("solaris");
item("bsd");
}
}
arrayEnd();
```
No, I find this harder to review.
`.` is the module scope operator, which is already going to be
difficult for new dlang coders to learn about given that they
would end up searching for the meaning of the `.` character (I
speak from *my* experience learning D).
I haven't reviewed the DIP in full, but a quick search of the
DIP for "module scope operator" does indicate that overloading
the module scope operator was already called out as
undesirable, so I'm not sure why you would use `.` again here
when trying to defend the rejected DIP.
Having read the conversation, but not the DIP, I think the
repetition issue is known, but the examples offered don't
demonstrate (to me, a random nobody reading this thread) a
clear improvement of the language or the code in question.
I will add that this particular case of repetition the DIP
seems to be intended to solve reminds me of brace-expansion in
bash, where `foo.iso{,.sig}` expands to `foo.iso foo.iso.sig`
allowing bashers to avoid repetition in some cases of
repetitive strings, but it should be evident to anyone
subjected to reading someone else's bash script that that
reducing repetition with brace expansion does not
unconditionally improve reviewability of the code in question.
The syntax doesn't matter, i could have used # or :, what ever,
let's focus on the idea first
It's am improvement to me, hence why i advocate for it, i'm not a
compiler developper, i can't think of everything, all i can think
of is it's going to improve the way i write my code
All it took me to appreciate it was to discover it when i was
using a language that happen to support it, as simple as that,
i'm not good at english, not even at programming, but i can
appreciate things makes me write nice code
```D
switch (action.type)
{
case .Attack: do_attack(); break;
case .Jump: do_jump(); break;
}
```
this is simple and readable, if i can't convice you, then there
is nothing i can do
Steve Jobs came up with the iPhone when everyone was saying
"touching your screen with your fingers is a stupid idea", and
look at us now..
All it takes is to try it
Re: DIP1044---"Enum Type Inference"---Formal Assessment
I was reading DMD source code, case of repetition that adds
nothing of value but useless reading strain
https://github.com/dlang/dmd/blob/999d835c1196eb993a99bb7f1c863da265a6b6c0/compiler/src/dmd/json.d#L843-L869
```D
if (target.os == Target.OS.Windows)
{
item("windows");
}
else
{
item("posix");
if (target.os == Target.OS.linux)
item("linux");
else if (target.os == Target.OS.OSX)
item("osx");
else if (target.os == Target.OS.FreeBSD)
{
item("freebsd");
item("bsd");
}
else if (target.os == Target.OS.OpenBSD)
{
item("openbsd");
item("bsd");
}
else if (target.os == Target.OS.Solaris)
{
item("solaris");
item("bsd");
}
}
arrayEnd();
```
what could be done to avoid the repetition?
Reduce the length of the repetition with a short alias?
```D
alias TOS = Target.OS;
if (target.os == TOS.Windows)
{
item("windows");
}
else
{
item("posix");
if (target.os == TOS.linux)
item("linux");
else if (target.os == TOS.OSX)
item("osx");
else if (target.os == TOS.FreeBSD)
{
item("freebsd");
item("bsd");
}
else if (target.os == TOS.OpenBSD)
{
item("openbsd");
item("bsd");
}
else if (target.os == TOS.Solaris)
{
item("solaris");
item("bsd");
}
}
arrayEnd();
```
Well, repetition is still there, now you got a short Type to type
that doesn't mean anything without context, why is it needed? why
do we need that noise? what problem does it solve?
We can use ``with()``? but why do i need a with here? target.os
is self explanatory already, it's supposed to be type safe, it's
a type safe enumeration, i should only care about the values, why
now introduce an extra scope with extra indentation? it'd create
more noise and now visual strain
Don't you find this code easier to read and review?
```D
if (target.os == .Windows)
{
item("windows");
}
else
{
item("posix");
if (target.os == .linux)
item("linux");
else if (target.os == .OSX)
item("osx");
else if (target.os == .FreeBSD)
{
item("freebsd");
item("bsd");
}
else if (target.os == .OpenBSD)
{
item("openbsd");
item("bsd");
}
else if (target.os == .Solaris)
{
item("solaris");
item("bsd");
}
}
arrayEnd();
```
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Monday, 1 May 2023 at 14:03:51 UTC, bachmeier wrote: On Monday, 1 May 2023 at 00:34:03 UTC, ryuukk_ wrote: I don't think it's a misconception. It's more like a complete lack of clarity. the goal is not to use an anonymous enum, the goal is to leverage the robust type system to avoid repeting yourself, wich is bad ``` Value value; value.type = ValueType.STRING; ``` vs ``` Value value; value.type = .STRING; ``` This is another case of the "complete lack of clarity" I wrote about in my earlier comment. With an anonymous enum you could write ``` value.type = STRING; ``` Maybe you have something deeper in mind, but that example does not make a case for changing the language. Rather than shouting, you should put together a better example. I will let this conversation die. I don't think it's going to resolve anything (and I'm not the one that needs convincing anyway). Ok.. so you _refuse_ to understand (as opposed to not understanding, wich in that case you'd only have to listen and learn) You didn't read my previous comment, so let me copy/paste it: the goal is not to use an anonymous enum, the goal is to leverage the robust type system to avoid repeting yourself, wich is bad And to make sure i'm being understood, the goal is not to make code less verbose, quite the opposite, the goal is to encourage verbosity while avoiding useless repetitions, the two are not compatible Are you familiar with this popular quote? "democracy dies in darkness"? It goes the same way with discussing feature suggestions and language impromvents, don't "let this conversation die", convince me, argument, don't just try to silence me, that won't work
Re: DIP1044---"Enum Type Inference"---Formal Assessment
Do you write this? ``` float myfloat = float(1.0); ``` Or this? ``` float myfloat = 1.0; ``` Why would it be different for enums (or any other type) Also i suggest you to try all kind of languages to expand your knowledge and to try out new UX that modern languages provide, there is no reason to refuse to understand other people's opinion only because you thought the existing rule is immutable because you can't give a critical opinion on it
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Thursday, 27 April 2023 at 13:03:17 UTC, bachmeier wrote:
On Thursday, 27 April 2023 at 06:10:57 UTC, Basile B. wrote:
On Thursday, 27 April 2023 at 00:16:10 UTC, Walter Bright
wrote:
This also works:
alias F = MySuperLongNameFlag;
auto flag = F.A | F.B | F.C | F.D;
set_flags(F.A | F.B | F.C | F.D);
It's similar to setting a local variable to some complex
expression, just so you don't have to repeat that expression
multiple times.
It's a misconception of the problem that the DIP tried to
solve. What the DIP tried to solve is that the compiler should
know that you are using an enum member. Actually I even think
this should work without any special syntax, as a "last
resort", let's say. But as you've explained, through Mike's
report, this causes problems for D because the identifier
resolution is tied to a particular implementation, i.e your
fast symtabs.
I don't think it's a misconception. It's more like a complete
lack of clarity. What would be the point of complexifying the
language for the new programmer when you can just use an
anonymous enum? This program runs just fine:
```
import std.stdio;
enum {
A1,
B1,
C1,
D1
}
enum {
_A,
_B,
_C,
_D
}
void main() {
writeln(A1);
writeln(_A);
writeln(A1 == _A);
auto flag = _B;
switch(flag) {
case _A:
writeln("_A");
break;
case _B:
writeln("_B");
break;
case _C:
writeln("_C");
break;
case _D:
writeln("_D");
break;
default:
break;
}
}
```
What's the point in using a named enum if you want an anonymous
enum? The response when this question was asked was not
"because [something where it matters]". It was instead to
ignore the question, give an unrealistic example that was
solved by the response, and insert a bunch of unhelpful
hostility.
what's the point? if you read the discussion that happened for
the DIP you wouldn't ask the question
the goal is not to use an anonymous enum, the goal is to leverage
the robust type system to avoid repeting yourself, wich is bad
```
Value value;
value.type = ValueType.STRING;
```
vs
```
Value value;
value.type = .STRING;
```
Read your code, would you read a book where each sentence would
be a repetition of the previous one?
"Billy went to the town to buy some beer, as he arrived to the
town to buy some beer he met Richard, as he arrived to the town
to buy some beer Richard, that he just met, asked him how his
wife was doing"
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 12:50:32 UTC, bachmeier wrote:
On Wednesday, 26 April 2023 at 11:52:31 UTC, Jacob Shtokolov
wrote:
On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote:
void set_connected()
{
network_connect_state = NetworkConnectState.CONNECTED
}
MySuperLongNameFlag flag = MySuperLongNameFlag.A |
MySuperLongNameFlag.B | MySuperLongNameFlag.C |
MySuperLongNameFlag.D;
set_flags(MySuperLongNameFlag.A | MySuperLongNameFlag.B |
MySuperLongNameFlag.C | MySuperLongNameFlag.D)
Okay, I understand this is sometimes really annoying, but in
this example, why can't you just:
Many other solutions were provided as well, including but not
limited to
- Using shorter names
Why make your code harder to read ?
```
// just use short name, duh
enum CState
{
CON, DC, WT
}
void on_con()
{
st = CState.CON;
}
// no, let me take advantage of the robust type system
enum NetworkConnectionState
{
CONNECTED, DISCONNECTED, WAITING
}
void on_connecte()
{
network_state = .CONNECTED;
}
```
- Using alias
Now you have multiple symbols doing the same thing, that's a
maintenance downgrade, "refactor? ohhh i forgot to refactor the
multiple aliases"
- Using an IDE with autocomplete
Now i need an IDE to code, nice
- Using copy and paste
Now introduce duplicates that are hard to manage during
refactors, wich copy pasta is the right one?
Again, all of this was covered and argumented during the DIP
discussion
The goal is to improve the language, not find excuses or
workarounds, don't defend obfuscation, move forward
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 10:48:21 UTC, Greggor wrote: On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote: I submitted DIP1044, "Enum Type Inference", to Walter and Atila on April 1. I received the final decision from them on April 18. They have decided not to accept this proposal. [...] I’m going to contribute to the peanut gallery, and say I support the rejection of the dip and the reasoning given is solid. I do like the suggestion of `with final switch` and I also like the even shorter `enumswitch` as a new keyword, it would be a nice bit of syntactic sugar. Regardless of this dip being added or not, I'm not going to be dramatic about it, its not the end of the world or of D :^) That's not contribution ``with final switch`` what kind of Java is that? or is it D? i'm getting lost for a moment, not sure!
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 11:52:31 UTC, Jacob Shtokolov
wrote:
On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote:
void set_connected()
{
network_connect_state = NetworkConnectState.CONNECTED
}
MySuperLongNameFlag flag = MySuperLongNameFlag.A |
MySuperLongNameFlag.B | MySuperLongNameFlag.C |
MySuperLongNameFlag.D;
set_flags(MySuperLongNameFlag.A | MySuperLongNameFlag.B |
MySuperLongNameFlag.C | MySuperLongNameFlag.D)
Okay, I understand this is sometimes really annoying, but in
this example, why can't you just:
```d
import std.stdio;
enum MySuperLongNameFlag : int
{
A = 0b0001,
B = 0b0010,
C = 0b0100,
D = 0b1000,
}
void set_flags(MySuperLongNameFlag f) {}
void main()
{
with (MySuperLongNameFlag)
{
auto flag = A | B | C | D;
set_flags(A | B | C | D);
writefln("%04b", flag);
}
}
```
No, what about this:
```d
import std.stdio;
enum MySuperLongNameFlag : int
{
A = 0b0001,
B = 0b0010,
C = 0b0100,
D = 0b1000,
}
void set_flags(MySuperLongNameFlag f) {}
void main()
{
MySuperLongNameFlag flag = A | B | C | D;
set_flags(A | B | C | D);
writefln("%04b", flag);
}
```
No bloat, no extra indentation, no auto, you know what you are
using
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Wednesday, 26 April 2023 at 01:39:14 UTC, Walter Bright wrote: On 4/25/2023 1:15 PM, ryuukk_ wrote: Or perhaps, listen to this person: https://github.com/dlang/dmd/pull/14650 That only does a subset of the proposal. The inference only works in specific cases. Things like function overloading are not addressed. Where were you when we discussed about it? https://forum.dlang.org/post/clkvzkxobrcqcelzw...@forum.dlang.org Nowhere to be seen For projects to move forward, discussion must happen Hiding in the back with a knife mean you waste everyone's time People who spending time thinking about the feature, writing the DIP, discussing about it, implementing the PR, arguing with people, doing the effort to argument etc etc Anyways, this is your project, you choose how it goes, it goes both ways tho, i choose what i use
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 20:59:23 UTC, max haughton wrote: On Tuesday, 25 April 2023 at 20:15:39 UTC, ryuukk_ wrote: On Tuesday, 25 April 2023 at 18:38:14 UTC, max haughton wrote: [...] Why you guys focus on "switch" Because that's the example given by Mike... Who doesn't love writing other than Walter Bright: [...] Who are you saying said it's too hard to implement? Also consider that *any* change breaks all the tooling. It's in the 2nd paragraph Oh, now you care about the tooling? I was the only one who raised awareness about the new features landing but tooling was ignored all while i was getting ignored (importC // dub) (bitfields // dcd), how funny Same for the debugging issue, i got ignored Same for the TLS issue, i got ignored I has the wrong expectations it seems, you also seems to have the wrong expectation on your users ImportC will save everything, i now understand
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 18:38:14 UTC, max haughton wrote:
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:
Firstly I think this is the correct decision, certainly for
now, probably forever.
Regarding enums in switch statements, Walter suggested we
could shorten the `with final switch` syntax such that the
`with` is implicitly applied to the type of the switch
variable:
```D
auto myEnum = MyEnum.a;
with final switch (myEnum) { }
```
Alternatively, we could make the `with` implicit for case
statements, but that would break existing code.
What we have at the moment with `with` is, I think perfectly
fine.
The `switch(...) with(...)` pattern is used rather a lot in the
SDC codebase
for example and I think it's very readable.
On the topic of `with` I do think, and have even implemented
;), with expressions do need to happen eventually. The with
statement is a little heavy handed for places where these kinds
of shorthands are needed locally.
Why you guys focus on "switch"
Who doesn't love writing other than Walter Bright:
```
void set_connected()
{
network_connect_state = NetworkConnectState.CONNECTED
}
MySuperLongNameFlag flag = MySuperLongNameFlag.A |
MySuperLongNameFlag.B | MySuperLongNameFlag.C |
MySuperLongNameFlag.D;
set_flags(MySuperLongNameFlag.A | MySuperLongNameFlag.B |
MySuperLongNameFlag.C | MySuperLongNameFlag.D)
```
Too hard to implement? oh really? then i suggest trying other
languages and reading their source code, so you can learn new
techniques and improve your project
Or perhaps, listen to this person:
https://github.com/dlang/dmd/pull/14650
He seem talented, he did what you find "too hard" to implement
Being stuck is a good thing if you work, if you don't work, and
you are stuck, then perhaps is time to reflect on the time spent
working on being stuck?
I still can't debug my program btw
https://forum.dlang.org/thread/mhqywnoqhoirtruyk...@forum.dlang.org
So i now understand better, things aren't "hard to implement",
things are frozen in time, and no will to improve anything, the
motto is go template yourself! (sumtype)
Re: DIP1044---"Enum Type Inference"---Formal Assessment
On Tuesday, 25 April 2023 at 04:54:43 UTC, Mike Parker wrote:
I submitted DIP1044, "Enum Type Inference", to Walter and Atila
on April 1. I received the final decision from them on April
18. They have decided not to accept this proposal.
https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1044.md
The said the proposal was well done and an interesting read,
but found it to be too complex for insufficient benefit. They
provided the following list of concerns that led them to their
decision:
* Given that D already has `with`, `alias`, and `auto`, it does
not seem worthwhile to add a special case for enums.
* Semantic analysis in D is strictly bottom-up. This proposal
would add top-up type inference on top of that. This presents
problems in handling function and template overloads, as well
as variadic parameter lists.
* The proposal only allows ETI in some contexts. This is
potentially confusing for the programmer, particularly in the
presence of mixin templates (which draw symbols from the
instantiation context) and function overloads.
* Symbol tables can get very large. Lookups are done via hash
table for max speed, but this will not work for ETI. There may
be a very large number of "enums in scope", and each one will
have to be searched to resolve a member.
* ETI is similar to ADL (Argument Dependent Lookup) in C++.
Walter implemented ADL in the Digital Mars C++ compiler and is
strongly against allowing anything like it in D. He finds it
slow and complex, and few people really know how it's going to
work.
Regarding enums in switch statements, Walter suggested we could
shorten the `with final switch` syntax such that the `with` is
implicitly applied to the type of the switch variable:
```D
auto myEnum = MyEnum.a;
with final switch (myEnum) { }
```
Alternatively, we could make the `with` implicit for case
statements, but that would break existing code.
Welp, time for me to find a new language then, that's
unfortunate..
Re: newer version of Vibe.d tutorial
On Friday, 21 April 2023 at 15:26:15 UTC, Rey Valeza wrote: Hi, I just completed the newer version of the tutorial on Vibe.d. It is viewable here: https://reyvaleza.gitbook.io/vibe.d-tutorial and the PDF version is downloadable here: https://github.com/reyvaleza/vibed/blob/main/BuildTimekeepWithVibe.pdf Thanks! Hi, thanks for your effort again! One suggestion: Screenshot:  This look very bad, please use proper markdown syntax ``` ```D // your code ``` ```
Re: newer version of Vibe.d tutorial
Another suggestion: https://i.imgur.com/x7nkKXl.png This is unreadable, please put that on a code block too to make it easier on the eyes
Re: LDC 1.32.1
On Monday, 17 April 2023 at 15:26:16 UTC, kinke wrote: A new patch version was just released: * The prebuilt Linux packages are now generated on a Ubuntu 20.04 box, so the min required glibc version has been raised from 2.26 to 2.31. * Fix empty `ldc.gccbuiltins_*` modules with LLVM 15+. * Fix v1.31 regression wrt. potentially wrong constant pointer offsets. * Windows: Fix v1.32.0 regression wrt. leaking `Throwable.info` backtraces. * Fix C assert calls for newlib targets. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.32.1 Thanks to all contributors & sponsors! Thanks for the release! If someone could look into this that would be nice: https://github.com/ldc-developers/ldc/issues/2425 I want to get rid of the ugly hacks i have to incorporate in all my projects
Re: Release D 2.103.0
On Monday, 3 April 2023 at 16:41:25 UTC, Iain Buclaw wrote: Glad to announce D 2.103.0, ♥ to the 43 contributors. This release comes with 9 major changes, including: - In the compiler, `-preview=dip25` is now enabled by default. - In the standard library, std.uni Grapheme functions have been updated to conform to Unicode 15 - In dub, the `--color` argument now accepts the values `auto`, `never`, and `always`. http://dlang.org/download.html http://dlang.org/changelog/2.103.0.html -Iain on behalf of the Dlang Core Team Thanks for the ImportC fixes, very welcome
Re: Objective-C D metal binding
On Friday, 10 March 2023 at 21:14:38 UTC, Hipreme wrote: On Friday, 10 March 2023 at 21:10:50 UTC, ryuukk_ wrote: Congrats! But metal obj-c? do you mean DMD support only? so no Apple Silicon (intel only)? I don't think Intel stuff on mac ecosystem will be a thing for too long, PPC era already vanished from history There is the official C++ headers that you can use to make things easier https://developer.apple.com/metal/cpp/ As said in the post above, I do intend to get `extern(Objective-C)` into LDC even if I have to do it myself. Which is also why I'm looking if someone could help Martin get this on LDC. Binding to the main API is better than the secondary one, and this is an advantage that D has over other languages. This is not only about Silicon, it is also about getting iOS. iOS market share is as big as Android and any game developer would be interested in entering in this market. That's exactly what i'm saying, Intel is dead on that platform, it's only just ARM, therefore this metal-cpp comes handy
Re: Objective-C D metal binding
On Friday, 10 March 2023 at 20:53:23 UTC, Hipreme wrote: Hello guys. I have been working for some time into binding Metal to D. This has been quite an interesting journey and today I've reached a point where it is usable. It is far from complete, but I included a lot of comments from Apple's documentation, and also have tested and got an entire Metal hello world working in D. The API I worked on is really nice, I manually put the opIndex, opIndexAssign, wrapped Objective C Runtime Arrays to a strongly typed array in D. The main point into this binding is getting Metal to run on Hipreme Engine, so, I don't plan into supporting what I don't use. That said, I still welcome any contribution to make this a standard way to program using Apple's Metal. I'll put an example folder the moment I get a dub fix for macOS.  https://code.dlang.org/packages/d-metal-binding Congrats! But metal obj-c? do you mean DMD support only? so no Apple Silicon (intel only)? I don't think Intel stuff on mac ecosystem will be a thing for too long, PPC era already vanished from history There is the official C++ headers that you can use to make things easier https://developer.apple.com/metal/cpp/
Re: Beta 2.103.0
On Thursday, 2 March 2023 at 14:40:04 UTC, Iain Buclaw wrote:
Glad to announce the first beta for the 2.103.0 release, ♥ to
the 43 contributors.
This release comes with 9 major changes, including:
- In the compiler, `-preview=dip25` is now enabled by default.
- In the standard library, std.uni Grapheme functions have been
updated to conform to Unicode 15
- In dub, the `--color` argument now accepts the values `auto`,
`never`, and `always`.
http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.103.0.html
As usual please report any bugs at https://issues.dlang.org
-Iain
on behalf of the Dlang Core Team
```D
@safe ref int wrongIdentity(ref int x) {
return x; // ERROR! Cannot return a ref, please use "return
ref"
}
@safe ref int identity(return ref int x) {
return x; // fine
}
```
a keyword to return a value
``return 5;``
and a keyword to tell that a reference is returnable
``return ref int x``
that's dumb, why?
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 14:24:38 UTC, Adam D Ruppe wrote: On Monday, 27 February 2023 at 12:08:58 UTC, newbie wrote: with `betterC` you can target into new platform without much work, and easy to deal with dynamic library, generate much fast and smaller binary. you can do this without betterC too. often easier. And it could be even easier with a little bit of work that benefits everybody. The custom runtime route is a mistake to expect from users, why should i manage all of this, it should just work, well you are forced because of X, Y, Z are not yet ported! so you cherry pick on a code basis, rather than on a feature basis You'll also have to keep track of the compiler developments in case runtime hooks get changed, also if you are not careful about your implementation you have silent bugs (i had one with switch errors that was hard to track down, i had to copy/paste code from your repo) With C/C++ and even Rust/Zig/Go(tinygo), you don't have that kind of problems The bare is set by other languages already, -betterC is helping staying on buisness for that kind of purpose
Re: D Language Foundation January 2023 Quarterly Meeting Summary
I use -betterC because i can focus on the language and build upon
it, i don't have to deal with the slowness of phobos and more
importantly, i don't have to wait for phobos or druntime to be
ported to WASM in order to be able to target to WASM, i target
WASM today
It also makes me confident that none of my game code will
accidentally call the GC, as i banned the use of the GC for this
particular project (game)
I can focus on what i love about C with the greatness of D (the
language)
My project fully recompile (clean build, game+engine) in just
1.2s, thanks Walter!
The only complain i have about betterC, and D in general are the
error messages, sometimes just having new lines with proper
spacing makes errors easier to read, i made a comment in one
PR(related to improving betterC error message) that it was
helpful and very much welcome, so looks like things are going to
improve
Walter decided to put the Sum Types proposal aside for now
That's super sad to hear.. i was eagerly hoping tagged union
would come sooner rather than later.. it's one feature that
enables writing useful with less noise
I want to replace that kind of ugly code that i have, notice how
easy it is to have bugs if you are not careful what field you
use, not safe!: (no, template is not the solution)
```D
enum EventType: ubyte
{
QUIT,
GFX_RESIZE,
INPUT_KEY_DOWN,
INPUT_KEY_UP,
INPUT_KEY_TYPED,
INPUT_TOUCH_DOWN,
INPUT_TOUCH_UP,
INPUT_TOUCH_DRAGGED,
INPUT_MOUSE_MOVED,
INPUT_SCROLLED,
}
struct Event
{
long time;
bool consumed;
EventType type;
union
{
// GFX
Resize resize;
// INPUT
KeyDown key_down;
KeyUp key_up;
KeyTyped key_typed;
TouchDown touch_down;
TouchUp touch_up;
TouchDragged touch_dragged;
TouchMoved touch_moved;
Scrolled scrolled;
}
}
(..)
// update key state
foreach(Event* e; engine.queue)
{
if (e.consumed) continue;
switch (e.type) with (EventType)
{
case INPUT_KEY_DOWN:
switch(e.key_down.key)
{
(..)
}
break;
case INPUT_KEY_UP:
switch(e.key_up.key)
{
(..)
}
break;
case INPUT_TOUCH_DOWN:
if (e.touch_down.button == 1)
(..)
break;
case INPUT_TOUCH_UP:
if (e.touch_up.button == 1)
(..)
break;
default:break;
}
}
```
I think expecting users to ask for new features shouldn't be seen
as something bad
It's great to have people discuss language improvement, it gives
the ability to talk about and remind people about existing
features, and potentially their issues
And what a better opportunity than to remind ones who think bugs
in weird and cryptic corner cases, is what turn off people
What turn me off from D is that kind of issues:
https://github.com/dlang/dub/issues/2600
When you start to import things from the std and it makes your
compile time go from 5seconds (already an eternity) to 10
seconds, and people think "it's not a problem"
tagged union would help reduce the code complexity, template
usage and bugs by a significant amount of time, as well as
improving error messages
https://forum.dlang.org/thread/zsxipgibubqgnwwwx...@forum.dlang.org
Re: Centroid tracking using DCV
That's pretty cool, thanks for sharing!
Re: Hipreme Engine is fully ported to WebAssembly
On Saturday, 4 February 2023 at 12:47:30 UTC, Guillaume Piolat wrote: On Friday, 3 February 2023 at 13:41:35 UTC, Hipreme wrote:  This custom runtime is a most welcome development. I agree, but this is also unfortunate, one shouldn't have to do that to target WASM, the druntime needs to be shrinked asap
Re: Hipreme Engine is fully ported to WebAssembly
Congrats! This shows D capabilities, system language that is able to scale from as little as micro controllers to full blown cross platform games including the Web with WASM! That's why it's always important to keep runtime as simple as possible, and the std as minimal as possible, lets you target new platforms with ease! I also ported my engine to WASM, i'll have something interesting to show in the coming months, stay tuned! D playing nice with WASM, that's a strength not many languages have! Let's do more with it!
Re: Release D 2.102.0
On Thursday, 2 February 2023 at 12:30:50 UTC, Iain Buclaw wrote: Glad to announce D 2.102.0, ♥ to the 40 contributors. This release comes with support for multiple message arguments in `static assert()`, stack allocated `scope` array literals, a new preview switch to add support for `@system` variables, and many more. Downloads and full changelog are available from the dlang site. http://dlang.org/download.html http://dlang.org/changelog/2.102.0.html -Iain on behalf of the Dlang Core Team Dub changes Binary output will now be in a central cache A welcome change, thanks! Bugzilla 21301: Wrong values being passed in long parameter list Finally fixed, thanks!!
Re: second edition of Build Web Apps in Vibe.d by learning from a learner
On Monday, 23 January 2023 at 01:48:11 UTC, Rey Valeza wrote: Hi, I just uploaded a second edition of the tutorial I uploaded on Github last year. Here is the link: https://github.com/reyvaleza/vibed/blob/main/Build%20Web%20Apps%20in%20Vibed%20second%20edition.pdf Thanks! PDF is not a good choice for that kind of tutorial, there is no navigation, so once has to scroll to get to the vided stuff No proper support for code blocks, it's messy with cli output being truncated into multiple page That's messy Here an example of a proper format: https://astaxie.gitbooks.io/build-web-application-with-golang/content/en/07.4.html It's open source: https://github.com/astaxie/build-web-application-with-golang/
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote: Robert spoke up then to suggest deprecating @property and releasing a tool that removes it from a code base. Then we should apply that tool to create pull requests for all dub packages using @property, and then in a future release, we kill it. Anyone affected by the removal can then run the tool on their own code. He added that we should do this with any feature we decide to remove. This is the modern way of software development: you don't just break someone's code, you break their code and give them a tool to fix it. I agree with that 100%, perhaps the feature should be built in into DUB, it can already detect the compilers and its version, so it can do all the heavy lifting already Compile times keep getting slower. Why doesn't an LSP implementation come with DMD? Why don't we have a compiler daemon? Why aren't his build times sub one second? All my projects fully recompile in around 1s, i am sad when i see libraries that tank the compile speed to multiple seconds.. I ended up writing my own runtime and my own std, this is why i advocate for language enhancements rather than putting more template soup into the std And i agree even more on the language server, Jan did an amazing work with serve-d, but it highlights 2 problems: - slow to compile, wich makes contributing a pain - DCD is basically too basic, doesn't even support most D features including templates SumType is really awesome, and we should really do something with it. I agree, SumType is a great piece of library, it should be promoted as a language feature The first involved dub's settings file, settings.json. As he put it, have you ever seen a program that asked you to write its settings using JSON? There had been some favorable responses to the idea of moving to YAML from some core contributors a few years back. It just needed someone to do it. He asked if we were okay with the move. Átila said we probably shouldn't keep JSON, but wondered if YAML was the best choice. What about TOML? This sparked a minor bikeshedding discussion, but there was no major opposition to Mathias's plan. (He has since opened a draft PR. Sönke Ludwig wants to see a broader discussion of this before finalizing it, so I expect Mathias will ask for community feedback at some point.) I agree, json is not a good file format, it doesn't even support comments and is annoying to parse A simple ini file would be 10x better already, no need complicated parsers like YAML or TML Robert thinks Rust has won that game. We're the second person to the moon. Put @safe on top, disallow taking addresses of the stack, don't allow returning ref, and don't allow pointer arithmetic. That's as safe as we need to be. D's niche is on top of Rust and under TypeScript. That's where we need to be. That may not be the most popular opinion in the group, but he was alone in his room and no one could hurt him. He thinks C++ has been sinking, but it's probably going to keep sinking until he's dead and will never sink completely, but Rust will take that over. Rust is also taking over some of the web world because it compiles easily to web assembly. I DISAGREE fully, Rust has not won "that game", there is a similar negative sentiment about rust, "too complicated", "too hard", "bad syntax", "slow to compile", etc The future will be many languages, each being best at certain domains, we seen it with the rise of Go, doing what it do best with the cli/web/server/containers and nothing else WASM? C/C++ won the game, Abobe is the perfect example, it's not simple hello world Rust people are doing, it's full commercial projects https://web.dev/ps-on-the-web/ Same with games
Re: D Contributor Tutorials Part 1 - Building the Compiler From Source
On Sunday, 8 January 2023 at 11:27:14 UTC, Mike Parker wrote: Have you ever considered hacking on the D compiler but were intimidated by the build process? Dennis Korpel has been working on a series of video tutorials aimed at helping potential contributors establish a foundation from which to start contributing code. In this first tutorial of the series, he gives an overview of what happens when compiling a D source file, then shows how to set up an environment from which to build dmd and the standard library/runtime binary. The next video will use this setup to start making changes to dmd. https://youtu.be/iLN4rQkk4Fs The plan is to publish a new tutorial in the series every two weeks, so you can look for the next tutorial on January 22. Thanks to Dennis for offering to put these videos together. Even a short video like this one takes a significant time investment to go from concept to publication. I'm certain there are people out there who will find them beneficial. Last time i tried to build DMD to finish a PR i had was a miserable expenrience that i decided to give up https://github.com/dlang/dmd/pull/14418 The Wiki is outdated and mentions tools that do not exist https://wiki.dlang.org/Building_under_Windows I updated it with the little information i had but that still wasn't enough to be able to build the whole thing I even asked on the forum for some help, wich was met with silence https://forum.dlang.org/thread/aapqglgpugyuimhof...@forum.dlang.org?page=1 While this video definitely help, but i'm not going to rewind to find information on a 7minutes video, it should be a simple document, with a set of simple scripts and they should put accessible under the DMD repo It shouldn't be that convoluted
Re: D Language Foundation October 2022 Quarterly Meeting Summary
On Wednesday, 2 November 2022 at 04:42:06 UTC, Mike Parker wrote: Following that, he had begun adding colors in the stack trace because he thought they were unreadable, and adding colors was not that much work. He had a proof-of-concept but still had a few things to work out. That's a little detail, but it makes a big impact, thanks!
Re: ctod: a tool that translates C code to D
WOW that's pretty cool!! It was always time consuming having to manually port C code, your tool will be very helpful! Thanks a lot for sharing!
Re: D + Qt + QtDesigner
On Tuesday, 27 September 2022 at 21:07:25 UTC, Willian wrote: https://forum.dlang.org/post/misbkuqdifjdhhsox...@forum.dlang.org On Sunday, 21 November 2021 at 15:08:18 UTC, MGW wrote: I am still developing my QtE5 library. Unfortunately, I don't have enough free time to make it into a complete dub package. Link to short video: http://www.youtube.com/watch?v=TFN5P4eoS_o Dear friends, I would like to know if it is possible to gather the D community to work together on D + Qt + QtDesigner. I believe that the maturation of this library is the gateway for many programmers in the D language. Announce is not the right place to ask questions, either #learn or #general Posts in the #announce category are automatically shared on twitter, so we should avoid sending out noise/spam
Re: DIP 1043---Shortened Method Syntax---Accepted
On Thursday, 22 September 2022 at 01:28:11 UTC, Doigt wrote: On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker wrote: For example: T front() => from; becomes: T front => from; As DIP author, Max decided against this. He said it's not a bad idea, but it's then "inconsistent with other the other syntaxes". If there is a demand for this, it would be easy to add later, but he felt it's better to keep things simple for now by going with the current implementation as is. It's one of those things that aren't necessary, but bring some small "quality of life" kind of change to the code we write. At least in my opinion, I quite like it, the same way I like how I can call a parameter-less function without parentheses. It actually makes code very hard to read Is it a field? is it a function, does it have arguments, or maybe it is just a static function, maybe it is a property, oh shoot i have to waste time trying to figure out what it is It is same story with imprts, so now i exclusivly use named import ``import xxx = my.package.here`` ``xx.my_global_function();`` This way when i read code, i know exactly what is doing what and from what module This shortened method syntax is the same, it is a method, not a field, therefore it should require ``()``, i personally never omit it from the way i write function in my code, calling a function this way: ``this_is_a_function`` is imo very dangerous, i wish it was gone from the language
Re: D Language Foundation August 2022 Monthly Meeting Summary
On Monday, 5 September 2022 at 11:39:44 UTC, Mike Parker wrote: I mentioned to Max that I had spoken to Eyal Lotem of Weka about the move constructor DIP (DIP 1040, "Copying, Moving, and Forwarding", You linked the wrong DIP, your link point to DIP1043
Re: D Language Foundation August 2022 Monthly Meeting Summary
On Monday, 5 September 2022 at 11:39:44 UTC, Mike Parker wrote: EV code-signing certs are expensive, and also have a 2FA dependency on a hardware token D is an established open source project known by everyone in the planet I'm pretty sure contacting one company to get sponsor for 1 would work, have you tried that? No need to pay the expensive price, money should be spent on human resources for the language, not on that kind of stuff, if possible of course
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: gamut v0.0.7 ask for what you want
That's a very cool library, i might ditch stb_image for yours, thanks for sharing! I went ahead and added it to the list of libraries that supports QOI file format here: https://github.com/phoboslab/qoi/pull/235 One suggestion, have a little struct with function pointers for malloc/free/realloc, so that we can plug our own allocator
Re: The D Programming Language Vision Document
On Wednesday, 6 July 2022 at 14:30:07 UTC, Paulo Pinto wrote: On Tuesday, 5 July 2022 at 12:34:57 UTC, ryuukk_ wrote: On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote: On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: You can find the final draft of the high-level goals for the D programming language at the following link: https://github.com/dlang/vision-document Under 'Memory safety': Allow the continued use of garbage collection as the default memory management strategy without impact. The GC is one of D's strengths, and we should not "throw the baby out with the bath water". Under 'Phobos and DRuntime': @nogc as much as possible. Aren't these the polar opposites of each other? The GC is one of D's strengths, yet we should avoid it as much as possible in the standard library. Then it's not part of D's strengths. GC is one of D's strength because it is optional, not making core APIs bing-your-own-memory-allocation-strategy through nogc or allocators, is making it no longer optional, which is no longer a strength imo You don't want GC when you do microcontroller development, so as a result core APIs (most of them) becomes useless, moving forward that should make the story better for everyone Which becomes a strength again Feel free to consider it a strength, when in reality it is a flaw against established market players. https://www.microej.com/ https://www.wildernesslabs.co/ https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ https://www.astrobe.com/ People also use nodejs and npm, what is your point? If you invest in the future you must take the pragmatic approach and give options Those are not Oracle's products, companies took the JVM for what it is as a foundation and built their products They haven't picked the default Oracle JDK and the default concurrent GC D should enable similar stories with what it has and can provide, read on the challenges TinyGO faced, if D provides the tools for companies to experiment with it, with a proper set of efficient and minimal Core APIs, that alone makes it a proper and more efficient alternative solution
Re: The D Programming Language Vision Document
On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote: On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: You can find the final draft of the high-level goals for the D programming language at the following link: https://github.com/dlang/vision-document Under 'Memory safety': Allow the continued use of garbage collection as the default memory management strategy without impact. The GC is one of D's strengths, and we should not "throw the baby out with the bath water". Under 'Phobos and DRuntime': @nogc as much as possible. Aren't these the polar opposites of each other? The GC is one of D's strengths, yet we should avoid it as much as possible in the standard library. Then it's not part of D's strengths. GC is one of D's strength because it is optional, not making core APIs bing-your-own-memory-allocation-strategy through nogc or allocators, is making it no longer optional, which is no longer a strength imo You don't want GC when you do microcontroller development, so as a result core APIs (most of them) becomes useless, moving forward that should make the story better for everyone Which becomes a strength again!
Re: The D Programming Language Vision Document
Pattern matching
Hopefully that includes proper built in Tagged Union, non OOP
people need that otherwise we are stuck in C's era of programming
We can, and we should do better (import std.sumtype is
embarrassing when other languages have it built in without
template soup, i still refuse to touch it)
Tuples
Awesome! hopefully they become built in and more integrated
Async/await
This one will be tricky, done well means it scale from 0 to
hearo, meaning i should be able to use it without the need of a GC
Hopefully it's not one of these import `std.concurency: async,
await, frame;`
Stronger traits
That's awesome to hear, metaprogramming is one of D's strength
On the tooling part:
A language server is long overdue..
https://pkg.go.dev/golang.org/x/tools/gopls
https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html
https://rust-analyzer.github.io/
The one we have right now (serve-d) is nice, but uses the same
backend as every other projects (DCD), and this project haven't
evolved in years, the moment you step into template territory, it
falls short ``T get(T)() { return T.init } auto myInt =
get!int;`` it'll not know what myInt is.. wich is a shame when
that feature is D's signature
A better debugging story is also essential, without having to use
external (incomplete) files like:
https://github.com/Pure-D/dlang-debug
msvc, clang, gcc: they should know what D types are, and they
should be able to step properly into D syntax without the need of
the user to do weird things
Zig is a young language and yet has a better debugging story
Onto the phobos/druntime:
That's nice to hear that the goal is to reduce inter module
dependencies
Core APIs should be made independent and VERY simple, this allows
them to be easily ported to other platforms, easier to extend
I am sad that no word on the Allocator API, moving forward i
personally think APIs that use memory should be required to ask
for an Allocator and do their allocation using it, and only it
A default GCAllocator could be used if none provided, this allows
users of all kind to enjoy the APIs without having to complain
about the GC or their inability to integrate the APIs in their
game engine for example
--
Overall this document is super encouraging, thanks for making it,
D finally have a long term roadmap!
Hopefully this allows everyone to align and coordinate their
efforts
I wish i could help, i tried, but language programming is
definitely not my cup of tea, hopefully you guys are not sick of
my suggestions
A language is about allowing user to express their intent, making
it easier for them to achieve that goal is a priority, compiler
internal difficulties should not prevent language improvements,
compiler internals doesn't exist from the user point of view
Re: A New Game Written in D
I know GCs are a big source of contention, particularly so among game developers, but I have to say I've never really experienced one of the (theoretical) scenarios where a GC ruins a game's performance or something like that, at least not with the D GC. It seems to just be a matter of not doing crazy things (like running heap-based operations every frame) and pre-allocating everything that you can with pools or something similar. The concept of GC is fine, it exist in both Unreal and Unity The only difference is their implementation Both Unreal/Unity doesn't have "much" problems because they use some sort of incremental GC, usually multithreaded The problem of D is it's the worst implementation for games, it scans your entire heap, while doing so pauses all the threads The bigger your heap is (wich games usually have), the longer the pause will be It's not a problem for "some" games, but as 144hz monitors are becoming mainstream, the need of games running at 120/144fps is becoming crucial For 120fps, your frame budget is only 8ms, no time for any GC pause Even thought GC's story is better on Unreal/Unity, they still struggle, constantly, wich GC issues, a simple google request is enough to validate the point) I used to not care about the GC, until it started to get in my way, since then, malloc/free/allocators, and nothing else Designing an engine this way gives you much more control, GC for scripting only in isolated thread! That's why it is dangerous to tell people to not mind the GC and "just program", no, you have to be meticulous about your allocation strategy to properly make use of the benefits that a GC will give you! GC is an ice thing, when used properly, depending on its implementation!
Re: Archttp - Fast and easy to use web framework.
On Saturday, 14 May 2022 at 14:58:52 UTC, zoujiaqing wrote:
Hi, everybody.
The epidemic in China is serious. I am in home quarantine in
Shanghai.
I used to write a lot of frameworks. But they are huge and
difficult to use.
I've always wanted to design a lightweight Web framework that
is easy to use and has good performance. These days I finally
write a version. This version currently runs well on Linux and
macOS. We haven't had time to test it on Windows yet.
## Sample code:
```D
import archttp;
void main()
{
auto app = new Archttp;
app.Bind(8080);
app.Get("/", (context) {
auto response = context.response();
response.body("Hello Archttp");
});
app.Get("/json", (context) {
import std.json;
auto response = context.response();
auto j = JSONValue( ["message" : "Hello, World!"] );
response.json(j);
});
app.Get("/user/{id:\\d+}", (context) {
auto request = context.request();
auto response = context.response();
response.body("User id: " ~ request.parameters["id"]);
});
app.Get("/blog/{name}", (context) {
auto request = context.request();
auto response = context.response();
response.body("Username: " ~
request.parameters["name"]);
});
app.Post("/upload", (context) {
auto response = context.response();
response.body("Using post method!");
});
app.Run();
}
```
The project relies on 'nbuff' and 'httparsed', which provide
very powerful support for 'Archttp'.
** Thanks to 'ikod' and 'Tchaloupka'.**
Be aware that there will be many changes and tweaks to the API
in the future. It's not a stable version yet.
The current project supports HTTP 1.1 request processing. And a
good built-in routing module.
## Examples of running projects:
```bash
git clone https://github.com/kerisy/archttp.git
cd archttp/examples/httpserver/
dub run
```
## Project source code:
https://github.com/kerisy/archttp
I'll check the source code, but so far it looks very nice! good
job! very simple and easy to use API!
Thanks for sharing!
Re: Bubel ECS - Entity-Component-System architecture implementation
That's impressive, and shows the D capabilities, the future is WASM!!! glad to see D ready for it! I'm working on a similar project, thanks for sharing, it'll be very helpful for me!
Re: Windows Bindings v1.1
On Saturday, 20 February 2021 at 14:03:18 UTC, Rumbu wrote: - updated to Windows SDK 10.19041.5 - wchar* constants with GUID patterns translated as GUID structures - improved documentation - strongly typed handles - auto disposed handles - new attributes (currently ignored): RetVal, NullNullTerminated, NotNullTerminated - published as dub package https://github.com/rumbu13/windows-d Thanks for the dub package! easier to use, at least for me :D
Re: LDC 1.25.0-beta1
On Saturday, 9 January 2021 at 11:48:46 UTC, kinke wrote: Glad to announce the first beta for LDC 1.25 - some highlights: - Based on D 2.095.0+. - LLVM for prebuilt packages bumped to v11.0.1. - Profile/trace LDC invocations via --ftime-trace. - New Windows installer. - New experimental template emission scheme for -linkonce-templates. This option can significantly accelerate compilation times for optimized builds (e.g., 56% faster on my box when compiling the optimized Phobos unittests). Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.25.0-beta1 Please help test, and thanks to all contributors & sponsors! thanks to the LDC team, amazing work and amazing compiler!
