Given last month's successful conversion of a sand pile to an atomic pile, this
#dlang meeting will be about resurrecting the lost technology of the Atomic
Earth Blaster.
Thu May 30 7pm at the Red Robin
2390 148th Ave NE, Redmond, WA 98052
On 5/10/2024 6:22 PM, kinke wrote:
Glad to announce LDC 1.38.0. Major changes:
- Based on D 2.108.1.
- Support for LLVM 18; the prebuilt packages use v18.1.5.
- Android: Switch to native ELF TLS, supported since API level 29 (Android v10),
dropping our former custom TLS emulation (requiring a
https://x.com/WalterBright/status/1781022970984775915
On 4/7/2024 6:38 PM, Mike Shah wrote:
I'll be talking more about D (and modern C++) at the ACCU 2024 conference in
Bristol (Abstract below -- talk is on April 19, 2024).
Let me know if you'll be joining (in-person or online)! The recording of the
talk will otherwise be posted after the talk,
Wow! This is really good work. It's much appreciated!
On 2/23/2024 4:54 PM, Walter Bright wrote:
Tonight's agenda: select the Ring Bearer. Those who don't show up run the risk
of being chosen.
We had our largest ever group, 8 people!
Tonight's agenda: select the Ring Bearer. Those who don't show up run the risk
of being chosen.
Now on front page of HackerNews!
https://news.ycombinator.com/news
Martin is indeed a treasure!
be there or be square!
On 1/23/2024 8:01 AM, Steven Schveighoffer wrote:
zero proposals that infer type from how they are used
have been accepted by Walter, this one probably will be no different.
Types are inferred in D from the bottom up. Mixing in special cases of it being
top down leads to confusion over how
On 1/21/2024 3:51 AM, zjh wrote:
When you need `friend`, You can put them all in one module.
Sometimes, when `multiple classes` are closely related and independent, `class
level privacy` becomes very important. No one wants , someone from outside may
secretly steal money from your home.
D
On 1/21/2024 3:46 AM, Dom DiSc wrote:
`class-private` is superfluous cruft. You can very easy live without it.
And it has only no side effects, if it is implemented without `friend`s. But
without this misfeature it is incomplete.
Therefor it was decided not to implement it.
It would be ok for
This is going to be a great initiative. Thanks, Mike!
On 1/14/2024 3:16 PM, Mike Shah wrote:
My talk on how I'm using the D programming language and why I think it is an
excellent language choice for open source projects will be featured at FOSDEM
2024 at the start of February 2024 in Brussels, Belgium.
Ehhxcellent!
On 1/5/2024 2:53 AM, Martin Tschierschke wrote:
And BIG THANK YOU, to the whole community!
Our pleasure!
Nice work!
Along with my best wishes for a happy and prosperous 2024 to all the DLF
community members, and their families and friends.
Ehhxcellent!
What could possibly go better with #dlang than a Ferrari? Come enjoy the Ferrari
movie with us. Bring a friend!
https://www.showtimes.com/movie-theaters/regal-bella-bottega-stadium-11-8026/
8890 NE 161st Ave, Redmond, WA 98052 844-462-7342
Send me an email to get on the Dlang Club mailing
On 12/17/2023 2:53 AM, Adam Wilson wrote:
You have my email already!
Of course!
If you want to be on it, email me your address!
We hope to have some fun activities for D aficionados. For example, I am
planning "Ferrari Night" towards the end of the month where we all meet at the
theater to watch "Ferrari".
https://www.imdb.com/title/tt3758542
On 12/12/2023 9:52 AM, Gregor Mückl wrote:
Hi!
I'm interested in joining this time. Looking forward to meeting you all!
It was fun to meet you! Glad you could come.
6 of us attended, and we had a grand time! After Red Robin threw us out at 10PM
because they were closing, we continued for another hour in the parking lot.
On 12/7/2023 9:17 PM, Ki Rill wrote:
This is amazing!
All in a day's work!
It should solve the disappearing of enum-like definitions in
code. I encountered this in Raylib. It has colors defined as macros:
```c
#define WHITE (Color){255, 255, 255, 255}
```
I preprocessed the file and all
On 12/6/2023 12:43 PM, Dave P. wrote:
Does this work for function-like macros?
Not yet. It just lays the groundwork for that.
On 12/6/2023 11:59 AM, Walter Bright wrote:
Macros with the pattern:
#define BOO ( expression )
are now translated to:
auto BOO()() { return expression; }
and are available for importing!
The interesting thing here is `expression` does not need to be translated to D.
It's still
Macros with the pattern:
#define BOO ( expression )
are now translated to:
auto BOO()() { return expression; }
and are available for importing!
On 10/28/2023 1:54 PM, bachmeier wrote:
I wonder if Walter has an opinion on this. In a .c file:
It looks like the author is self-taught with little exposure to other
programmers.
On 10/26/2023 2:30 AM, John Colvin wrote:
Good talk.
Many very clever people would achieve more if they tried to understand why a v.
experienced developer would care to spend so much time talking about what might
appear to be such basic points.
The key challenge: If this stuff was so
On 10/3/2023 8:10 AM, matheus wrote:
I understand the advantages of the UFCS, I was just pointing out that the
example given in that post are NOT equivalent, if it was deliberated or not I
don't know, but I think it was just a small mistake, otherwise the author
woundn't say they are
On 10/18/2023 11:51 AM, Max Samukha wrote:
On Tuesday, 3 October 2023 at 19:03:00 UTC, Walter Bright wrote:
$0.
true
It's one reason why donations to the DLF go a long way. We try hard to squeeze
the most out of every dollar.
On 10/8/2023 6:21 AM, sighoya wrote:
I have another thing to add. You argued about reasons not to use macros but
these reasons don't apply to AST Macros, they won't allow constructing new
languages like in Lisp or in Neat.
Typed AST Macros would only accept parseable D source code with
On 10/7/2023 5:37 AM, sighoya wrote:
Thanks, I think we need more of this as D has become a large language already.
There were some points I even never considered before.
I'm glad it's a win for you!
I disagree however in all binary types should be just boolean.
I prefer
On 10/5/2023 10:21 AM, angel wrote:
I don't mind if it does not compile without the `ref`, but it should be on the
table - WYSIWYG.
It's a good point. Consider the refactoring angle. If I wished to switch from a
struct to a class, and vice versa, and can just change the definition. If `ref`
On 10/5/2023 6:30 AM, claptrap wrote:
While I agree with the overall gist I didn't find his examples very interesting
or convincing. They were pretty much all made up to illustrate, outdated, or
disingenuous (the first one with the intentionally obfuscated code).
I know they look trivial, but
On 10/4/2023 5:53 PM, claptrap wrote:
I have never once said he cant talk about whatever he wants to, I've explicitly
said the opposite. All I said is that by virtue of who he is has more
interesting things to talk about than whether "enum { yes, no }" is a good idea
or not.
When I stop
On 10/4/2023 12:50 PM, claptrap wrote:
Yes he can do what he likes, nobody has the right to demand anything from him.
But his position and experience and knowledge is such that him doing a talk on
coding guidelines is disappointing.
Considering how few people follow the coding guidelines I
On 10/23/2023 12:02 PM, Sönke Ludwig wrote:
Link:
https://aspect.bildhuus.com/blog/posts/how-we-are-using-d-from-the-ground-up
https://x.com/WalterBright/status/1717077828255228223
On 10/3/2023 12:36 AM, Max Samukha wrote:
'No hire' for language designers who design sum types to be implicitly
enumerated and convertible to integers and booleans?
There's a reason my salary from the D Foundation is $0.
HN front page, too!
https://news.ycombinator.com/news
On 8/9/2023 7:25 PM, Doigt wrote:
whoa that's pretty cool you could do it in D, I had to write my syntax file
using regexes :-(
I feel so sorry for you!
On 8/7/2023 5:43 PM, Doigt wrote:
Would be nice to have feedback. I made a PR for the improved nano syntax project
because I don't have a gitlab account to contribute directly to the nano
project, but feel free to fork and do it yourself if you feel it's
important/good enough.
Here's the PR:
On 8/7/2023 10:35 PM, Vladimir Panteleev wrote:
It would have been nice to be in the loop so I could have helped avoid this
situation; oh well!
Sorry about that. Will include you next time.
On 7/6/2023 8:14 PM, Richard (Rikki) Andrew Cattermole wrote:
And for the record I still want hex strings to come back. They were incredibly
useful with no good alternatives when we talk about large tables of data being
described.
For reference:
https://github.com/dlang/dmd/pull/13773
On 7/7/2023 7:56 AM, Guillaume Piolat wrote:
It just seems to me, instead of complaining when features become deprecated,
people will complain when obsolete feature becomes deprecated and they see the
message. The proposal here is that they see the message later. In the meantime,
nothing will
As time moves on, the D language has to evolve as well. What do we do with
obsolete and/or problem-causing, legacy features?
Our answer was deprecation. The deprecation starts out as just a message, which
can be disabled, or can be set to be errors. The deprecations could last for
many years,
Hotels are running out of room, and prices are going up as a result. Book ASAP.
#dconf
Thank you, this is great news!
But the license is different from the license Phobos uses, and with the
conditions it makes the most sense to add your libraries to the dub repository.
That way it will be easy to conform to your requirements.
On 5/12/2023 1:30 PM, kinke wrote:
Thanks to all contributors & sponsors!
Yes, indeed!
This initiative has my full support.
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.
You make a good case. I'll think about it.
On 4/26/2023 1:19 AM, Stefan Koch wrote:
While it is true that it only implements a subset of the proposal.
It does implemnent function overloading for non-templated functions the specific
code for this is here:
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.
On 4/25/2023 4:12 PM, max haughton wrote:
I have never been in favour of D having bitfields. This isn't worth breaking
stuff for.
D bitfields didn't break anything. Also, it exposed an overlooked bug in the
ImportC bitfields.
On 4/18/2023 6:36 AM, Petar Kirov [ZombineDev] wrote:
On Tuesday, 18 April 2023 at 03:02:16 UTC, Walter Bright wrote:
On 4/15/2023 6:49 AM, Monkyyy wrote:
By all means fund and promote *live coding* or teaching videos if you want to
outreach, but shitposting on twitter wont do anything
On 4/15/2023 4:12 AM, Hipreme wrote:
Great! I'll try starting to do that also since we most of the time we're here
posting only to existing D users, being in an unfiltered platform such as
twitter could help too.
Good!
I've started doing that kind of work on instagram since images tells a
On 4/15/2023 6:49 AM, Monkyyy wrote:
By all means fund and promote *live coding* or teaching videos if you want to
outreach, but shitposting on twitter wont do anything of value
Mike has also suggested I do some live coding videos.
On 4/14/2023 5:54 PM, zjh wrote:
Can you create a special post in the forum?
This way, it is safer and more convenient.
That is a good idea to do that as well. But I have no idea why would be safer?
Anyhow, the idea with Twitter is outreach to a larger audience. Newspapers all
do it, why
I've had a twitter account for 15 years now (!) and haven't used it much for
anything. But lately I've decided to use it to give regular updates on D things
I've been working on.
You can follow me on:
https://twitter.com/WalterBright
I encourage other D users on twitter to do the same!
On 4/11/2023 7:35 PM, bachmeier wrote:
Can't the changes to those files by stored in the compiler? Walter obviously
can't change the raw header files, but he can make changes to the files before
they're used by the compiler. If that's not possible, can't a modified set of
header files be
On 4/3/2023 9:41 AM, Iain Buclaw wrote:
Glad to announce D 2.103.0, ♥ to the 43 contributors.
And a special thanks to you, Iain, for deftly managing the releases!
Ehhxcellent!
On 3/5/2023 5:19 AM, Mike Parker wrote:
If you aren't subscribed to our YouTube channel and [missed the first
announcement](https://forum.dlang.org/thread/ljyxxtlaooxzwymad...@forum.dlang.org), you might not know about Dennis Korpel's DLang Contributor Tutorials.
I've just published Part 4,
On 1/28/2023 5:04 AM, Johan wrote:
Is there a document describing cases where removal of `@property` does not lead
to an error but does lead to a change in behavior of code?
No.
We are considering a blanket removal of 3000+ instances of `@property`. The
resulting compile errors I can fix
On 1/27/2023 12:35 PM, kinke wrote:
Glad to announce the first beta for LDC 1.31. Major changes:
Nice work!
On 1/23/2023 11:21 PM, Siarhei Siamashka wrote:
But the safety is not exactly great.
It does (and always has) resolved the #1 memory safety problem - buffer
overflows.
If you use @safe, and the GC for allocations, it is just as memory safe as
Python.
On 1/11/2023 8:15 PM, Tejas wrote:
Well, the companies don't get to single-handedly decide what features to add or
deprecate, thanks to C spec being written by ISO, which is why they have
developed their own PLs.
Yes they can, as they add extensions to C all the time.
But also, adding
On 1/11/2023 3:26 AM, Paulo Pinto wrote:
It is kind of "solved", by turning all computers into C machines,
What an amazing amount of work just to avoid adding dynamic arrays to C.
By the way, back in the 80's, I wrote my own pointer checker for my own use
developing C code. It was immensely useful in flushing bugs out of my code.
There are vestiges of it still in the dmd source code.
But it ran very slooowwly, and was not usable for
shipped
On 1/10/2023 10:49 PM, Siarhei Siamashka wrote:
It's impractical to have this in the ISO standard, but surely not impossible.
Various C compilers from different vendors implement bounds checking. See:
* https://bellard.org/tcc/tcc-doc.html#Bounds
This works by constructing a data
On 1/8/2023 8:31 PM, Siarhei Siamashka wrote:
On Monday, 9 January 2023 at 03:54:32 UTC, Walter Bright wrote:
Buffer overflows are trivial to have in C, and C has no mechanism to prevent
them.
ASAN, Valgrind, Clang Static Analyzer and plenty of other tools are the
practical mechanisms
On 1/8/2023 10:34 PM, Paulo Pinto wrote:
The best part of memory safe systems programming languages is that many of those
tools don't even have to exist, they are part of language semantics!
Exactly! I once annoyed the Coverity folks by telling them that my goal with D
was to make Coverity
On 1/7/2023 2:25 PM, areYouSureAboutThat wrote:
In fact, C can be used in a perfectly memory safe manner.
Yes, as long as you don't make any mistakes. A table saw won't cut your fingers
off if you never make a mistake, too.
The problem is that too few programmers know how to do that, and
A big thank you!
On 12/20/2022 1:51 PM, Adrian Matoga wrote:
I frequently find it useful for a text data file parser to call a diagnostic
callback instead of assuming some default behavior (whether that's forgiving,
printing warnings, throwing or something else). With template callback
parameters the parser
On 12/21/2022 6:27 AM, Adam D Ruppe wrote:
On Tuesday, 20 December 2022 at 00:16:57 UTC, Walter Bright wrote:
LOL, learn something every day! I've even written my own, but it isn't very
good.
Yeah, I wrote a csv module too back in... I think 2010, before Phobos had one.
It is about 90 lines
On 12/20/2022 8:19 PM, 9il wrote:
It has already been replaced with
[mir.csv](https://github.com/libmir/mir-ion/blob/master/source/mir/csv.d). Mir
is faster, SIMD accelerated, and supports numbers and timestamp recognition.
Propose this for Phobos?
On 12/20/2022 11:46 AM, John Colvin wrote:
We use this at work with some light tweaks, it’s done a lot work
Sweet!
On 12/19/2022 4:35 AM, Adam D Ruppe wrote:
On Monday, 19 December 2022 at 09:55:47 UTC, Walter Bright wrote:
Curious why CSV isn't in the list.
Maybe std.csv is already good enough?
LOL, learn something every day! I've even written my own, but it isn't very
good.
On 12/18/2022 5:08 AM, Mike Parker wrote:
We're coming up on the start of the Day Two livestream. I'll get it started at
13:45 UTC. I'll jump in around 13:50, and Walter will join me at 13:55 just
before his talk starts.
See you there!
https://youtu.be/VCgdajZconA
Another marvelous DConf
On 12/18/2022 7:56 AM, Robert Schadek wrote:
So stop talking, and start creating PR's.
Yup!
Curious why CSV isn't in the list. I encounter that a lot at tax time.
https://en.wikipedia.org/wiki/Comma-separated_values
Maybe just ask OpenAI?
On 12/17/2022 5:12 AM, Mike Parker wrote:
The DConf Online Day One Q & A Livestream kicks off in less than an hour. See
you there!
Many thanks to today's speakers:
Átila Neves
Max Haughton
Robert Schadek
Dennis Korpel
Adam D. Ruppe
who obviously spent a lot of time and effort preparing their
On 11/2/2022 4:19 AM, Steven Schveighoffer wrote:
https://briancallahan.net/blog/20220704.html
That's now in the "new" section of HackerNews!
https://news.ycombinator.com/newest
On 11/2/2022 4:19 AM, Steven Schveighoffer wrote:
On one of the only articles using ImportC (which otherwise shines a positive
light on the feature), this specific issue is the only one that comes up as a
blocker:
The easiest option would be to simply ignore "const" when it is "const pointer
Just posted it in the "New" section of HackerNews
On 9/22/2022 6:10 AM, Guillaume Piolat wrote:
September was a great month for the D sub-community around #Dplug & #audio.
Very nice work!
Thank you, Mike!
On 8/6/2022 1:29 PM, Timon Gehr wrote:
Seems you should just use a long double/real literal?
real x = 0x1p-16383L; // (works)
Looks like that settles it. (Why didn't I notice that? Sheesh!)
On 8/6/2022 4:08 AM, Max Samukha wrote:
UFCS could still be supported with the exception of functions named like
exponents. (I am not advocating for it.)
We could, and enter the inevitable bug report from the baffled user who can't
figure out why UFCS stopped working for his
On 8/6/2022 2:02 AM, Tim wrote:
It could silently break code if the right function is defined. The following
example is valid in C and D (except import/include), but prints a different value:
```D
// #include
import core.stdc.stdio;
int E2(int i)
{
return i;
}
int main()
{
float f
On 8/5/2022 9:43 AM, Max Samukha wrote:
Both "123." and "123.E123" is valid C. For some reason, D only copied the
former.
It's to support UFCS (Universal Function Call Syntax). The idea with C
compatible aspects of D is to not *silently* break code when there's a different
meaning for it.
On 7/20/2022 11:43 AM, kinke wrote:
Glad to announce LDC 1.30.0.
Yay!
On 7/11/2022 2:18 PM, bachmeier wrote:
One reason is that the editing can be done automatically by services like
Descript. I don't know if Mike does it manually.
Doing it automatically means then you've got to spend time comparing the two to
ensure it cut in the right places :-(
On 7/10/2022 8:26 PM, Mike Parker wrote:
On Sunday, 10 July 2022 at 18:26:13 UTC, bachmeier wrote:
Have you considered uploading the audio to Spotify or somewhere as a podcast?
No idea what that would involve, but for a lot of us there are more
opportunities to listen to a podcast rather than
Mike has our full support in his moderation policy and authority.
#28 on the front page
https://news.ycombinator.com/news
On 6/5/2022 10:49 PM, Paulo Pinto wrote:
On Sunday, 5 June 2022 at 22:41:14 UTC, Walter Bright wrote:
That are *C* compilers doing imports for *C* code?
https://clang.llvm.org/docs/Modules.html
And I am out of this thread.
I had thought that was just for ObjectiveC. It seems it does work
On 6/4/2022 10:54 PM, Paulo Pinto wrote:
That paper had a real implementation to follow along,
I didn't see it.
while Lucid and IBM
products were real things one could buy.
That are *C* compilers doing imports for *C* code?
What C compilers have imports:
gcc - nope
clang - nope
VC - nope
1 - 100 of 2363 matches
Mail list logo