On Wednesday, 15 November 2023 at 11:05:03 UTC, Jonathan M Davis
wrote:
So, we'll have to see what they actually manage to come up with.
I guess this is the only way to understand the idea of how this
should work.
On Thursday, 2 November 2023 at 00:57:23 UTC, Iain Buclaw wrote:
Glad to announce the first beta for the 2.106.0 release, ♥ to
the 33 contributors.
http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.106.0.html
As usual please report any bugs at
https://issues.dlang.org
-Iain
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:
* We should have a tool that automates as much as possible the
migration of modules to new editions
* DMD-as-a-library is a critical component for that tool and
other tools in the ecosystem. We need to put a priority on
working ou
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:
## Editions
Did you take a look at other languages and how they implement
this feature? May be there is a language that already implements
the approach your are looking for and you don't need to reinvent
a wheel?
What I'd like
On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:
## The future of D
Did you see this video from cppnow'23?
https://youtu.be/VMYVbA2gg0g?si=fMGbnE0FliLwmYgo
It's a good talk about language evolution in general.
On Sunday, 15 October 2023 at 13:37:30 UTC, kinke wrote:
Glad to announce LDC 1.35.0. Major changes:
* Based on D 2.105.2+.
* A few important ImportC fixes.
* Fix GC2Stack optimization regression introduced in v1.24.
Full release log and downloads:
https://github.com/ldc-developers/ldc/release
On Thursday, 21 September 2023 at 15:59:10 UTC, Atila Neves wrote:
...
I got your point.
Why does it have multiple languages (front-ends)? Is there anyone
willing to write build script for C++ on JavaScript or Ruby, for
example?
Also why is it meta build system? Why can't it just build by
On Wednesday, 20 September 2023 at 21:19:22 UTC, Atila Neves
wrote:
Because we don't have one now. Using CMake for D is horrible,
I would say just using CMake is horrible :-D But there are a lot
of people using it (even myself) and they all are trapped with
the language.
Hand-written Makefi
On Thursday, 7 September 2023 at 17:34:48 UTC, Atila Neves wrote:
https://code.dlang.org/packages/reggae
For those who don't know, reggae is a meta-build system for and
in D. It's like CMake, if you replace their terrible language
with D*. Like CMake, it can output make and ninja files. Unlike
On Friday, 19 August 2022 at 11:36:09 UTC, Iain Buclaw wrote:
GCC version 12.2 has been released.
Is it possible to add GDC to [github
actions](https://github.com/dlang-community/setup-dlang)?
New version 1.1.0 of `argparse` is published!
Major feature in this version is fully customized ANSI coloring
and styling.
Here is an example of default styling:
Are you disappointed with jcli? Why? It's pretty good.
On Friday, 10 June 2022 at 14:20:15 UTC, Vladimir Panteleev wrote:
I invoke https://xkcd.com/927/ ! :)
:-D
I tried to improve one of the existing libs but it didn't go well
enough.
Glad you asked! I use an approach similar to the one here, with
commands in a struct. The common arguments are
On Friday, 10 June 2022 at 09:20:24 UTC, Vladimir Panteleev wrote:
Congratulations on the release. Though there's a good number of
libraries for this task in D already, this solution looks very
complete.
I looked at them when I started this project and they didn't
provide complete set of feat
Hi everyone,
I'm glad to announce first major version of
[argparse](https://code.dlang.org/packages/argparse) - a library
for creating command line interface. It took some time to figure
out public API of this library and I believe it's mature enough
for the major version.
If you don't know
On Monday, 14 March 2022 at 13:09:53 UTC, Guillaume Piolat wrote:
On Monday, 14 March 2022 at 03:06:44 UTC, Andrey Zherikov wrote:
In case if anyone has thoughts about what feature is missed in
the library, I'm open to the suggestions.
A v1.0.0 tag. A roadmap, examples, tutorials are already
Hi everyone,
I'd like to share that I've published a new version of
[argparse](https://code.dlang.org/packages/argparse) library.
It's got some new features since my [first
announcement](https://forum.dlang.org/post/zjljbdzfrtcxfiuzo...@forum.dlang.org) as well as some bug fixes:
- Support of
On Tuesday, 19 October 2021 at 14:06:21 UTC, Steven Schveighoffer
wrote:
Just nitpicks. Like allowing `@NamedArgument` without
parentheses. Or using `@NamedArgument("b", "banana", "ban")`
instead of `@NamedArgument(["b", "banana", "ban"])`
I did array because I think it makes sense to have
`@
On Tuesday, 19 October 2021 at 03:49:46 UTC, Mathias LANG wrote:
Very interesting! I was looking for something similar recently,
will definitely give it a try! One thing that it'd be
interested to see would be subcommand support. Check what DUB
is doing for example.
This is definitely in my t
On Monday, 18 October 2021 at 13:16:01 UTC, Steven Schveighoffer
wrote:
OMG this looks awesome! I will switch my code to using it...
Glad to hear that my work is useful!
Prepare for some PRs, I already see ways to make this better ;)
Don't you mind sharing your ideas?
On Thursday, 14 October 2021 at 15:03:34 UTC, Steven
Schveighoffer wrote:
Having done a lot of stuff with serialization and UDAs, this
turns into a mess if you have multiple systems (serialization
is really what you are doing here) using the same structs. So
really, you are likely to have this
On Thursday, 14 October 2021 at 13:51:50 UTC, Paul Backus wrote:
On Thursday, 14 October 2021 at 13:37:29 UTC, Andrey Zherikov
wrote:
Another thing is that I couldn't use `allMembers` without
using the module name explicitly, because: `__traits(isModule,
__MODULE__)` returns `false` and `__trai
On Thursday, 14 October 2021 at 02:09:35 UTC, Bill Baxter wrote:
Yeh, it's definitely a mixed bag. It can be very convenient to
be able to put the flag right near point of use without having
to do any plumbing. But sometimes it can be frustrating given
that "flags" are essentially a single glo
On Thursday, 14 October 2021 at 00:35:11 UTC, Bill Baxter wrote:
On Wed, Oct 13, 2021 at 5:30 PM Andrey Zherikov via
Digitalmars-d-announce < digitalmars-d-announce@puremagic.com>
wrote:
On Wednesday, 13 October 2021 at 19:26:49 UTC, Andrei
Alexandrescu wrote:
> Cool!
>
> On
On Wednesday, 13 October 2021 at 19:26:49 UTC, Andrei
Alexandrescu wrote:
Cool!
One note - gflags (https://opensource.google/projects/gflags)
allows modules to define their own flags in a decentralized
manner. I've always thought this is a major feature missing
from std.getopt, but never got
On Wednesday, 13 October 2021 at 18:39:47 UTC, SealabJaster wrote:
On Wednesday, 13 October 2021 at 11:27:40 UTC, Andrey Zherikov
wrote:
...
Guess you got fed up with me not updating JCLI :3
Looks great either way, I really like what you've done with the
`.Parse!().PreValidate!()` chaining,
On Wednesday, 13 October 2021 at 16:24:52 UTC, Steven
Schveighoffer wrote:
The point is that I shouldn't have to tell the library the name
of something that I've already given a name to.
Having them named differently on the command line than the
actual field name should still be a possibility
On Wednesday, 13 October 2021 at 14:36:30 UTC, Steven
Schveighoffer wrote:
One nitpick -- you should be able to opt in using the name of
the field member instead of having to write `@NamedArgument`.
e.g. your `string unused` parameter requires a
`@NamedArgument("unused")` which seems unnecessar
On Wednesday, 13 October 2021 at 11:59:06 UTC, WebFreak001 wrote:
On Wednesday, 13 October 2021 at 11:27:40 UTC, Andrey Zherikov
wrote:
[...]
It also doesn't depend on anything besides the standard
library.
[...]
if you want to drop the dependency on std.typecons : Nullable
you could use ht
Hi everyone,
I'm happy to announce that I've published a CLI argument parsing
library - [argparse](https://code.dlang.org/packages/argparse).
It's been around for some time already so please take a look and
provide your feedback if you haven't done so.
The reasoning to create one more CLI pa
31 matches
Mail list logo
