Release D 2.102.0
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
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 Fantastic!
Re: Release D 2.102.0
Awesome! Remember if you need any help with any of the Unicode changes, please let me know!
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: second edition of Build Web Apps in Vibe.d by learning from a learner
On Tuesday, 31 January 2023 at 07:11:06 UTC, Lars Johansson wrote: On Monday, 23 January 2023 at 01:48:11 UTC, Rey Valeza wrote: Please tell me if you ran into any problems. I am sure there are still errors I missed. Thanks! Hi sorry for the late reply. I'm busy at the moment. My attention to details is at best sloppy, it's more than likely I did something wrong. I hope to restart with your 2nd edition soon. This time I will keep you posted on my success. Great!
Re: Release D 2.102.0
On 2/2/23 10:01 AM, jmh530 wrote: 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? 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
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 2/2/23 04:30, Iain Buclaw wrote: > Glad to announce D 2.102.0, ♥ to the 40 contributors. Thanks indeed! Two issues that I had some interest in are fixed. Yay! https://issues.dlang.org/show_bug.cgi?id=17378 https://issues.dlang.org/show_bug.cgi?id=23561 I am aware how complex unicode collation is[1] but I somehow find it very wrong to list Ömer at the end. :) [...] > Steven Schveighoffer > Vladimir Panteleev > Walter Bright > Ömer Faruk IRMAK Obviously because I am used to the Turkish alphabet but in any case because Ö is very much related to O, I find it universally better to list Ö right after O. (The same should be for all latin based characters.) I see there is std.uni.icmp which uses dmd/std/internal/unicode_tables.d but it doesn't help because the array fullCaseTable in there seems to be about equivalence (e.g. of ß and ss). I think we need a "mostly correct" collation for latin based characters. I have a hacky[2] solution only for Turkish, which I used for the Index section of my book: https://bitbucket.org/acehreli/ddili/src/4c0552fe8352dfe905c9734a57d84d36ce4ed476/src/alphabet.d#lines-50 Ali [1] https://www.unicode.org/reports/tr10/ [2] The comment about the hacky treatment of 'I' in there is another example of how difficult collation is. This may not fit everybody's preference but as a result and as I desired, the entries "IDE" and "InputRange" appear under 'İ' in the index (instead of 'I'): http://ddili.org/ders/d/ix.html
Re: Release D 2.102.0
On 03/02/2023 6:22 AM, Ali Çehreli wrote: but it doesn't help because the array fullCaseTable in there seems to be about equivalence (e.g. of ß and ss). I think we need a "mostly correct" collation for latin based characters. Yeah collation is a very different beast than comparison, we can absolutely have a correct implementation its just somebody has to do it. What we have is correct (although incomplete and on my todo list to improve), but it isn't collation and won't be as its a different algorithm and tables. I.e. we are missing https://www.unicode.org/Public/UCA/15.0.0/allkeys.txt https://issues.dlang.org/show_bug.cgi?id=10566
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 17:22:46 UTC, Ali Çehreli wrote: I am aware how complex unicode collation is[1] but I somehow find it very wrong to list Ömer at the end. :) [...] > Steven Schveighoffer > Vladimir Panteleev > Walter Bright > Ömer Faruk IRMAK Obviously because I am used to the Turkish alphabet but in any case because Ö is very much related to O, I find it universally better to list Ö right after O. (The same should be for all latin based characters.) I see there is std.uni.icmp which uses dmd/std/internal/unicode_tables.d but it doesn't help because the array fullCaseTable in there seems to be about equivalence (e.g. of ß and ss). I think we need a "mostly correct" collation for latin based characters. You are more than welcome to raise a PR to fix the sort. :-) https://github.com/dlang/tools/blob/master/contributors.d#L107-L113
Re: Release D 2.102.0
On 2/2/23 10:29, jmh530 wrote: > 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. I've noticed that as well. > You might want to file a separate one for assert. I am a little hesitant after long philosophical (to me) discussions on a tangential topic. That forum discussion is linked from this bug: https://issues.dlang.org/show_bug.cgi?id=17226 The forum discussion: https://forum.dlang.org/thread/qwixdanceeupdefyq...@forum.dlang.org I still agree with myself :) in that discussion here: https://forum.dlang.org/post/tlqcjq$usk$1...@digitalmars.com And I think this code is how 17226 should be fixed as: https://forum.dlang.org/post/tldrrs$qn$1...@digitalmars.com Ali
Re: Release D 2.102.0
On Thursday, 2 February 2023 at 17:22:46 UTC, Ali Çehreli wrote: On 2/2/23 04:30, Iain Buclaw wrote: > Glad to announce D 2.102.0, ♥ to the 40 contributors. ... Two issues that I had some interest in are fixed. Yay! Ali rabboni, I think the other issue(#17226) is more important, very much! "Ali hocam, bence diğer konu daha önemli, hem de çok!" Because it can wait in line for the mighty David, who has more pressing issues. "Çünkü daha acil sorunları olan çok güçlü D için sırada bekleyebilir." Moreover, other programming languages have the same problem and non-native speakers come up with their own solutions. "Üstelik diğer programlama dillerinde de aynı sorun var ve ana dili İngilizce olmayanlar kendi çözümlerini buluyor." In summary this is not D's primary problem. "Özetle bu D'nin öncelikli sorun değildir." By the way, thank you very much for the update. This was the first update I followed from start to finish. "Bu arada, güncelleme için çok teşekkür ederim. Bu, başından sonuna kadar takip ettiğim ilk güncellemeydi." SDB@79
Re: Release D 2.102.0
On Thursday, 2 February 2023 at 12:30:50 UTC, Iain Buclaw wrote: http://dlang.org/download.html http://dlang.org/changelog/2.102.0.html -Iain on behalf of the Dlang Core Team - Stack traces can now be generated when run inside the GC collection routine. - InvalidMemoryOperationError now has a stack trace. This is awesome. And thanks for the release Iain.
