Re: DLF September 2023 Planning Update
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.
Re: First Beta 2.106.0
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 behalf of the Dlang Core Team Filed https://issues.dlang.org/show_bug.cgi?id=24246 for ICE
Re: DLF September 2023 Planning Update
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 out all the implementation issues Razvan has raised. IMHO having a general purpose migration tool is a big win. For example, I, as a library owner, want to help users to migrate their code from one library version to another and making this code evolution automatic would be ideal.
Re: DLF September 2023 Planning Update
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 to see is something like "we took a look at languages A,B and C and we decided that editions should work that way because X, Y and Z" or "editions should work the same way as in language A" There will always be two requests and you'll have to provide a solution (tbh I don't see how to make everyone happy here): - I want my old code to be built with the latest compiler the same way forever. - I want to evolve my code together with the language and compiler.
Re: DLF September 2023 Planning Update
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.
Re: LDC 1.35.0
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/releases/tag/v1.35.0 Thanks to all contributors & sponsors! I got this error with [1.35](https://github.com/andrey-zherikov/argparse/actions/runs/6329005408/job/17881016327#step:4:24): ``` Exception Code: 0xC005 #0 0x7ff74f6b00d4 (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x2ee00d4) #1 0x7ff74f6b118d (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x2ee118d) #2 0x7ff74c8527c8 (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x827c8) #3 0x7ff74f9d33b1 (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x32033b1) #4 0x7ff74f64f052 (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x2e7f052) #5 0x7ff74f7601da (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x2f901da) #6 0x7ff74f75fe2f (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x2f8fe2f) #7 0x7ff74f760135 (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x2f90135) #8 0x7ff74f6484dd (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x2e784dd) #9 0x7ff74f9ff4c4 (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x322f4c4) #10 0x7ffc84be4de0 (C:\Windows\System32\KERNEL32.DLL+0x14de0) #11 0x7ffc859fed9b (C:\Windows\SYSTEM32\ntdll.dll+0x7ed9b) Error C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe failed with exit code -1073741819. ``` There was no error with [1.34](https://github.com/andrey-zherikov/argparse/actions/runs/6165141917/job/16732347607) Does this look familiar?
Re: reggae v0.10.0 - The meta build system just got better
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 itself without calling external tools (make, ninja)? PS I tried to reach you out on Discord and LinkedIn but no response so far.
Re: reggae v0.10.0 - The meta build system just got better
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 Makefiles are a nightmare and will never get dependencies right. dub isn't a build system, although it includes a very limited one that can't be extended. I agree that dub is not a build tool, it's more a package manager. TBH I had the same thought - we should have "good" build tool for D that has D as a language. Since I have some experience with CMake and agree with a lot of people that it have horrible language, I thought it would be beneficial. But then I looked round and realized that it will be like this: In practice, this doesn't seem to happen with build systems. Instead each language ecosystem ends up using its own: CMake, Gradle, Rake, ... IMHO this does not prove that D must have its own build system. Have you looked as Meson, for example - it even has a [section about D](https://mesonbuild.com/D.html)? Yes, and even had to use it for D. I don't know what state it's in now, but it was pretty much unusable if one had dub dependencies which... is nearly always the case. I believe this is applicable to all build systems atm - they don't know what dub is and how to deal with it. Then there's the language: I'd rather use D or Python. If anything, Meson's use case could be questioned just as well by "why another build language?". TBH I thought Meson uses python but just found out it's not. My bad. Just took a quick look at [known build tools](https://en.wikipedia.org/wiki/List_of_build_automation_software#Licensing_overview) and noticed that there are (at least) two build tools that have Python as a build language and support D: [SCons](https://en.wikipedia.org/wiki/SCons#Major_features) and [Waf](https://en.wikipedia.org/wiki/Waf_(build_system)#Features). Although I don't how well they support it. My whole comment was about the reasoning why we need new build system and can't improve existing one. So I would expect more wide analysis and comparison [here](https://github.com/atilaneves/reggae#why), not just with CMake. My main concern is that if we create a brand new build tool, years later it might turn out that other existing tool got wide adoption for D so this project become abandoned and all efforts are thrown away.
Re: reggae v0.10.0 - The meta build system just got better
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 CMake, it can also output tup files and has its own binary generator in case the dependency on one of those programs is undesired. Also unlike CMake, it supports dub projects out-of-the-box by using dub as a library. Out of curiosity, why do we need one more build tool? TBH I had the same thought - we should have "good" build tool for D that has D as a language. Since I have some experience with CMake and agree with a lot of people that it have horrible language, I thought it would be beneficial. But then I looked round and realized that it will be like this:  So I dropped that idea and think that investing into existing build tool to support D will be much more efficient. Have you looked as Meson, for example - it even has a [section about D](https://mesonbuild.com/D.html)?
Re: GCC 12.2 Released (D v2.100.1)
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)?
argparse 1.1.0: now with ANSI colors and styles
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:  Complete list of available features can be found in [readme](https://github.com/andrey-zherikov/argparse#features).
Re: New WIP DUB documentation
Just throwing an idea: may be dub can support yaml which has comments?
Re: argparse version 1.0.0
On Saturday, 11 June 2022 at 08:04:14 UTC, SealabJaster wrote: If it's any consolation, there's yet another person trying to use the library that I'm currently disapointing ;^) Are you disappointed with jcli? Why? It's pretty good.
Re: argparse version 1.0.0
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 parsed before invoking the command. https://github.com/CyberShadow/steamkeyactivator/blob/144d322ecee65f4f536e5fd4141837e51d61a27a/activator.d#L142 When only some commands need to share some arguments, you can put them in a tuple. https://github.com/CyberShadow/Digger/blob/7c7dd167aea2214d594bab932ea4e41e5f0a357a/digger.d#L34 Now you have both approaches: parsing into struct with members and parsing into function arguments. Why do we need two if one is enough?
Re: argparse version 1.0.0
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 features I was looking for. That was the main reason to start this work. I was wondering if you ran into any strong reasons for describing the arguments as a struct, rather than, well, function arguments. I have had good success so far with the latter, which has the benefit of being succinct: https://github.com/CyberShadow/btdu/blob/116d190079ca77d61383eb738defa4318d5a1e5f/source/btdu/main.d#L59 This is an interesting approach. I think they are equivalent for simple cases but how would you model subcommands with common arguments for all of them?
argparse version 1.0.0
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 what argparse does, here is not complete list of features (see full list in [readme](https://github.com/andrey-zherikov/argparse#readme)): - Positional arguments, short and long options - Argument groups - Subcommands - Help text generation - Shell completion
Re: argparse version 0.7.0 - a CLI parsing library
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 good. But without a commitment to SemVer stability, it's hard to recommend a v0.0.x package to people. v1.0.0 will be definitely there as soon as I'm done with all major features. I want to minimize breaking changes after v1.
argparse version 0.7.0 - a CLI parsing library
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 the usage without UDAs - Custom grouping of arguments on help screen - Mutually exclusive arguments - Mutually dependent arguments - Subcommands Enjoy it! Regarding the future, I have some items in my todo list and here are few things I will work on next: - Improve subcommand support (for example, default command) - Shell completion In case if anyone has thoughts about what feature is missed in the library, I'm open to the suggestions. -- Andrey
Re: New library: argparse, for parsing CLI arguments
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
`@NamedArgument(names, help_text)` as a shortcut for
`@(NamedArgument(names).HelpText(help_text))` for CLI.
Re: New library: argparse, for parsing CLI arguments
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 todo list
Re: New library: argparse, for parsing CLI arguments
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?
Re: New library: argparse, for parsing CLI arguments
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 `Params` struct be distinctly for parameter parsing. It's OK to have requirements such as expecting all items to be serialized by default and in a default way. Structs without UDA are now supported starting version `0.4.0`. I also added this use case as a basic into "Getting started" section in readme.
Re: New library: argparse, for parsing CLI arguments
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 `__traits(allMembers, __MODULE__)` gives `"mymodule" can't have members, "mymodule" must evaluate to either a module, a struct, an union, a class, an interface or a template instantiation` You can use `__traits(allMembers, mixin(__MODULE__))`. How nice! Thanks!
Re: New library: argparse, for parsing CLI arguments
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 global namespace that people don't always realize is a global namespace. Quite annoying when you go to add something like a "--start_time" flag and find that some random .cc file in a library already defines that flag for their own purposes. --bb I might be wrong but AFAIK D program doesn't have global namespace - it's split between modules. Another thing is that I couldn't use `allMembers` without using the module name explicitly, because: `__traits(isModule, __MODULE__)` returns `false` and `__traits(allMembers, __MODULE__)` gives `"mymodule" can't have members, "mymodule" must evaluate to either a module, a struct, an union, a class, an interface or a template instantiation`
Re: New library: argparse, for parsing CLI arguments
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! > > 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 around to it. It would be great if > argparse would add such support. This is an interesting approach. I'm not a fan of it but I'll take a look at whether this can be supported. Not sure how much change there is over "classic" gflags, but https://abseil.io/docs/cpp/guides/flags is what google now uses internally. --bb Abseil version suggests not to put flags into multiple .cpp files: - `Allows distributed declaration and definition of flags, though this usage has drawbacks and should generally be avoided` - `Prefer to define flags only in the file containing the binary’s main() function` - `Prefer to reference flags only from within the file containing the binary’s main() function` So I'm a bit confused about supporting this use case
Re: New library: argparse, for parsing CLI arguments
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 around to it. It would be great if argparse would add such support. This is an interesting approach. I'm not a fan of it but I'll take a look at whether this can be supported.
Re: New library: argparse, for parsing CLI arguments
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, looks clean. I actually started with the research how this can be done and here is a result.
Re: New library: argparse, for parsing CLI arguments
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 (and required
in some cases, e.g. the `enum` case above), but honestly, the
`Params` struct exists solely to accept command line
parameters, there's no compelling need to use alternate names
for the command line and the field name. If the library
automatically does the right thing by default, then your code
becomes simpler and more beautiful.
Not to detract from your library, because I think it's an
awesome design to model using structs (one I use all the time),
but the API developer in me frowns at lack of DRY. Try to focus
on requiring the smallest amount of machinery/attributes
possible. Every time you require extraneous pieces to get
things to work, it adds another place where errors/confusion
can happen.
I got your point. Omitting the name is good suggestion and I'll
add this.
Regarding the detecting all members and treating them as an
arguments, I see one issues so far: the struct might have other
members that are not used in CLI (it can be even functions).
Consider the example when the member is renamed but the struct
still provides the old name for backward compatibility:
```d
struct T
{
string name;
@property string label() const { return name; }
}
pragma(msg, __traits(allMembers, T)); // tuple("name", "label")
```
Another example is when the struct has additional functions
convenient for the users so it's not clear whether `void foo()`
is a CLI flag or just a convenient function.
So to implement your suggestion correctly, `argparse` should
provide a way to opt-out specific members from CLI.
In addition to that, each CLI argument usually has its own help
text so in most cases each member will have an UDA with this text
which makes opt-out approach mush less useful. So it sill look
like this at the end:
```d
struct T
{
@help("First name")
string firstName;
@help("Last name")
string lastName;
@skip
@property string fullName() const { return firstName~"
"~lastName; }
}
```
Re: New library: argparse, for parsing CLI arguments
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 unnecessary.
I think `unused` word confuses a bit. I meant the argument that
is skipped in command line so it has a default value (`"some
default value"`).
So having this is totally fine:
```d
struct Params
{
string s;
@NamedArgument("num")
int n;
}
```
I'll rename `unused` to remove this confusion.
Re: New library: argparse, for parsing CLI arguments
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 https://code.dlang.org/packages/expected, where you can additionally return error values with instead of returning null on error. Doesn't cast to bool but can check for .hasError which is more explicit. This will break "doesn't depend on anything besides std" unfortunately.
New library: argparse, for parsing CLI arguments
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 parsing library is that the existing libraries do not provide enough flexibility in parsing that I'm looking for and/or they depend on other libraries. As a result `argparse` supports wide variety of data types including enums, callbacks and arrays as well as a fully customized argument parsing. It also doesn't depend on anything besides the standard library. Since it's in active development (activeness depends on my availability of course), I have few things to do before making the first major release so stay tuned and/or contribute if you'd like to.
