Re: LDC 1.28.0
On Tuesday, 19 October 2021 at 23:37:22 UTC, kinke wrote: Glad to announce LDC 1.28 - some highlights: * Based on D 2.098.0+ (yesterday's stable). * Dynamic casts across binary boundaries (DLLs etc.) now work. * Windows: `-dllimport=defaultLibsOnly` doesn't require `-linkonce-templates` anymore. * dcompute: Basic support for OpenCL image I/O. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.28.0 Thanks to all contributors & sponsors! Well done guys 👏
Re: Beta 2.098.0
On Wednesday, 20 October 2021 at 05:08:51 UTC, max haughton wrote: On Wednesday, 20 October 2021 at 01:48:24 UTC, Walter Bright wrote: On 10/19/2021 6:35 AM, Timon Gehr wrote: [...] Timon and I famously disagree over the concept behind @live. Nevertheless, we do agree that ImportC is more important. Iain and I have decided that changing the build process so that Phobos' zlib code is built with dmd rather than gcc is going to be our goalpost for declaring ImportC ready to use. Why is compiling zlib a goalpost for *Import*C? Hopefully that doesn't make it "finished, because that goalpost has almost no effect on the issues actually plaguing C interop at the moment - i.e. the preprocessor. I interpreted it as "a goalpost", not *the* goal. I hope at least 🍀 ImportC has the potential to be really powerful. But maybe the later steps doesn't have to be made by Walter?
Re: Beta 2.098.0
On Wednesday, 20 October 2021 at 01:48:24 UTC, Walter Bright wrote: On 10/19/2021 6:35 AM, Timon Gehr wrote: I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise. Timon and I famously disagree over the concept behind @live. Nevertheless, we do agree that ImportC is more important. Iain and I have decided that changing the build process so that Phobos' zlib code is built with dmd rather than gcc is going to be our goalpost for declaring ImportC ready to use. Why is compiling zlib a goalpost for *Import*C? Hopefully that doesn't make it "finished, because that goalpost has almost no effect on the issues actually plaguing C interop at the moment - i.e. the preprocessor.
Re: Beta 2.098.0
On 10/19/2021 6:35 AM, Timon Gehr wrote: I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise. Timon and I famously disagree over the concept behind @live. Nevertheless, we do agree that ImportC is more important. Iain and I have decided that changing the build process so that Phobos' zlib code is built with dmd rather than gcc is going to be our goalpost for declaring ImportC ready to use.
Re: LDC 1.28.0
On Tue, Oct 19, 2021 at 11:37:22PM +, kinke via Digitalmars-d-announce wrote: > Glad to announce LDC 1.28 - some highlights: > > * Based on D 2.098.0+ (yesterday's stable). > * Dynamic casts across binary boundaries (DLLs etc.) now work. > * Windows: `-dllimport=defaultLibsOnly` doesn't require > `-linkonce-templates` anymore. > * dcompute: Basic support for OpenCL image I/O. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.28.0 > > Thanks to all contributors & sponsors! +1, awesome, thanks for the good work! T -- Caffeine underflow. Brain dumped.
LDC 1.28.0
Glad to announce LDC 1.28 - some highlights: * Based on D 2.098.0+ (yesterday's stable). * Dynamic casts across binary boundaries (DLLs etc.) now work. * Windows: `-dllimport=defaultLibsOnly` doesn't require `-linkonce-templates` anymore. * dcompute: Basic support for OpenCL image I/O. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.28.0 Thanks to all contributors & sponsors!
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Tuesday, 12 October 2021 at 19:21:50 UTC, Ben Jones wrote: On Wednesday, 6 October 2021 at 06:23:01 UTC, WebFreak001 wrote: On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: [...] new slogan [...] want to generate controversial heat? Do it in D (DIID) (careful with there being a trademark for DiiD though) How about "from prototype to production" or something? I was reading yesterday about how both memcached and redis were originally written in scripting languages and then rewritten in C for performance. Kinda like this one
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Tuesday, 19 October 2021 at 16:17:43 UTC, Andrea Fontana wrote: On Wednesday, 6 October 2021 at 06:23:01 UTC, WebFreak001 wrote: On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: [...] new slogan [...] want to generate controversial heat? Do it in D (DIID) (careful with there being a trademark for DiiD though) You mean: Just D it That's awesome! using that as my discord status now.
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Wednesday, 6 October 2021 at 06:23:01 UTC, WebFreak001 wrote: On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: [...] new slogan [...] want to generate controversial heat? Do it in D (DIID) (careful with there being a trademark for DiiD though) You mean: Just D it
Re: Beta 2.098.0
On Tuesday, 19 October 2021 at 14:48:20 UTC, Tejas wrote: On Tuesday, 19 October 2021 at 13:53:04 UTC, Paul Backus wrote: I this specific case, I agree completely. But there is a broader pattern in D of projects getting "stuck" because a specific individual is unable to continue work on them (e.g., std.experimental.allocator and Andrei), and I think it is worth considering whether we can do anything to make future projects robust against this mode of failure. The obvious solution is more people who get paid to work on D the language/stdlib/rt-env full-time. Where to get money to pay those individuals? Well there's no obvious solution to that (that I know of). We can say community, but, like the vision documents, they will be a bust because one can't _make_ volunteers meet deadlines, code in a particular way, or incorporate all feedback language maintainers think should be acted on. That would help. But also, I think there are probably steps we could take that would make it easier for people other than the original author to pick up existing stalled projects and help move them towards completion. To return to the `std.experimental.allocator` example: there are many people in the community who'd be happy to contribute towards getting it moved out of `experimental`. The problem is, nobody knows what needs to be done, or what the criteria are to consider the project "finished." If the original author(s) had written down, say, a design document and a TODO list, and posted them somewhere publicly visible (maybe the D Wiki?), we would not have this problem.
Re: New library: argparse, for parsing CLI arguments
On 10/19/21 10:36 AM, Andrey Zherikov wrote:
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.
Just going to put this here, instead of a PR, but if you change your
parameter type to:
```d
NamedArgument(string[] names...);
```
Now, these all work:
```d
NamedArgument("banana")
NamedArgument("b", "banana", "ban")
NamedArgument(["b", "banana", "ban"])
```
If you want to support an array + extra string, then you can add:
```d
NamedArgument(string[] names, string helptext);
```
And it shouldn't conflict with the first overload.
Though, I like the explicit HelpText better (that's what I'd use, even
if the convenient overload is there). UDAs that don't spell out what
they are for are harder to review.
-Steve
Re: Beta 2.098.0
On Tuesday, 19 October 2021 at 13:53:04 UTC, Paul Backus wrote: On Tuesday, 19 October 2021 at 13:35:16 UTC, Timon Gehr wrote: On 11.10.21 03:08, Paul Backus wrote: Perhaps worth asking why Walter, specifically, is required to work on @live in order for it to make progress. Is it just because no one else is willing to step up to the plate, or is he the only person qualified/capable enough? I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise. I this specific case, I agree completely. But there is a broader pattern in D of projects getting "stuck" because a specific individual is unable to continue work on them (e.g., std.experimental.allocator and Andrei), and I think it is worth considering whether we can do anything to make future projects robust against this mode of failure. The obvious solution is more people who get paid to work on D the language/stdlib/rt-env full-time. Where to get money to pay those individuals? Well there's no obvious solution to that (that I know of). We can say community, but, like the vision documents, they will be a bust because one can't _make_ volunteers meet deadlines, code in a particular way, or incorporate all feedback language maintainers think should be acted on.
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 10/19/21 6:54 AM, Andrey Zherikov wrote:
On Monday, 18 October 2021 at 13:16:01 UTC, Steven Schveighoffer wrote:
Prepare for some PRs, I already see ways to make this better ;)
Don't you mind sharing your ideas?
Just nitpicks. Like allowing `@NamedArgument` without parentheses. Or
using `@NamedArgument("b", "banana", "ban")` instead of
`@NamedArgument(["b", "banana", "ban"])`
All this is possible. It takes some effort on the library side, but
makes things pleasant to use.
I'll know more when I start using it.
-Steve
Re: Beta 2.098.0
On Tuesday, 19 October 2021 at 13:35:16 UTC, Timon Gehr wrote: On 11.10.21 03:08, Paul Backus wrote: Perhaps worth asking why Walter, specifically, is required to work on @live in order for it to make progress. Is it just because no one else is willing to step up to the plate, or is he the only person qualified/capable enough? I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise. I this specific case, I agree completely. But there is a broader pattern in D of projects getting "stuck" because a specific individual is unable to continue work on them (e.g., std.experimental.allocator and Andrei), and I think it is worth considering whether we can do anything to make future projects robust against this mode of failure.
Re: Beta 2.098.0
On 11.10.21 03:08, Paul Backus wrote: On Monday, 11 October 2021 at 00:34:28 UTC, Mike Parker wrote: On Sunday, 10 October 2021 at 23:36:56 UTC, surlymoor wrote: Meanwhile @live is in the language, and it's half-baked. Then there's preview switches that will linger on into perpetuity; DIPs' implementations that haven't been finished. And Walter has prioritized this issue over those. No matter what he works on, people will moan that he isn’t working on something else. Maybe we should clone him. Perhaps worth asking why Walter, specifically, is required to work on @live in order for it to make progress. Is it just because no one else is willing to step up to the plate, or is he the only person qualified/capable enough? I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise.
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?
