Re: D Language Foundation January 2024 Quarterly Meeting Summary
On Wednesday, 3 April 2024 at 16:25:49 UTC, Mike Parker wrote: The D Language Foundation's quarterly meeting for January, 2024 took place on Friday the 5th at 15:00 UTC. It lasted for about 45 minutes. [snip] Thanks for the write-up, as always. __Question about Ddoc__ Second, when documenting template parameters vs. regular paramters, was there a separate segment for template parameters? In the language and the code, they were distinct, but in Ddoc there was only `Params:`. Mathias said that putting them all in `Params:` handled it. Vijay asked if grouping them together was the right choice given that they were distinct in the language and the code. Mathias thought so. He said that at Sociomantic (where they had maintained their own fork of the compiler), they'd implemented `Template_Params:` at one point. He said from his experience with that, there wasn't much value in it. If we really wanted to separate them, the compiler could figure it out and we could just display them separately. But he didn't see the value in it. Átila agreed. He said that you knew the names, the names weren't going to repeat, so you could probably tell them apart. I haven't found myself needing a separate section for template parameters, but I've come across a number of bugs associated with ddoc (or ddox, I can't recall the difference) [1] and some are related to how it handles more complicated templates. [1] https://issues.dlang.org/buglist.cgi?email2=john.michael.hall%40gmail.com_to2=1=1=1=1=substring_format=advanced=---_desc=ddoc_desc_type=allwordssubstr
Re: DConf Online Livestream Link
On Sunday, 10 March 2024 at 16:07:23 UTC, Mike Parker wrote: The countdown is on! I'll kick off the DConf Online Livestream at 14:55 UTC on March 16. You can find it here: https://www.youtube.com/live/8GV_TuYk3lk And if you haven't seen the details yet, take a look here: https://dconf.org/2024/online/index.html See you there! Finally got around to start watching. On the tuple talk, Timon says on slide 32 that heterogeneous dynamic arrays don’t make much sense. I agree maybe not a completely heterogeneous one, but data frames are incredibly popular and quite similar. You could think of a data frame like a tuple composed of N-dimensional slices, but also with a slice-like interface.
Re: D Language Foundation November 2023 Monthly Meeting Summary
On Monday, 4 March 2024 at 11:19:57 UTC, Mike Parker wrote: On Monday, 4 March 2024 at 11:17:16 UTC, Sergey wrote: On Monday, 4 March 2024 at 11:07:07 UTC, Mike Parker wrote: snip Thanks for keep posting it just a bit awkward to read in March about November.. Yeah, sorry about that. I'll get caught up this month. Then I'll be back to posting them on a regular schedule. Regardless, they make for good reading. Thanks!
Re: Google Summer of Code 2024 Application Submitted
On Monday, 5 February 2024 at 13:47:21 UTC, Mike Parker wrote: I've just pressed the submit button on the GSoC 2024 application form. All we can do now is keep our fingers crossed that we're accepted this year. In the meantime, we can continue to update and refine the project ideas list: https://github.com/dlang/project-ideas So any submissions to the issues list there are welcome. I expect either Razvan or I will be updating the projects in the root directory after our monthly meeting this week. Thanks for the hard work.
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. [snip] Thanks to Martin for his hard work on LDC!
Re: Preparing for the New DIP Process
On Thursday, 25 January 2024 at 15:03:41 UTC, Max Samukha wrote:
On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis
wrote:
Of course, ultimately, different programmers have different
preferences, and none of us are going to be happy about
everything in any language.
It's not only about preferences. The feature is inconsistent
with how 'invariant' and 'synchronized' are specified. They
imply class-instance-level private, while the language dictates
module-level. Consider:
```
synchronized class C
{
private int x;
private int y;
invariant () { assert (x == y); }
}
void foo(C c)
{
// mutate c
}
```
With module-level private, 'foo' is part of C's public
interface, but it neither locks on c, nor runs the invariant
checks. I personally have no idea how to fix that sensibly
except by ditching class invariant/synchronized entirely.
Is there issue with module-private, invariant, and synchronized
solely the result of the interaction between all three? Or is
there an issue with module-private and invariant by themselves
(i.e. if C is not synchronized)?
Re: Beta 2.107.0
On Tuesday, 2 January 2024 at 12:49:51 UTC, Iain Buclaw wrote: Glad to announce the first beta for the 2.107.0 release, ♥ to the 35 contributors. This release comes with 9 major changes and 52 fixed Bugzilla issues, including: - Unrecognized pragmas are no longer an error, but instead simply ignored. - Added `@core.attribute.standalone` for shared static module constructors. - In D runtime, a new module `core.stdc.stdatomic` has been implemented. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.107.0.html As usual please report any bugs at https://issues.dlang.org -Iain on behalf of the Dlang Core Team Thanks as always. Since 2023 was a year of language stabilization and bug fixes, it might be good for someone to do a blog post on what was accomplished. Even something short and simple would be good. Also, I saw this in the change log and it might need to get revised: "If you do not care about code generation quality should the aliases to the function names not exist, you may append _impl to get at the implementation."
Re: New DUB documentation
On Monday, 27 November 2023 at 16:08:09 UTC, Mike Shah wrote: On Wednesday, 22 November 2023 at 21:35:34 UTC, WebFreak001 wrote: the revamped DUB documentation I started a while ago is now deployed on https://dub.pm [...] Just wanted to say that I appreciate the effort and improvements to the documentation. The ability to easily edit and add new examples will be incredibly useful over time. Ditto. Even where people have suggestions for further enhancements, I very much appreciate the work done here.
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 18:40:58 UTC, Adam D Ruppe wrote: [snip] But for existing libraries, I actually have a potential solution for that: made dub look at the version tag date. So, suppose dub determines it wants to use abandoned-library version 1.4. It knows version 1.4 was tagged on December 25, 2016. This could automatically go ahead and add `-edition=abandoned.library=2.092` to the build command for that lib. Notice that build command used a package specifier, if an edition is specified on the command line, it *MUST* be scoped to a specific module (or D package, just like how `-i` works) so when it is imported, the compiler can attach the edition tag there without affecting other things in the build. It would basically work like you pass `-edition=abandoned.library=2.092` on the cmd line and the compiler acts exactly the same as if you wrote `@edition(2.092)` when it sees `module abandoned library`. On the other hand, suppose dub sees a new tag, version 2.0, created in 2024. This will be edition 2.107 since it has a date range to version map. We'd have to work out the exact details, but just since dub knows the tag date it can make a pretty good automatic guess as to the proper version. To bikeshed a little, dub has the concept of `subConfigurations` that you use to pass a configuration to a dependency. This is kind of like a `subEdition` so `subEdition "abandoned.library" 2.092. Or something like that would be a bit more consistent.
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 17:57:36 UTC, Steven Schveighoffer wrote: [snip] That's not any better. If you have to opt-in to the language as it exists, people are going to quit immediately. I'm not joking about this. Imagine spending 2 hours trying to figure out why your app that is trying out some new feature doesn't compile, only to find out after posting online that it was looking at some ancient version of phobos. -Steve You are describing my first attempt to attempt to use "modern C++" features. Certainly didn't want me to learn any more C++.
Re: DLF September 2023 Planning Update
On Tuesday, 14 November 2023 at 12:55:28 UTC, Andrey Zherikov wrote: 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. Haven't seen that one, but there's certainly a lot of interest in the C++ community on language evolution. From the same conference, this one on the Carbon language is kind of in line with the work on editions https://www.youtube.com/watch?v=1ZTJ9omXOQ0 I also enjoyed Herb's discussion of language evolution at the latest CppCon https://www.youtube.com/watch?v=8U3hl8XMm8c=PLHTh1InhhwT7gQEuYznhhvAYTel0qzl72=4
Re: DLF September 2023 Monthly Meeting Summary
On Monday, 13 November 2023 at 16:09:51 UTC, Guillaume Piolat wrote: On Sunday, 12 November 2023 at 19:50:02 UTC, Mike Parker wrote: https://gist.github.com/mdparker/f28c9ae64f096cd06db6b987318cc581 Thanks for the detailed summary, I'm reading them all! Seconded, though I didn't follow all of it...
Re: implicit-context v0.0.1
On Friday, 29 September 2023 at 11:00:05 UTC, Guillaume Piolat wrote: On Friday, 29 September 2023 at 08:33:56 UTC, Imperatorn wrote: [...] Thinking about this, it's more vs TLS variable. __gshared would require synchronization. [...] Do you have an example of how this would be used in practice with allocators?
Re: reggae v0.10.0 - The meta build system just got better
On Thursday, 21 September 2023 at 15:54:26 UTC, Atila Neves wrote: [snip] Yes, and I've done that, but it's not great. I'm going to add CMake support to reggae by making CMake export its compilation DB and importing that. Interesting.
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: On Wednesday, 20 September 2023 at 15:24:52 UTC, Andrey Zherikov wrote: 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? Because we don't have one now. Using CMake for D is horrible, and none of the alternatives are that much better. 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. Want to build D and C++ [snip] You can call CMake with a pre-build command right? Would it make sense to add an example of that? It also might make sense to include in the tests/projects folder an importC example (not sure it makes sense to include a CMake example there).
Re: LDC 1.34.0-beta2
On Friday, 18 August 2023 at 13:40:54 UTC, drug007 wrote: 18.08.2023 01:32, Guillaume Piolat пишет: [...] Let me improve it a little bit (some form of procrastination) [...] Sorry, but what are you improving here?
Re: D Language Foundation July 2023 Monthly Meeting Summary
On Monday, 14 August 2023 at 12:20:50 UTC, Dom DiSc wrote: On Monday, 14 August 2023 at 08:42:17 UTC, claptrap wrote: Maybe if the compiler detects that deprecated features are being used it could add a line to the output... "To check for usage of deprecated features use the '-wo' switch" A simple 1 line "friendly reminder" instead of pages of warnings, surely people could live with that? Jup, that's a very good idea. Yup. It would be nice if the message would only appear if deprecated features are actually being used.
Re: DasBetterR
On Tuesday, 1 August 2023 at 14:00:30 UTC, bachmeier wrote: On Tuesday, 1 August 2023 at 12:37:58 UTC, jmh530 wrote: You mention creating a better interface, but recall for rstan to work you need to put the data into an R list with names that match what is in your program (your stan program could be all kinds of complicated with all kinds of different naming conventions). For it to be seamless, you would need to be able to pass a named D tuple to R easily. rstanarm might be easier to create initially, but I don't use that much. That should easy using a list, [as demonstrated here](https://github.com/bachmeil/betterr/blob/main/testing/testlist.d). [snip] Ah, ok. More to look into.
Re: DasBetterR
On Tuesday, 1 August 2023 at 12:37:58 UTC, jmh530 wrote:
[snip]
- The custom allocator requires leaving 80 bits immediately
preceding the data free for R to store its metadata related to
the vector. There's no way around that as R would not know
what to do without the metadata.
https://github.com/bachmeil/betterr/blob/main/testing/teststan.d
[snip]
I'm a little confused by this
```d
// The 80 bits R needs
foreach(ii; 0..10) { y ~= 0.0; }
```
Isn't a double 64 bits? You're putting ten doubles here. That's
like 640 bits. I would think it only needs to have padding for a
real or two doubles (if x87 isn't available).
What about something like below? I'm not sure this works for you
or not (and I'm not really an expert on how align works, there
may be a better way to do this), but the idea would be do have
make the padded slice first on the D side and then transfer that
to R (I use a real if that is 80 bits, and two doubles otherwise).
```d
struct PaddedSlice(T)
{
align (1):
static if (real.mant_dig == 64) {
private real _metadata = 0;
} else {
private double[2] _metadata = [0, 0];
}
T[] data;
alias data this;
this(T[] x) {
data = x;
}
}
```
Re: DasBetterR
On Monday, 31 July 2023 at 21:36:45 UTC, bachmeier wrote: On Friday, 7 July 2023 at 21:54:12 UTC, jmh530 wrote: Cool. The main thing I want to try is rstan. They have an interface called cmdstan that you can call from the command line that would be possible to use with D. The problem is that you have to write the data to a CSV file and then read it. So it would be kind of slow and I never got around to playing around with it in D. With your tool as it is, I would just have to copy the data in memory, which I would expect not to be as bad of an overhead as IO (but again haven't gotten around to do anything with it). I just pushed an update with a minimal example of how to call RStan with the following workflow: - Allocate a double[] in D and fill it with data. - Use a custom allocator to pass a pointer to the double[] to R. - Call RStan functions using the data. - Pull the results into D. Note that: - This is the first I've used RStan. My previous (limited) usage of Stan was at the command line. In practice, you'd want to create a better interface, so that it feels like D rather than passing strings of code around. I'm not familiar enough with RStan to do that. - The custom allocator requires leaving 80 bits immediately preceding the data free for R to store its metadata related to the vector. There's no way around that as R would not know what to do without the metadata. https://github.com/bachmeil/betterr/blob/main/testing/teststan.d Very cool. I definitely will need to play around with it. I typically save a ".stan" file with the program and then call the `stan` function with a file parameter to where it is saved (but how you did it is easier to understand for an example since everything is in this file). The `stan` function combines the `stan_model` and `sampling` functionality together. You mention creating a better interface, but recall for rstan to work you need to put the data into an R list with names that match what is in your program (your stan program could be all kinds of complicated with all kinds of different naming conventions). For it to be seamless, you would need to be able to pass a named D tuple to R easily. rstanarm might be easier to create initially, but I don't use that much. Anyway, it looks like you have done the hard work in terms of figuring out the code needed to pass a pointer to double[] from D to R. Is that something that you will incorporate into the broader project? That could be pretty useful more generally (suppose most of my analysis is in D, but then I really need one little thing from R that D doesn't have a library for).
Re: DasBetterR
On Friday, 7 July 2023 at 20:33:08 UTC, bachmeier wrote: [snip] I was wrong. They added custom allocators a while back, but didn't tell anyone. Actually, what I said before is technically correct. The SEXP struct itself still has to be allocated by R and managed by the R garbage collector. It's just that you can use a custom allocator to send a pointer to the data you've allocated, and once R is done with the data, it'll call the function you've provide to free the memory before destroying the SEXP struct that wraps it. I uploaded [an example here](https://github.com/bachmeil/betterr/blob/main/testing/testalloc.d). It's still a bit hackish because you need to adjust the pointer for a header R inserts when it allocates arrays. Adjusting by 10*double.sizeof works in this example, but "my test didn't segfault" doesn't exactly inspire confidence. Once I am comfortable with this solution, I'll do a new release of betterr. This'll be kind of a big deal if it works. For instance, if you want to use a database interface and D doesn't have one, you can use R's interface to that database without having R manage your project's memory. You could use any of the available R interfaces (databases, machine learning libraries, Qt, etc.) Cool. The main thing I want to try is rstan. They have an interface called cmdstan that you can call from the command line that would be possible to use with D. The problem is that you have to write the data to a CSV file and then read it. So it would be kind of slow and I never got around to playing around with it in D. With your tool as it is, I would just have to copy the data in memory, which I would expect not to be as bad of an overhead as IO (but again haven't gotten around to do anything with it).
Re: Evolving the D Language
On Friday, 7 July 2023 at 10:45:33 UTC, Guillaume Piolat wrote: On Friday, 7 July 2023 at 09:35:14 UTC, Paolo Invernizzi wrote: I respectfully disagree, and prefer to keep going on with the current deprecation and cleanup policy: Scott Meyers' DConf 2014 keynote all the way down. +1 I've always agreed with the deprecation in the end, even complex numbers. alias this was a relatively bad idea, even if an iconic feature. I don't remember people from outside the community being impressed by alias this. We have the right to backtrack on bad ideas instead of keeping them forever. [snip] The question is whether there is a migration path. If they removed functionality that didn't have a good foundation and put it on one with a better foundation, then I think people would have been ok (like removing Complex numbers was annoying, but std.complex exists or you can write your own). The current approach had a lot going for it. I'm sympathetic to those who favor being strict by default, but I don't feel strongly as I'm not really sure what I think about Hipreme's comment about how this all interacts with dependencies. If the new switches could turn deprecation errors into warnings or hide depreciation errors/warnings, then that might be a good complement to the revert switch (revert with a version number is also an interesting idea).
Re: DasBetterR
On Friday, 30 June 2023 at 18:47:06 UTC, bachmeier wrote: [snip] I assume you mean that you've allocated memory on the D side, like this: ``` auto a = new double[24]; a[] = 1.6; Slice!(double*, 1) s = a.sliced(); ``` and you want to pass s to R for further analysis. Unfortunately, that will not work. R functions only work with memory R has allocated. It has a single struct type, so there's no way to pass s in this example to R. Unfortunate, but understood. Looking at the implementation for Vector, the implementation of the constructor and opAssign look like it has to copy the data over anyway. [snip] As much fun as it is to figure these things out, I have never had sufficient time or motivation to do so. Yeah, that seems like it would be a bit hairy to figure out.
Re: DasBetterR
On Thursday, 29 June 2023 at 23:51:44 UTC, bachmeier wrote: [snip] Glad you're continuing to do work on this front. There's a lot of great material explaining things, which is always good. It would be cool to have another version of the link below for using a mir Slice with R. https://bachmeil.github.io/betterr/setvar.html
Re: D Language Foundation April 2023 Monthly Meeting Summary
On Monday, 15 May 2023 at 18:02:49 UTC, ryuukk_ wrote: [snip] It can be frustrating when you are are neck deep in some complicated problem to explain to people who haven't spent the same amount of time with it as you have.
Re: Beta 2.104.0
On Wednesday, 10 May 2023 at 02:48:02 UTC, anonymouse wrote: On Tuesday, 2 May 2023 at 00:34:45 UTC, Iain Buclaw wrote: Glad to announce the first beta for the 2.104.0 release, ♥ to the 36 contributors. A couple days ago I ran into an issue that was solved by https://issues.dlang.org/show_bug.cgi?id=23846 so I upgraded to this beta. I just initialized a dub project to try to use ```mir.stat``` [snip] Does it matter if instead of importing mir-stat you use mir-algorithm or std.math? mir-stat also doesn't include mac os as part of the test suite (mir-algorithm does). PRs are welcome.
Re: D Language Foundation April 2023 Quarterly Meeting Summary
On Friday, 28 April 2023 at 16:25:03 UTC, Steven Schveighoffer wrote: On 4/28/23 11:42 AM, jmh530 wrote: 2) It would be cool to have a built-in way to profile unittests by module. So for instance, the output would be how long it took the unit tests to run, broken out by module and then with a total. This is a runtime thing. You can customize it: https://dlang.org/phobos/core_runtime.html#.Runtime.extendedModuleUnitTester -Steve Cool.
Re: D Language Foundation April 2023 Quarterly Meeting Summary
On Friday, 28 April 2023 at 14:29:47 UTC, Mike Parker wrote: The D Language Foundation's second quarterly meeting for 2023 took place on April 7 at 14:00 UTC. It lasted just over an hour. This was the first "standalone" quarterly meeting, where the foundation's monthly discussion was split into a separate meeting the following week. [snip] Thanks for these, as always. He next brought up the persistent issue of slower compile times. He noted that LDC now has > a "very, very snazzy" command-line option, -ftime-trace, that outputs profiles of LDC compile times in the Chrome Trace Event format, which can then be seen as a flame graph in a viewer. [snip] Two points: 1) I feel like LDC has a lot of cool features that I'm not really sure how to use properly 2) It would be cool to have a built-in way to profile unittests by module. So for instance, the output would be how long it took the unit tests to run, broken out by module and then with a total.
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. [snip] I didn't follow this too closely last year, but I don't see a lot wrong with the "implicit with" approach (or at least I'm not sure how wrong it would be, I would lean toward adding it to a preview switch and see if it broke anything). The DIP proponents would argued against that approach seem to just be saying that the DIP is more powerful than that. Sure, that may be true, but this is also a situation where they probably shouldn't let perfect be the enemy of good. I'd rather "implicit with" than using strings and mixins to hack together the same effect for function argument lists.
Re: Release D 2.103.0
On Tuesday, 4 April 2023 at 12:01:23 UTC, Iain Buclaw wrote: On Monday, 3 April 2023 at 17:56:25 UTC, jmh530 wrote: The changelog doesn't list the fix to log1p https://github.com/dlang/phobos/pull/8712 Was there a bugzilla issue for it? Must have been missed. I think I just commented on one of the older PRs and then you fixed the problem.
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! The changelog doesn't list the fix to log1p https://github.com/dlang/phobos/pull/8712
Re: Beta 2.103.0
On Thursday, 2 March 2023 at 18:35:36 UTC, Bastiaan Veelo wrote: On Thursday, 2 March 2023 at 16:40:12 UTC, jmh530 wrote: Any reason why it doesn't match the options from DMD? See the [changelog](https://dlang.org/changelog/2.103.0.html#colors): The previous **automatic**, **on**, **off** values are still supported, but undocumented, because they are used in almost no other program like this. For consistency, with other Linux tools especially, we have implemented and switched the defaults to the widely-used **auto**, **never**, **always** values. Thanks. I must have missed that...
Re: Beta 2.103.0
On Thursday, 2 March 2023 at 16:40:12 UTC, jmh530 wrote: 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. [snip] I see some typos in the changelog (stars around what I noticed): [snip] I guess with markdown, the stars became italics
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. [snip] I see some typos in the changelog (stars around what I noticed): (Compiler changes #5) Up until this release, D had both traits(isVirtualFunction) and traits(isVirtualMethod) (and their *coressponding* traits(get...) counterpart). The *differenrcte* between the two is that isVirtualFunction returns true for final methods that do not override anything. (this sentence is listed for both library change #2 and #3) As the template constraint is not used to overload the symbol template function, the *constrains* are *move* into static asserts with expressive error messages. - In dub, the `--color` argument now accepts the values `auto`, `never`, and `always`. Any reason why it doesn't match the options from DMD? I recall some discussion about how to get the colors working on Windows, but it's been a long time and hard to find. It might be good to add something like "Here's an example on Windows 1X" to https://dlang.org/dmd-windows.html
Re: Release D 2.102.2
On Wednesday, 1 March 2023 at 18:39:45 UTC, Iain Buclaw wrote: Glad to announce D 2.102.2, ♥ to the 8 contributors. This is the last point release for 2.102 series, and the beta for 2.103 will be released shortly. http://dlang.org/download.html This point release fixes a few issues over 2.102.1, see the changelog for more details. http://dlang.org/changelog/2.102.2.html -Iain on behalf of the Dlang Core Team Thanks for the log1p fix!
Re: D Language Foundation January 2023 Quarterly Meeting Summary
On Monday, 27 February 2023 at 15:39:35 UTC, Dom Disc wrote: On Monday, 27 February 2023 at 14:27:25 UTC, bachmeier wrote: On Monday, 27 February 2023 at 10:47:04 UTC, Mike Parker wrote: Razvan [submitted a PR deprecating `alias this` in classes](https://github.com/dlang/dmd/pull/14812) the next day. Amaury [initiated a forum discussion](https://forum.dlang.org/thread/roaaoujwgkzednetb...@forum.dlang.org) a few days later. Is there a replacement? Yes. And there always was: In classes this was only an additional way to do, what should better be done with inheritance. Generally speaking, I agree, but it does add a little bit of mental overhead for a user if they want to change from struct to class. Hopefully the error message of a class alias this points users in the direction of inheriting instead.
Re: Release D 2.102.0
On Thursday, 2 February 2023 at 17:22:46 UTC, Ali Çehreli wrote: [snip] https://issues.dlang.org/show_bug.cgi?id=17378 Looks like your bug report is for assert and static assert, but the PR only handles static assert. You might want to file a separate one for assert.
Re: Release D 2.102.0
On Thursday, 2 February 2023 at 15:56:56 UTC, Steven Schveighoffer wrote: [snip] Previously, it would search in each path, and look for the files in the order of di, then d, then i, then c. So based on the order of the paths, it might find a matching C file before a matching D file in a later import path. Now, it searches all the paths for D files first, then all the paths for C files second, ensuring that it will prefer D files. The spec I don't think covers how files are searched for module definitions. The compiler command line docs have some information on what files are expected to contain, but doesn't seem to specify priorities or how they are searched. I don't know if it should be covered in the spec or the compiler docs. -Steve Thanks. The new way seems to make more sense to me.
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 Thanks. I was reading through some of the PRs referenced in [issue 23548](https://issues.dlang.org/show_bug.cgi?id=23548), and a little confused by the takeaway. It currently searches for Di, then D files. If it finds none of them, then it searches for C/h files. Is that right? Is this search order described in the spec anywhere?
Re: D Language Foundation Monthly Meeting Summary for November 2022
On Thursday, 12 January 2023 at 11:47:26 UTC, Mike Parker wrote: [snip] ### Andrei Andrei asked Razvan about the status of [the ProtoObject DIP](https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1042.md). Razvan said that Adam Ruppe had raised some valid complaints in the DIP's pull request thread, and those were reinforced in the community review. Razvan and the primary author had no answer for those complaints at the time. The primary author eventually decided to move on (I have belatedly marked the DIP as "Withdrawn"). Andrei thinks it's worth making an effort to resolve any issues the proposal has. [snip] Thanks, as always. Adam's complaints on ProtoObject start here https://github.com/dlang/DIPs/pull/219#issuecomment-954740989
Re: D Contributor Tutorials Part 1 - Building the Compiler From Source
On Sunday, 8 January 2023 at 11:27:14 UTC, Mike Parker wrote: [snip] 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. Thanks.
Re: Release D 2.101.0
On Thursday, 17 November 2022 at 07:13:38 UTC, Iain Buclaw wrote: [snip] I've just ran `rdmd -version=Contributors_Lib changed v2.100.2..v2.101.0` with my [hacked version of tools/changed.d](https://forum.dlang.org/post/jhmjyccxjxfrnboea...@forum.dlang.org), and all of a sudden I get "209 fixed Bugzilla issues" from "72 contributors". My faith in git log retrieving correct information has plummeted. :-) I'll push the fixed generated list into dlang.org, thankfully we'll never have to deal with this again (unless - queue dramatic three-beat sting - phobos is merged into dmd/druntime too). Great, thanks!
Re: Release D 2.101.0
On Thursday, 17 November 2022 at 00:25:19 UTC, Iain Buclaw wrote: On Wednesday, 16 November 2022 at 20:51:19 UTC, jmh530 wrote: Thanks again, but it doesn't look like the changelog is picking up everything. It really would help if you provide some bugzilla urls or PRs that you think should have been picked up. [snip] I'm not sure what the typically gets picked up, but I had done the search at the link below: https://github.com/dlang/dmd/pulls?q=is%3Apr+is%3Amerged+ImportC+ and it didn't look like any of the recent bug fixes were listed on the changelog (I only see 23123 and 23340). So for instance: https://github.com/dlang/dmd/pull/14528 https://github.com/dlang/dmd/pull/14509 https://github.com/dlang/dmd/pull/14508 https://github.com/dlang/dmd/pull/14490 https://github.com/dlang/dmd/pull/14485 https://github.com/dlang/dmd/pull/14481 https://github.com/dlang/dmd/pull/14480
Re: Release D 2.101.0
On Tuesday, 15 November 2022 at 20:54:03 UTC, Iain Buclaw wrote: Glad to announce D 2.101.0, ♥ to the 63 contributors. This release comes with shortened method syntax enabled by default, new bit-field support added as a preview feature, a new `std.typecons.SafeRefCounted` type that can be used in `@safe`, numerous improvements to dub (including colorized output), and many more. http://dlang.org/download.html http://dlang.org/changelog/2.101.0.html -Iain on behalf of the Dlang Core Team Thanks again, but it doesn't look like the changelog is picking up everything. Granted, I'm not sure exactly when the deadline is, but I see a whole bunch of PRs merged from Walter on ImportC on the Github repo, but only one ImportC item listed in the changelog under DMD compiler fixes (and that looks like this is actually a druntime PR). The one after that seems to be a phobos bug fix.
Re: D Language Foundation October 2022 Quarterly Meeting Summary
On Wednesday, 2 November 2022 at 04:42:06 UTC, Mike Parker wrote: The D Language Foundation's October 2022 meeting was a quarterly, meaning that several industry representatives attended. It took place via Jitsi Meet on October 7, 2022, at 14:00 UTC. The following people attended (those with DLF next to their names are either D Language Foundation board members, paid employees, or affiliated volunteers): [snip] Thanks for doing these. They are always informative and I'm sure time-consuming for you to produce. And another thanks to Martin Nowak for all the work he did over the years as release manager.
Re: D Language Foundation July 2022 Quarterly Meeting Summary
On Sunday, 28 August 2022 at 10:37:03 UTC, Mike Parker wrote: This summary is quite a bit overdue. Sorry for the delay. [...] Thanks for the detailed update.
Re: my d blog has idea of effect system to replace @nogc etc
On Monday, 15 August 2022 at 15:08:01 UTC, Adam D Ruppe wrote: [...] It's one of those things where it is better for learning a language when there are a smaller number of orthogonal features that can be built up into more complex things. @safe, pure, etc. are good, but feel a bit hackish when coming new to the language. Would require a DIP and some work in implementing it.
Re: New WIP DUB documentation
On Monday, 15 August 2022 at 21:32:23 UTC, WebFreak001 wrote: Hi all, I'm currently working on new revamped DUB documentation, check it out if you want, it currently contains most old documentation plus a big bunch of new documentation: [...] Looks go to be a big improvement. Some of the paragraphs on this page are a bit long and might need to get broken up. https://docs.webfreak.org/cli-reference/dub/
Re: importC | Using D with Raylib directly | No bindings | [video]
On Monday, 8 August 2022 at 13:01:46 UTC, Petar Kirov [ZombineDev] wrote: On Monday, 8 August 2022 at 05:39:29 UTC, Ki Rill wrote: On Sunday, 7 August 2022 at 13:53:12 UTC, Steven Schveighoffer wrote: Also, IIRC, in the latest master of DMD, there is an attempt to run the system preprocessor automatically. But I'm not sure of the state of it, or if it's in the latest release (which we are having trouble publishing still). I've read about this somewhere. It would be nice to have the preprocessor run automatically and, maybe in the future, add those #defines for the user. I think this was recently documented here: https://dlang.org/spec/importc.html#preprocessor Give it a read, try it out and let us know how it works out! It says: "Otherwise the cpp preprocessor will be used." You mean the default system cpp preprocessor, correct? I wouldn't be surprised if someone asks for the ability to set their own defaults.
Re: Giving up
On Friday, 5 August 2022 at 16:30:28 UTC, Rumbu wrote:
On Friday, 5 August 2022 at 16:08:50 UTC, Steven Schveighoffer
wrote:
Just saying, I see an integer. That's an integer according to
the language (as far back as I can test, which is 2.060
released 2012). If that was somehow parsing as a float before,
that was a bug in the parser. Since your first release is 0.9,
released Jan 2018, I find it hard to believe this ever worked
for you.
Yes, I am lying, my hidden agenda is to put D in a bad spot.
Congrats, you got me.
If you pull up run.dlang.org and run the code below with "All D
compilers" (which goes back to 2.060) you can see what the error
messages would have been. As I said above, if you remove the `.`
or the `E` then it should have run fine (the server might time
out with all compilers, but you can run it with the current
version just fine). It is entirely possible that you have a typo
in your code that is causing the issue and what you looked at
previously didn't have the typo. No hidden agenda needed.
```d
void main()
{
double x = 85886696878585969769557975866955695.E0;
}
```
Re: Giving up
On Friday, 5 August 2022 at 15:44:10 UTC, Steven Schveighoffer wrote: On 8/5/22 11:36 AM, Rumbu wrote: float z = 85886696878585969769557975866955695.E0; //integer overflow, I don't see any int That's an integer, which is trying to call a UFCS function named `E0`. Did you mean to include the `.`? -Steve Either drop the `.` or drop the `E`.
Re: DConf '22 Livestream Links
On Wednesday, 3 August 2022 at 15:52:31 UTC, matheus wrote: On Wednesday, 3 August 2022 at 09:28:29 UTC, Mike Parker wrote: On Monday, 1 August 2022 at 21:37:38 UTC, matheus wrote: On Monday, 1 August 2022 at 20:08:52 UTC, Bastiaan Veelo wrote: The first part is missing due to a late click on the “go live” button. I assume the footage is still recorded, and will be part of the edited video. — Bastiaan. Alright thanks and fingers crossed. Matheus. Yeah, sorry about that. That was a silly mistake. The recording will be fine though. It's independent of the livestream. Nice to hear this. By the way I guess you will upload all talks individually later, so when you do *please* get rid of the split screen, i.e.: https://i.imgur.com/1LeGPRd.png https://i.imgur.com/hN6YmG8.png It may seem that's nothing important for some people, but since I have vision impairment, looking small texts splitted like this is terrible and unnecessary since the slide is clearly visible on the background and could be even better if the screen was larger instead of these splits. Thanks, Matheus. I'm not visually impaired, but it's hard for me to read the slides on my laptop from the youtube videos. Nevertheless, it usually takes a while to get the individual talk videos. As Mike mentioned above, he will upload the slides at the hackathon. It usually helps me to be able to follow along with the slides while people are talking.
Re: DConf '22 Livestream Links
On Monday, 25 July 2022 at 13:52:51 UTC, Mike Parker wrote: For those of you who can't join us in person at DConf '22 in London next week, you can join us instead via each day's livestream link: [...] I'm only seeing Walter's slides on the github site [1]. Will the others be available soon? [1] https://github.com/dlang/dconf.org/blob/master/2022/online/slides/strawberries.pdf
Re: D Community Conversations: Walter Bright on the Origins of D Part 1
On Monday, 11 July 2022 at 15:33:32 UTC, Adam D Ruppe wrote: On Monday, 11 July 2022 at 13:37:10 UTC, Mike Parker wrote: The primary motivation is to trim the length of the video down. I think that's important for YouTube videos. This has changed a lot over recent years - the youtube algorithm now rewards longer length videos. It is the rise of the podcast! [snip] Many podcasts edit for the uhs and ahhs. Nothing wrong with that.
Re: D Language Foundation April Quarterly Meeting and Server Meeting Summaries
On Wednesday, 4 May 2022 at 16:21:19 UTC, Mike Parker wrote: [snip] As always, thanks for putting these together. Interesting that Ali said he should try out Visual Studio Code.
Re: Adding Modules to C in 10 Lines of Code
On Tuesday, 19 April 2022 at 12:46:16 UTC, Mike Parker wrote: [snip] Talks from past NWCPP meetups are on their YouTube channel here: https://www.youtube.com/user/NWCPP/videos I assume this one will be there, too. Thanks.
Re: Adding Modules to C in 10 Lines of Code
On Sunday, 17 April 2022 at 20:12:38 UTC, Walter Bright wrote: https://nwcpp.org/ An online presentation. Monday at 7PM PST. Will there be a recording available?
Re: Google Summer of Code -- An Apology
On Monday, 7 March 2022 at 07:25:54 UTC, bauss wrote: Don't worry about it, it's only human to forget things. It's impossible to remember everything, if you're already booked up with a lot of other stuff that has to be done. Agreed.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On Wednesday, 9 February 2022 at 16:21:24 UTC, Paul Backus wrote: [snip] In D, there is no existing word for this, so from that perspective both "mustuse" and "nodiscard" are equally valid. In other languages, there are multiple existing words: - C++17: [[nodiscard]] - C (gcc/clang): __attribute__((warn_unused_result)) - Rust: #[must_use] If you are used to C++, then you will find "nodiscard" natural, and "mustuse" will require you to learn a new word. If you are used to Rust, then you will find "mustuse" natural, and "nodiscard" would have required you to learn a new word. But what color should the bike shed be? ;)
Re: fixedstring: a @safe, @nogc string type
On Monday, 10 January 2022 at 12:55:28 UTC, Moth wrote: hi all. i got fed up with the built-in string type having so many features unavailable in `@nogc` code, so i made my own. introducing fixedstring: a templated fixed-length array of `char`s, compatible with `@safe`, `@nogc`, and `nothrow` code. licenced under the AGPL-3.0 or later, but i'm open to relicensing if someone really really wants it. have fun =] https://github.com/Moth-Tolias/fixedstring [snip] You might add some examples to the Readme.md
Re: DMD now incorporates a disassembler
On Friday, 7 January 2022 at 21:41:55 UTC, Walter Bright wrote: Compile with -vasm to see it! Enjoy! [snip] Would make a nice project for someone to integrate this into run.dlang.org
Re: DConf Online 2021 Q & A Videos
On Sunday, 5 December 2021 at 11:01:05 UTC, Mike Parker wrote: [snip] I'll likely be working on this for the remainder of this month. I'll try to get them out every three or four days, and I'll continue to update this thread with the new links. Stefan's Q & A session is next. Thanks for putting in the effort. Better to watch the edited ones.
Re: Release 2.098.0
On Sunday, 10 October 2021 at 14:10:53 UTC, Martin Nowak wrote: Glad to announce D 2.098.0, ♥ to the 62 contributors. This release comes with template alias assignments, ImportC, a forking parallel GC for POSIX systems, and many more changes. http://dlang.org/download.html http://dlang.org/changelog/2.098.0.html -Martin Thanks for everyone's work.
Re: mir.complex
On Monday, 30 August 2021 at 13:26:09 UTC, Per Nordlöw wrote: [snip] Why wasn't fixing the linking bugs considered an alternative to forking std.complex? What are the other remaining reasons for not using std.complex? It doesn't look like any bug reports were filed. Hopefully that can happen...
Re: SAOC 2021 Projects Summarized
On Monday, 30 August 2021 at 12:47:11 UTC, Mike Parker wrote: Five projects have been selected for SAOC 2021. I've summarized them on the blog. [snip] Looks like a good set of projects. Good luck to them.
Re: Beta 2.097.0
On Thursday, 13 May 2021 at 13:29:55 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.097.0 release, ♥ to the 54 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.097.0.html As usual please report any bugs at https://issues.dlang.org -Martin "11. Floating point numbers don't allocate with the GC anymore." Should this be "11. Formatting floating point numbers doesn't allocate with the GC anymore."
Re: LDC 1.26.0-beta1
On Saturday, 10 April 2021 at 20:50:08 UTC, kinke wrote: [snip] Please help test, and thanks to all contributors & sponsors! ldc-beta is passing tests I have for enabling dependencies in unittests in run.dlang.org [1]. Will be happy to get this in when the next release is live (the only reason ldc was failing was because the code requires the latest dub and installing a separate dub in a dockerfile was not trivial). [1] https://github.com/dlang-tour/core-exec/pull/56
Re: Please Congratulate My New Assistant
On Monday, 25 January 2021 at 21:25:28 UTC, H. S. Teoh wrote: [snip] I think we're looking at this in the wrong way. [snip] AKA https://en.wikipedia.org/wiki/Goodhart%27s_law
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Tuesday, 12 January 2021 at 20:04:00 UTC, Paul Backus wrote: On Tuesday, 12 January 2021 at 19:49:10 UTC, jmh530 wrote: I'd rather put the import at the top of the file, or in a version(unittest) block than that. The problem with those approaches is that if you have an example unittest, then when a user tries to run it then they have to put the import in themselves. Seems like the obvious solution is to put the import inside the unittest. I mean, I'm not chomping at the bit for it, or this DIP. If things stay as they are, then I'll keep doing what I'm doing.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Tuesday, 12 January 2021 at 19:27:31 UTC, Petar Kirov [ZombineDev] wrote: [snip] To play the devil's advocate, it shouldn't be hard to change the compiler config file to auto-import any module of your choice (it config file would simply append it to the compiler command line). [snip] That sounds a bit like magic, in the Arthur C. Clarke sense. Would that work in a project that other people are working on? (i.e., do they have to modify their compiler config files too?). I'd rather put the import at the top of the file, or in a version(unittest) block than that. The problem with those approaches is that if you have an example unittest, then when a user tries to run it then they have to put the import in themselves.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Tuesday, 12 January 2021 at 17:27:50 UTC, Q. Schroll wrote: On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote: On Monday, 11 January 2021 at 14:42:57 UTC, Nick Treleaven wrote: [snip] Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto var =` with it as normal. Gotcha. I think I would use that more than the current DIP (though I prefer [1]s to [1]$). You can do it today if you don't mind putting the marker in front: https://run.dlang.io/is/E6ne4k (Its operator abuse. What would you expect?) Interesting approach! However, it doesn't really resolve my underlying issue, which was that I would still need to import that s struct.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Monday, 11 January 2021 at 21:33:36 UTC, Paul Backus wrote:
On Monday, 11 January 2021 at 21:17:20 UTC, jmh530 wrote:
Of course, the typical response would be, "well why not use
alias s = static array". I would ask what about an @nogc
unittest where the author is trying to limit calls to
functions that aren't really central to what is being tested.
I've used std.array.staticArray for @nogc unit tests. It works
fine, and the fact that it has a descriptive name makes it a
lot more readable than something like `[1, 2, 3]s`.
I know it can be used. My main point was "where the author is
trying to limit calls to functions that aren't really central to
what is being tested".
Consider
@nogc unittest
{
assert([1, 2]s.nogcFunction == value);
}
vs
@nogc unittest
{
import std.array: staticArray;
assert([1, 2].staticArray.nogcFunction == value);
}
Not really different enough for me to care all that much, but the
first one avoids the import and is a bit simpler.
I didn't really feel that strongly about the DIP. My comment was
more that if that literal syntax were adopted, I would use it.
There's a lot of literals that I rarely make use of and have to
look up what it is. If I see 1.05L, I'm like "how could that be a
long?" Until I look it up and find out it's a real literal.
However, I imagine that people out there do make use of these
things (maybe not for reals so much, given the hate a lot of
people give them, but other ones).
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Monday, 11 January 2021 at 14:42:57 UTC, Nick Treleaven wrote: [snip] Just a suffix like `[1,2]$` or `[1]s`. Then just use `auto var =` with it as normal. Gotcha. I think I would use that more than the current DIP (though I prefer [1]s to [1]$). Of course, the typical response would be, "well why not use alias s = static array". I would ask what about an @nogc unittest where the author is trying to limit calls to functions that aren't really central to what is being tested. The next best alternative is something like `enum immutable x = [1];` and then using `x`. Building that static array literal functionality into the compiler would be useful in that case.
Re: Release D 2.095.0
On Monday, 11 January 2021 at 13:42:42 UTC, Mike Parker wrote: [snip] Blog Post (including LDC beta news): https://dlang.org/blog/2021/01/11/a-new-year-a-new-release-of-d/ Reddit: https://www.reddit.com/r/programming/comments/kv2ug5/dlang_20950_released/ typo on facilitate in line below "For a little while now, DMD has included experimental support for the generation of C++ header files from D source code, via the -CH command-line option, in order to facilate calling D libraries from C++." Otherwise looks good, though it might have been good to provide an example of the template QoL improvement.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Monday, 11 January 2021 at 12:32:42 UTC, Nick Treleaven wrote: [snip] I think if the DIP proposed a literal syntax instead of a new variable declaration syntax, it would be much less of a burden to the compiler. I think we don't have any partial (variable) type inference syntax ATM. [snip] Could you provide an example? (apologies if you already have...)
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 19:17:46 UTC, Luhrel wrote: [snip] Still doesn't work with `short`. Pretty sure my version above does.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 18:34:31 UTC, Nick Treleaven
wrote:
On Wednesday, 6 January 2021 at 18:29:05 UTC, Nick Treleaven
wrote:
Can be fixed (probably with another name):
//import std.array;
Actually template overloading seems to work fine:
template staticArray(T) {
T[n] staticArray(ulong n) (auto ref T[n] a) {return a;}
}
T[n] staticArray(T, ulong n) (auto ref T[n] a) {return a;}
void main(){
auto a = [1,2,3].staticArray!float;
pragma(msg, typeof(a)); // float[3]
a.writeln();
[1,2,3].staticArray.writeln();
}
What about something like below to handle any user-defined type.
import std.stdio: writeln;
template staticArray(T) {
T[n] staticArray(ulong n) (auto ref T[n] a) {return a;}
T[n] staticArray(U, ulong n) (auto ref U[n] a)
if (!is(T == U))
{
T[n] output;
for(size_t i = 0; i < n; i++) {
output[i] = cast(T) a[i];
}
return output;
}
}
T[n] staticArray(T, ulong n) (auto ref T[n] a) {return a;}
struct Foo {
float x;
T opCast(T)() {
return cast(T) x;
}
}
void main(){
auto a = [1,2,3].staticArray!float;
pragma(msg, typeof(a)); // float[3]
a.writeln();
[1,2,3].staticArray.writeln();
auto b = [1,2,3].staticArray!Foo;
b.writeln();
}
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 21:07:49 UTC, welkam wrote: [snip] P.s. Thank you for a well written post with a link to useful read. Thanks for reading it.
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 17:24:42 UTC, John Colvin wrote:
On Monday, 4 January 2021 at 17:22:55 UTC, John Colvin wrote:
On Monday, 4 January 2021 at 13:47:17 UTC, Ola Fosheim Grøstad
wrote:
[...]
I have a longer reply I'm trying to write, but just to make
sure I'm on the right track:
template Foo(T) {
alias Foo = T;
}
template Q(A : Foo!T, T) {
pragma(msg, A.stringof, " ", T.stringof);
}
alias X = Q!(Foo!int);
in your opinion, this should compile and msg `int int`, yes?
I'm trying to make a really concise example without using IFTI.
and presumably the same for
alias X = Q!(int);
yes?
Would this also imply:
enum bool Bar(A) = is(A : Foo!T, T);
void main() {
static assert(Bar!(Foo!int));
static assert(Bar!(int));
}
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 15:31:02 UTC, ag0aep6g wrote:
On 04.01.21 16:03, jmh530 wrote:
IMO, this is a better example, even if it's a little more
verbose.
struct Foo(T) {}
alias Bar(T) = Foo!T;
void f(T)(Bar!T x) {}
void main() {
auto x = Bar!int();
f(x);
}
To be sure that I'm not missing anything: You just added the
temporary `x`, right? I don't think that changes anything. The
type of the argument is `Foo!int` in all variations of the code
we've seen, including this one. And that type is all that DMD
sees when it attempts IFTI of `f`.
Ah, I see your point above now (mixing up my Bar!ints and
Bar!Ts). Yes, that was the only change and not really a
substantive change (just my ease of reading).
Your point is basically that a template alias only becomes an
actual alias when it has been instantiated. You then note that
the deduction process operates in terms of Bar (in that you have
to find a T that fits Bar!T to get to an alias of Foo!T). I think
part of what is confusing is that the temporary x in my example
is a Foo!int and not a Bar!int, which is why the Foo!int can't be
passed into f(T)(Bar!T).
I think part of the issue is that many people's mental model
would be for f(T)(Bar!T) to get re-writtn as f(T)(Foo!T), which
is related to Ola's point with respect to type unification.
But the compiler isn't really doing any re-writing, so much as it
sees the Foo!int and does not have the information necessary to
determine that a Foo!int should satisfy Bar!T (as you point out).
It would need to extract int from Foo!int, then instantiate Bar!T
to get Foo!int (which I believe is what the implementation was
doing, or something similar).
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 14:40:31 UTC, ag0aep6g wrote:
On 04.01.21 15:37, Ola Fosheim Grøstad wrote:
On Monday, 4 January 2021 at 14:11:28 UTC, ag0aep6g wrote:
`Bar!int` is an alias. It's indistinguishable from `Foo!int`.
The code fails in the same manner when you replace "Bar!int"
with "Foo!int".
Wrong. This succeeds:
struct Foo(T) {}
alias Bar(T) = Foo!T;
void f(T)(Foo!T x) {}
void main() {
f(Bar!int());
}
You didn't replace "Bar!int" with "Foo!int". You replaced
"Bar!T" with "Foo!T". That's something else entirely.
IMO, this is a better example, even if it's a little more verbose.
struct Foo(T) {}
alias Bar(T) = Foo!T;
void f(T)(Bar!T x) {}
void main() {
auto x = Bar!int();
f(x);
}
Re: Printing shortest decimal form of floating point number with Mir
On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote: [snip] The way I saw it the whole argumentation for a language change went like this: 9il: This would be helpful for my lib Atila: Im not convinced this is good addition to the language Thats it. No more good arguments came later. If proposal has only this kind of argument then ofcourse it will be rejected. Even if the idea is good. You should put yourself in the boots of Atila. If you accept a change that later turns out to be bad idea you cant just take it out. We all would have to be with it for 10 or more years. So to avoid situation that I described a proposal needs to have solid argumentation and cost/benefit ratio needs to be clear to make good decision. What happened was more that Atila said why not use template constraints and Ilya replied it makes things overly complicated and Atila responded about a workaround existing and he didn't see why to add. Obviously, if Atila or Walter is not in favor of something, it's usually better to know that sooner rather than later. However, it is a bit unfortunate that this never made its way farther through the DIP process. There was a first round review, but I think it was postponed before formal assessment. And for the end I want to point out that your proposal is not in the same category as ast macros. If you or some one else comes up with solid arguments then the outcome might be different. As for me. Im do not know ins and outs of templates to make a judgment if your proposal is good or not. No one showed how it would benefit the code I write. If you aren't writing templates, then it wouldn't affect you. However, it was deemed beneficial enough that a form of it was added to C++ as part of C++ 11 (was news to me as I rarely write C++). The paper on it is here [1], though it doesn't really get into the benefits of it. I'm sure there is a lot of C++ 11 and later code out there that uses the C++11 version of the idea. Nevertheless, there are some differences between the C++11 template aliases and these. C++11 adds the using syntax in addition to the typedef syntax. D already has the alias syntax, which is like using. The difference is that D's template alias syntax works when defining variables. It only doesn't work the same with type deduction in functions. In addition, one reason the DIP was postponed because it really had only addressed the short form template alias, not the long form. However, the C++ version only seems to support the equivalent of the short form. Regardless, the DIP likely could have been improved by mentioning its inclusion in C++ 11 (and perhaps focused a bit less on implementation). I wonder if the inability to do this would inhibit the ability of D code to interact with C++ code bases. For instance, what if you have a C++ function that takes a template alias and try to call it in D. Would you have to write out the target of the alias to get it to work? This kind of thing could be important. You wouldn't be able to use the same template aliases in D the way you use them in C++. If the DIP remained focused on C++ compatibility (if that is an actual issue), then it would only need to support the short form syntax (though that may raise questions as to why not support both). [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1489.pdf
Re: Release D 2.095.0
On Saturday, 2 January 2021 at 20:15:16 UTC, Martin Nowak wrote: Glad to announce D 2.095.0, ♥ to the 61 contributors. This release comes with a much improved C++ header generation, template instantiation traces for deprecations, module-level function conflict detection, and better compiler flag support in dub. http://dlang.org/download.html http://dlang.org/changelog/2.095.0.html -Martin Thanks. I'm excited to test out some of the dub changes when I have a chance. I'd like to repeat a previous ask: that the change log mention the dub version somewhere. Thanks.
Re: Release Candidate [was: Re: Beta 2.095.0]
On Wednesday, 30 December 2020 at 10:51:38 UTC, Martin Nowak wrote: On Sunday, 20 December 2020 at 13:21:46 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.095.0 release, ♥ to the 61 contributors. The release candidate for 2.095.0 is live now. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.095.0.html As usual please report any bugs at https://issues.dlang.org -Martin When I look at dub's commits, I see a recent commit to tag version 1.24.0-rc1. It might be useful to mention the latest version of dub somewhere in the change log as well, at least to the extent that the dub releases will be coinciding with the DMD ones.
Re: Printing shortest decimal form of floating point number with Mir
On Thursday, 24 December 2020 at 09:56:50 UTC, Ola Fosheim
Grøstad wrote:
[snip]
I don't use concepts yet as it is a very new C++ feature. The
following code does not work in XCode, although it probably
should according to cppreference. So take this with a grain of
salt (other variations should be possible):
namespace detail {
template typename F, class U>
constexpr void _is_instantiable(F a){}
}
template
struct Foo{};
template
concept Fooish = requires(T a){
detail::_is_instantiable(a);
};
That Foo-ish reminds me of something in D like
static if (__traits(compiles, {
auto temp = Foo!T.init;
}))
Re: Printing shortest decimal form of floating point number with Mir
On Wednesday, 23 December 2020 at 16:25:58 UTC, 9il wrote:
[snip]
1.
Alias template function parameter resolution
https://github.com/dlang/dmd/pull/9778
[snip]
I gave some thought to potential alternatives, but this is really
the simplest way to think about it.
For instance, I would imagine that something like below would be
expected to compile if this is ever resolved.
struct Foo(T) {}
alias Bar(T) = Foo!T;
void f(T)(Foo!T x) {}
void b(T)(Bar!T x) {}
void main() {
auto foo = Foo!int();
auto bar = Bar!int();
foo.f;
foo.b;
bar.f;
bar.b;
}
If you instead use template constraints, then you have to rely on
helper functions for anything more complicated and you are no
longer following DRY. For instance, a function like
enum bool isBar(T) = is(T == Foo!U, U);
void fb(T)(T x) if(isBar!T) {}
will compile (adjusting the calls above), but you are repeating
Foo!U.
Because of the bugs mentioned in other posts, replacing isBar
with below will not.
enum bool isBar(T) = is(T == Bar!U, U);
Given the similarities between template constraints and concepts,
something like below could accomplish something similar
concept Bar(T) = is(T == Foo!U, U);
but that doesn't help you if you want to also be able to use the
template alias, as in
auto bar = Bar!int();
This is because Bar(T) in the concept should be passing a Foo!T.
You would still need to have the alias for Bar if you want that
functionality (and how to name them when they are doing similar
things). Abusing C++'s syntax you might have something like
concept Bar(T) = requires(U)() {
Foo!U; //akin to something like typename T::Foo;
}
where we would basically be telling the compiler that T has to be
a Foo!U, which would mean you would have to use Bar like
Bar!U...at least that's the idea. I don't think anything like
this would work currently in C++.
It's useful to contrast this with implicit conversion. For
instance, if instead Bar is something like
struct Baz(T)
{
Foo!T payload
alias payload this;
}
but then you can no longer have foo get passed to the b function
(suitably adjusted). So implicit conversion isn't the solution.
However, it is interesting. The problem is that Baz is a separate
type. Even if it's implicitly convertible to Foo, a Foo isn't
convertible to it (every Baz is a Foo but no Foos are Baz's). By
contrast, the template alias Bar is still a Foo (every Bar is a
Foo and some but not all Foos are Bars). So it can be thought of
as a constrained version of Foo, though in this case there are no
constraints listed. That's where the similarity with C++ concepts
come in.
Re: Truly algebraic Variant and Nullable
On Tuesday, 22 December 2020 at 17:20:03 UTC, ag0aep6g wrote:
On Tuesday, 22 December 2020 at 16:53:11 UTC, jmh530 wrote:
For
v = cast(size_t) x;
I thought @safe prevented explicitly casting an immutable to a
mutable, but the code below seems to suggest it is ok in this
case...
void main() @safe
{
immutable x = 32;
auto v = cast(size_t) x;
}
It's ok because you're making a copy. Casting from immutable to
mutable is only dangerous when altering the mutable thing would
affect the immutable thing, as it happens with pointers and
such.
Ah, I get the error when I keep v as a pointer (or replace x with
a cast). I had tried below and didn't have errors, but if you
change the cast to cast(size_t*) then you get the error. Thanks
for that.
void main() @safe
{
immutable int* x = new int(32);
auto v = cast(size_t) x;
v++;
}
Re: Truly algebraic Variant and Nullable
On Tuesday, 22 December 2020 at 14:27:02 UTC, ag0aep6g wrote:
On 22.12.20 04:56, 9il wrote:
6. Algebraic type subsets are supported by `get`,
`trustedGet`, `_is`, and `this` primitives. You can operate
with algebraic subset as with the type of the original
typeset. [1]
"trustedGet" - That name smells of a safety violation. And
indeed (compile with `-release`):
import mir.algebraic;
import std.stdio;
void main() @safe
{
immutable int* x = new int(42);
Variant!(size_t, int*) v;
v = cast(size_t) x;
auto p = v.trustedGet!(int*); /* uh-oh */
*p = 13; /* mutating immutable */
writeln(*x); /* prints "13" */
}
[snip]
For
v = cast(size_t) x;
I thought @safe prevented explicitly casting an immutable to a
mutable, but the code below seems to suggest it is ok in this
case...
void main() @safe
{
immutable x = 32;
auto v = cast(size_t) x;
}
Re: Truly algebraic Variant and Nullable
On Thursday, 17 December 2020 at 15:12:12 UTC, 9il wrote: On Wednesday, 16 December 2020 at 16:14:08 UTC, jmh530 wrote: On Wednesday, 16 December 2020 at 15:58:21 UTC, 9il wrote: [snip] Thanks! Maybe, but mir-core is quite small itself and mir.algebraic is the only part that would be extended or updated in the near future. Other parts are quite stable. If there would be a strong reason to split it, we can do it. What about making it into a sub-package, as in here [1]? [1] https://github.com/atilaneves/unit-threaded/tree/master/subpackages It takes 0.1 seconds to compile mir-core with LDC in the release mode. It is almost all generic and quite fast to compile. We can, but dub doesn't always work well with submodules. Is there any other reason except compilation speed? You can put it on code.dlang.org as a subPackage and people can download it without downloading all of mir-core. See below: https://code.dlang.org/packages/unit-threaded
Re: Truly algebraic Variant and Nullable
On Wednesday, 16 December 2020 at 15:58:21 UTC, 9il wrote: [snip] Thanks! Maybe, but mir-core is quite small itself and mir.algebraic is the only part that would be extended or updated in the near future. Other parts are quite stable. If there would be a strong reason to split it, we can do it. What about making it into a sub-package, as in here [1]? [1] https://github.com/atilaneves/unit-threaded/tree/master/subpackages
Re: Mir vs. Numpy: Reworked!
On Thursday, 10 December 2020 at 11:07:06 UTC, Igor Shirkalin wrote: On Monday, 7 December 2020 at 13:17:47 UTC, jmh530 wrote: "no need to calculate inverse matrix" What? Since when? Since when highly optimized algorithms are required. This does not mean that you should not know the algorithms for calculating the inverse matrix. I still find myself inverting large matrices from time to time. Maybe there are ways to reduce the number of times I do it, but it still needs to get done for some types of problems.
Re: Mir vs. Numpy: Reworked!
On Monday, 7 December 2020 at 13:41:17 UTC, Ola Fosheim Grostad wrote: On Monday, 7 December 2020 at 13:17:47 UTC, jmh530 wrote: [snip] "no need to calculate inverse matrix" What? Since when? I dont know what he meant in this context, but a common technique in computer graphics is to build the inverse as as you apply computations. Ah, well if you have a small matrix, then it's not so hard to calculate the inverse anyway.
Re: Mir vs. Numpy: Reworked!
On Monday, 7 December 2020 at 11:21:16 UTC, Igor Shirkalin wrote: [snip] Agreed. As a matter of fact the simplest convolutions of tensors are out of date. It is like there's no need to calculate inverse matrix. Mir is the usefull work for author, of course, and practically almost not used. Every one who needs something fast in his own tasks should make same things again in D. "no need to calculate inverse matrix" What? Since when?
Re: Mir vs. Numpy: Reworked!
On Friday, 4 December 2020 at 20:26:17 UTC, data pulverizer wrote: [snip] I see, looking at some of the code, field case is literally doing the indexing calculation right there. I guess ndslice is doing the same thing just with "Mir magic" an in the background? Still, ndslice is able to get a consistent higher rate of flops than the field case - interesting. One thing I discovered about these kinds of plots is that introducing log scale or two particularly for timed comparisons can make the differences between different methods that look close clearer. A log plot might show some consistent difference between the timings of ndslice and the field case. Underneath they should be doing essentially the same thing so teasing out what is causing the difference would be interesting. Is Mir doing some more efficient form of the indexing calculation than naked field calculations? I'm still not sure why slice is so slow. Doesn't that completely rely on the opSlice implementations? The choice of indexing method and underlying data structure? Isn't it just a symbolic interface that you write whatever you want? Ilya might have a better ability to answer that than me.
Re: Mir vs. Numpy: Reworked!
On Friday, 4 December 2020 at 02:35:49 UTC, data pulverizer wrote: [snip] NDSlice is even faster for this case - cool. Am I correct in assuming that the data in the NDSlice is also a single array? It looks like all the `sweep_XXX` functions are only defined for contiguous slices, as that would be the default if define a Slice!(T, N). How the functions access the data is a big difference. If you compare the `sweep_field` version with the `sweep_naive` version, the `sweep_field` function is able to access through one index, whereas the `sweep_naive` function has to use two in the 2d version and 3 in the 3d version. Also, the main difference in the NDSlice version is that it uses *built-in* MIR functionality, like how `sweep_ndslice` uses the `each` function from MIR, whereas `sweep_field` uses a for loop. I think this is partially to show that the built-in MIR functionality is as fast as if you tried to do it with a for loop yourself.
Re: Mir vs. Numpy: Reworked!
On Thursday, 3 December 2020 at 20:25:11 UTC, data pulverizer wrote: [snip] Very interesting work. What is the difference between Mir's field, slice, native and ndslice? [...] The document says: Slice: Python like. Uses D Slices and Strides for grouping (Red-Black). Naive: one for-loop for each dimension. Matrix-Access via multi-dimensional Array. Field: one for-loop. Matrix is flattened. Access via flattened index. NdSlice: D like. Uses just MIR functionalities.
Re: Mir vs. Numpy: Reworked!
On Thursday, 3 December 2020 at 16:27:59 UTC, 9il wrote: Hi all, Since the first announcement [0] the original benchmark [1] has been boosted [2] with Mir-like implementations. D+Mir: 1. is more abstract than NumPy 2. requires less code for multidimensional algorithms 3. doesn't require indexing 4. uses recursion across dimensions 5. a few times faster than NumPy for non-trivial real-world applications. Why Mir is faster than NumPy? 1. Mir allows the compiler to generate specialized kernels while NumPy constraints a user to write code that needs to access memory twice or more times. Another Mir killer feature is the ability to write generalized N-dimensional implementations, while Numpy code needs to have separate implementations for 1D, 2D, and 3D cases. For example, the main D loop in the benchmark can compile for 4D, 5D, and higher dimensional optimizations. 2. @nogc iteration loop. @nogc helps when you need to control what is going on with your memory allocations in the critical code part. [0] https://forum.dlang.org/post/pemharpztorlqkxdo...@forum.dlang.org [1] https://github.com/typohnebild/numpy-vs-mir [2] https://github.com/typohnebild/numpy-vs-mir/pull/1 The benchmark [1] has been created by Christoph Alt and Tobias Schmidt. Kind regards, Ilya Looks good, but a few typos: "The big difference is especially visible in this figures." "For bigger prolem sizes the FLOP/s slightly drop and finally level out." "Propably this is mainly caused by the overhead of the Python interpreter and might be reduced by more optimization efforts."
Re: MIR vs. Numpy
On Wednesday, 18 November 2020 at 15:20:19 UTC, 9il wrote: [snip] -O is added by DUB Ah, the -release-nobounds
Re: MIR vs. Numpy
On Wednesday, 18 November 2020 at 10:05:06 UTC, Tobias Schmidt wrote: Dear all, to compare MIR and Numpy in the HPC context, we implemented a multigrid solver in Python using Numpy and in D using Mir and perforemd some benchmarks with them. You can find our code and results here: https://github.com/typohnebild/numpy-vs-mir Feedback is very welcome. Please feel free to open issues, pull requests or simply post your thoughts below. Kind regards, Tobias Very nice write up. It's been a while since I've used numba, so I was a little confused on the numba 1 and numba 8 runs. It also looks like you are compiling on ldc with -mcpu=native --boundscheck=off. Why not -O as well?
Re: sumtype 1.0.0
On Tuesday, 17 November 2020 at 22:14:04 UTC, aliak wrote: [snip] Alright!! A 1.0.0 release! Awesome work here! Agreed.
