From schveiguy at gmail.com Sat Jul 2 19:52:28 2022 From: schveiguy at gmail.com (Steven Schveighoffer) Date: Sat, 2 Jul 2022 15:52:28 -0400 Subject: Beerconf July 2022 Message-ID: # BEERCONF! So this month is going to be a bit different. We are going to have beerconf *early*! It's like early Christmas, but with beer instead of presents! The reason for the early date is that the normal end-of-the-month date would be just before real dconf (literally one day before). While this might be a nice time to get together, some of the usual participants are likely going to be dealing with travel for dconf, or dconf itself. The dates this month are going to be July 16-17 (in 2 weeks). Why that and not the 23-24? Because [100% of the vote](https://forum.dlang.org/post/vmcjcprpzqyaimmabwxe at forum.dlang.org) was for this date. In any case, we will be getting together to talk D shop, and other stuff, as usual. As always here is the plug for the T shirt: https://www.zazzle.com/store/dlang_swag/products?cg=196874696466206954 ## What is beerconf? Check out the [wiki article](https://wiki.dlang.org/Beerconf). ## Presentations? Anyone who wants to reserve some time to show off any D projects or talks they want to send me an email, or ping me on discord or slack. Cheers! ? -Steve From aldacron at gmail.com Sun Jul 3 08:46:31 2022 From: aldacron at gmail.com (Mike Parker) Date: Sun, 03 Jul 2022 08:46:31 +0000 Subject: The D Programming Language Vision Document Message-ID: You can find the final draft of the high-level goals for the D programming language at the following link: https://github.com/dlang/vision-document I'll fill out the remaining sections as time allows over the coming weeks. Once it's complete, I'll make sure it's linked in the Community section of the menu bar. I want to emphasize that what we have there right now are a list of high-level goals. Please read my summary of our June meeting for more info on the motivation behind it. https://forum.dlang.org/thread/buythmwbdaswuqbtkddv at forum.dlang.org Some of these goals we want to actively pursue, others are things we'll take advantage of when the opportunity arises. For example, completing the memory safety story is an active project, but looking for features to remove, or to put on the "no recommended list" is something we'll evaluate when it comes up. Improving the ecosystem is a major goal. Right now, we don't have the resources in place to make that happen, but we expect to be there next year once we have an ecosystem management team in place. In the meantime, if you have an idea for a new tool or project that fits into our goals, and you don't want to start working on it until you know it's going have the foundation's approval or support, then please let me know. Hash out ideas of the project in the forums or on Discord if you need to, but we'll want you to bring a proposal to one of our monthly meetings for discussion. Then you'll know if it's worth your time. Just be aware that we do not have the resources to oversee things right now to the extent we would like, so anyone looking to make this kind of contribution should be self-motivated and independent. We'll support you as much as we can, and we may even be willing to pay out a contract in some cases, but for now you're largely going to be on your own. I also want to reiterate that this is a living document. We will modify the goals as needed as time goes by. Feedback is welcome. From ola.fosheim.grostad at gmail.com Sun Jul 3 11:13:42 2022 From: ola.fosheim.grostad at gmail.com (Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=) Date: Sun, 03 Jul 2022 11:13:42 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: > Feedback is welcome. Thank you for putting this in clear terms. I miss an overarching ?primary use scenarios? to guide further language evolution. How do you know if new language features are good or bad if you have no scenarios to measure them up against? It is nice to see that improved move semantics is a goal, then I guess ARC could be something one could envision down the line. That said, I am a bit disappointed that there is no hint of a departure from the current STOP-the-world GC regime, but I guess that is the reflecting reality. My interpretation of the vision document is that the core team sees no need to change the current GC strategy. From anonymous at example.com Sun Jul 3 11:25:38 2022 From: anonymous at example.com (ag0aep6g) Date: Sun, 3 Jul 2022 13:25:38 +0200 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On 03.07.22 10:46, Mike Parker wrote: > You can find the final draft of the high-level goals for the D > programming language at the following link: > > https://github.com/dlang/vision-document Quoting from the "Memory safety" section: > The language maintainers do not see memory safety as a fad, nor is their focus on its implementation in the D programming language a form of "chasing" other languages. There's no need to be so defensive, particularly in the first sentence of the section. Also, the "chasing" part is cryptic. What other languages are you talking about? Why can their names not be uttered? I know it's Rust, but other readers might not. Just ax that sentence and start with "The language maintainers see memory safety as a critical component [...]". > DIP 1000 is crucial to this because it eliminates most of the reasons why D code written as simply as possible is not @safe. Dubious claim. My experience is that people who try `scope` quickly run into its limitations. > Eliminate undefined behavior in @safe code. I.e., fix bugs. That's hardly worth mentioning as a high-level goal. > it's not possible to write a vector type where the following code is @safe. > > auto v = vector(1, 2, 3); > v ~= 4; That example isn't clear at all. I suppose the point is to (1) avoid the GC and (2) still allow taking the addresses of the elements. That isn't obvious from those two lines of code, at all. As presented, `vector` can easily be implemented @safe-ly with a dynamic array. > Even as we strive to increase memory safety in D, we must always ensure that programmers who need or want to eschew memory safety features can do so. And they must be able to do so with minimal friction. "Minimal friction" would mean not making @safe default, as that adds friction. Little friction is the real goal. From aldacron at gmail.com Sun Jul 3 11:39:45 2022 From: aldacron at gmail.com (Mike Parker) Date: Sun, 03 Jul 2022 11:39:45 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 11:13:42 UTC, Ola Fosheim Gr?stad wrote: > On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: >> Feedback is welcome. > > Thank you for putting this in clear terms. I miss an > overarching ?primary use scenarios? to guide further language > evolution. How do you know if new language features are good or > bad if you have no scenarios to measure them up against? That's not something we've discussed yet. Right now, the focus is on plugging holes in the existing language, building out the ecosystem, and overhauling Phobos. These areas are where we see some of the loudest complaints. Language evolution doesn't really mean much until we get all of this sorted. But we'll start discussing it at some point, at which time you'll see some new high-level goals appear. In the meantime, Walter and Atila will continue evaluating DIPs on a case-by-case basis. (Speaking of which, I want to look at overhauling the DIP process a bit some time next year). > > It is nice to see that improved move semantics is a goal, then > I guess ARC could be something one could envision down the > line. That said, I am a bit disappointed that there is no hint > of a departure from the current STOP-the-world GC regime, but I > guess that is the reflecting reality. My interpretation of the > vision document is that the core team sees no need to change > the current GC strategy. That's right. But Walter wants to minimize its use in Phobos v2, and there's a strong desire to have a pay-as-you-go DRuntime. I'm not the person to speculate on how the GC fits into that, but I do know they don't yet want git rid of it. (On a related note, I'll soon be publishing a video of a conversation I had with Walter about origins of D, and he said something there about the GC that really surprised me.) From ola.fosheim.grostad at gmail.com Sun Jul 3 12:21:57 2022 From: ola.fosheim.grostad at gmail.com (Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=) Date: Sun, 03 Jul 2022 12:21:57 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 11:39:45 UTC, Mike Parker wrote: > Language evolution doesn't really mean much until we get all of > this sorted. Good point. > That's right. But Walter wants to minimize its use in Phobos > v2, and there's a strong desire to have a pay-as-you-go > DRuntime. I'm not the person to speculate on how the GC fits > into that, but I do know they don't yet want git rid of it. Yes, the Phobos issue is probably a good point, but I don't think the standard library prevents experienced developers from doing anything (People can write their own or use third party solutions). Although I have been pro GC-free in the past, I am also not so sure if GC-free is the sweet spot in 2022 (due to Rust and C++ having reduced friction significantly). To my mind the sweet spot for larger applications would be to write your own runtime/GUI-framework/libraries in @system and cover your @safe application code with a convenient ?non-stop? (or at least only ?local stop?) GC/ARC solution. But I understand that you cannot say anything specific on this at this point in time. >(On a related note, I'll soon be publishing a video of a > conversation I had with Walter about origins of D, and he said > something there about the GC that really surprised me.) That would be interesting to hear more about as the GC was what surprised me the most when I first tried D as a C++ ?descendant?. From vladimmi at gmail.com Sun Jul 3 14:05:41 2022 From: vladimmi at gmail.com (Vladimir Marchevsky) Date: Sun, 03 Jul 2022 14:05:41 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: > Feedback is welcome. Had a hope to see the "complete started but abandoned features" point. From crazymonkyyy at gmail.com Sun Jul 3 17:09:46 2022 From: crazymonkyyy at gmail.com (monkyyy) Date: Sun, 03 Jul 2022 17:09:46 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: > Feedback is welcome. >Metaprogramming This section is... light on details and does little to clear up if you share my goals. My current take on this is that I believe something with c feature ser + templates are the future, their foundation extremely shaky and awful with c++ appearing to make it powerful by accident, and that I should be wherever there is the most sugar to make it livable. This will mostly involve me wanting an endless stream of new features to play with. But this contradicts the earlier section about simplicity and avoiding complex features. Templates generally get ugly syntax, alias when you want to store first class type, static if's everywhere, _______traits; so Id suggests that's updated to be complex features that affect standard code but generally be open to experimental features in the template space; so that templates are generally going to get the short end of the stick design-wise but that but open to exploring out the foundation meta programming needs. >Phobos and DRuntime You don't comment on how v2 should be organized. Currently, I believe to write functional-style code your going to import 5 different std libs and at least algorithm and range. Is that going to continue or be fixed? I find the naming conflicts of "write" to be fairly awful and makes `import std;` undoable and even if you always write out your imports, studio and file are often going to be used together. Will that be fixed? etc. etc. the goals of std v2 probably could get its own document. >Stronger ecosystem >Community management >All D users and contributors must feel comfortable participating >in the D community. >There is a divide between those who believe in a "kitchen sink" >standard library and those who support a minimal standard >library backed up by a large ecosystem. We must find a balance >that makes sense for the D programming language. Id suggest dropping std.experimental and get a std.community sort of thing going. Where given snar did sumtypes as a subtype lib, then got into std.experimental, had to follow your process and whatever; and then finally got merged into std. Instead, I'd suggest that snar makes an important lib, it gets noticed by the community, std.community.sumtype will point at snar's github either auto-downloaded or batched with compiler releases. Have whatever legal disclaimer that std.community is not your responsibility, is kinda bad style to overuse and should be verified yourself. But have a curated list of community projects that have a soft thumbs up and that are easy to use. While dropping the std.experimental take that everyone says is a bad experience. From rikki at cattermole.co.nz Sun Jul 3 17:27:43 2022 From: rikki at cattermole.co.nz (rikki cattermole) Date: Mon, 4 Jul 2022 05:27:43 +1200 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: > Stronger integration with other languages One of the things I judge D's compilers by is how well they can build a shared library. This is crucial for a lot of different applications of D and can be an complete stopper in using D if it doesn't "just work". To be blunt this is embarrassing, this should have been a top priority 10+ years ago... > Phobos and DRuntime I am very worried that this is going ahead without signatures. Its a major usability issue that concepts like ranges are not written into a function signature and is a common tripping point for people new to the language. I've been meaning to talk with Walter about this, this year. Times just haven't lined up at BeerConf to sort out lining up my designs into something that could actually go in. > No wstring or dstring. Any functions in Phobos v2 that deal with strings should deal exclusively with the string type. Users can convert from and to the other string types as needed. NOPEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE That's going to bite us big time when it comes to Unicode handling which wants to work with dstring's. > Provide automatic CI for actively-maintained third-party projects. I would like a big endian system to be included if possible, if a library is actively maintained you don't want surprises to arise from that. From ola.fosheim.grostad at gmail.com Sun Jul 3 18:10:47 2022 From: ola.fosheim.grostad at gmail.com (Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=) Date: Sun, 03 Jul 2022 18:10:47 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 17:27:43 UTC, rikki cattermole wrote: > That's going to bite us big time when it comes to Unicode > handling which wants to work with dstring's. You can just use ints? It is better to do something commonly used well, than have features that not enough people use to get the quality up. People who are willing to use 4 bytes per code point are probably using third party C-libraries that have their own representation, so you have to convert anyway? From rikki at cattermole.co.nz Sun Jul 3 18:33:29 2022 From: rikki at cattermole.co.nz (rikki cattermole) Date: Mon, 4 Jul 2022 06:33:29 +1200 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On 04/07/2022 6:10 AM, Ola Fosheim Gr?stad wrote: > People who are willing to use 4 bytes per code point are probably using > third party C-libraries that have their own representation, so you have > to convert anyway? If you use Unicode and follow their recommendations, you are going to be using dstrings at some point. For example, string equivalence, and anything to do with case is going to use them and very likely to require multiple memory allocations to do it. Its just an unnecessary goal, when most of the string algorithms we have probably don't care about the encoding and those that do probably will be using dstrings. From user1234 at 12.de Sun Jul 3 19:07:20 2022 From: user1234 at 12.de (user1234) Date: Sun, 03 Jul 2022 19:07:20 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 18:33:29 UTC, rikki cattermole wrote: > Its just an unnecessary goal, when most of the string > algorithms we have probably don't care about the encoding and > those that do probably will be using dstrings. To the contrary, I find this goal coherant with the end of autodecoding. that will probably make phobos simpler: less template overloads, less template constraints to evaluate, no more isNattowString etc. From ola.fosheim.grostad at gmail.com Sun Jul 3 19:18:11 2022 From: ola.fosheim.grostad at gmail.com (Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=) Date: Sun, 03 Jul 2022 19:18:11 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 18:33:29 UTC, rikki cattermole wrote: > > On 04/07/2022 6:10 AM, Ola Fosheim Gr?stad wrote: >> People who are willing to use 4 bytes per code point are >> probably using third party C-libraries that have their own >> representation, so you have to convert anyway? > > If you use Unicode and follow their recommendations, you are > going to be using dstrings at some point. I hardly ever use anything outside UTF-8, and if I do then I use a well tested unicode library as it has to be correct and up to date to be useful. The utility of going beyond UTF-8 seems to be limited: https://en.wikipedia.org/wiki/UTF-32#Analysis From rikki at cattermole.co.nz Sun Jul 3 19:32:56 2022 From: rikki at cattermole.co.nz (rikki cattermole) Date: Mon, 4 Jul 2022 07:32:56 +1200 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On 04/07/2022 7:18 AM, Ola Fosheim Gr?stad wrote: > I hardly ever use anything outside UTF-8, and if I do then I use a well > tested unicode library as it has to be correct and up to date to be > useful. The utility of going beyond UTF-8 seems to be limited: > > https://en.wikipedia.org/wiki/UTF-32#Analysis I have just finished implementing string normalization which is based around UTF-32. It is required for string equivalent comparisons (which is what you should be doing in a LOT more cases! Anything user provided when compared should be normalized first. From destructionator at gmail.com Sun Jul 3 19:37:51 2022 From: destructionator at gmail.com (Adam D Ruppe) Date: Sun, 03 Jul 2022 19:37:51 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 19:32:56 UTC, rikki cattermole wrote: > I have just finished implementing string normalization which is > based around UTF-32. There's a difference between utf-32 and unicode code points. > It is required for string equivalent comparisons (which is what > you should be doing in a LOT more cases! Anything user provided > when compared should be normalized first. Which you can do on any translation format. From ola.fosheim.grostad at gmail.com Sun Jul 3 20:16:35 2022 From: ola.fosheim.grostad at gmail.com (Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=) Date: Sun, 03 Jul 2022 20:16:35 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 19:32:56 UTC, rikki cattermole wrote: > It is required for string equivalent comparisons (which is what > you should be doing in a LOT more cases! Anything user provided > when compared should be normalized first. Well, I think it is reasonable for a protocol to require that the input is NFC, and just check it and reject it or call out to an external library to convert it into NFC. Anyway, UTF-8 is the only format that isn't affected by network byte order? So if you support more than UTF-8 then you have to support UTF-8, UTF16-LE, UTF16-BE, UTF-32LE, UTF-32BE? That is five formats for just a simple string? and only UTF-8 will be well tested by users. :-/ From rikki at cattermole.co.nz Sun Jul 3 20:28:18 2022 From: rikki at cattermole.co.nz (rikki cattermole) Date: Mon, 4 Jul 2022 08:28:18 +1200 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On 04/07/2022 8:16 AM, Ola Fosheim Gr?stad wrote: > On Sunday, 3 July 2022 at 19:32:56 UTC, rikki cattermole wrote: >> It is required for string equivalent comparisons (which is what you >> should be doing in a LOT more cases! Anything user provided when >> compared should be normalized first. > > Well, I think it is reasonable for a protocol to require that the input > is NFC, and just check it and reject it or call out to an external > library to convert it into NFC. > > Anyway, UTF-8 is the only format that isn't affected by network byte > order? So if you support more than UTF-8 then you have to support UTF-8, > UTF16-LE, UTF16-BE, UTF-32LE, UTF-32BE? > > That is five formats for just a simple string? and only UTF-8 will be > well tested by users. :-/ https://issues.dlang.org/show_bug.cgi?id=23186 We only support UTF-16/UTF-32 for the target endian. Text input comes from many sources, stdin, files and say the windowing system are three common sources that do not make any such guarantees. From ola.fosheim.grostad at gmail.com Sun Jul 3 21:01:49 2022 From: ola.fosheim.grostad at gmail.com (Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=) Date: Sun, 03 Jul 2022 21:01:49 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 20:28:18 UTC, rikki cattermole wrote: > We only support UTF-16/UTF-32 for the target endian. > > Text input comes from many sources, stdin, files and say the > windowing system are three common sources that do not make any > such guarantees. Well, then the application author will use an external Unicode library anyway. If you support UTF-16 or UTF-32 there might not be a BOM mark, so you might need to use heuristics to figure out the LE/LB endian issue. For things like gzip, png, crypto and unicode there are most likely faster and better tested open source alternatives than a small community can come up with. Maybe just use out whatever Chromium or Clang uses? What I never liked about C++ is the string mess: char, signed char, unsigned char, char8_t, char16_t, char32_t, wchar_t, string, wstring, u8string, u16string, u32string, pmr::string, pmr::wstring, pmr::u8string, pmr::u16string, pmr::u32string? And this doesn't even account for endianess!! This is what happens over time as new needs pops up. One of the best things about Python3 and JavaScript is that there is one commonly used string type that is well supported. Having one common string representation is a good thing for API authors. (But make sure to have a maintained binding to a versatile C unicode library.) From rikki at cattermole.co.nz Sun Jul 3 21:06:40 2022 From: rikki at cattermole.co.nz (rikki cattermole) Date: Mon, 4 Jul 2022 09:06:40 +1200 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: We have a perfectly good Unicode handling library already. (Okay, little out of date and doesn't handle Turkic stuff, but fixable). The standard one is called ICU. Anyway, we are straying from my original point, that limiting ourselves to the string alias and not supporting wstring or dstring in Phobos is going to bite us. Its not what people expect, its not what we have supported and code that looks like it should work won't. There better be a good reason for this that isn't just removing templates. From andrej.mitrovich at gmail.com Mon Jul 4 05:30:10 2022 From: andrej.mitrovich at gmail.com (Andrej Mitrovic) Date: Mon, 04 Jul 2022 05:30:10 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: > You can find the final draft of the high-level goals for the D > programming language at the following link: > > https://github.com/dlang/vision-document Under 'Memory safety': > Allow the continued use of garbage collection as the default > memory management strategy without impact. The GC is one of D's > strengths, and we should not "throw the baby out with the bath > water". Under 'Phobos and DRuntime': > @nogc as much as possible. Aren't these the polar opposites of each other? The GC is one of D's strengths, yet we should avoid it as much as possible in the standard library. Then it's not part of D's strengths. From rikki at cattermole.co.nz Mon Jul 4 05:35:20 2022 From: rikki at cattermole.co.nz (rikki cattermole) Date: Mon, 4 Jul 2022 17:35:20 +1200 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On 04/07/2022 5:30 PM, Andrej Mitrovic wrote: > Aren't these the polar opposites of each other? The GC is one of D's > strengths, yet we should avoid it as much as possible in the standard > library. Not necessarily. It could and should most likely mean that it won't do any heap allocations. Heap allocations are expensive after all. From andrej.mitrovich at gmail.com Mon Jul 4 05:51:48 2022 From: andrej.mitrovich at gmail.com (Andrej Mitrovic) Date: Mon, 04 Jul 2022 05:51:48 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Monday, 4 July 2022 at 05:35:20 UTC, rikki cattermole wrote: > > On 04/07/2022 5:30 PM, Andrej Mitrovic wrote: >> Aren't these the polar opposites of each other? The GC is one >> of D's strengths, yet we should avoid it as much as possible >> in the standard library. > > Not necessarily. > > It could and should most likely mean that it won't do any heap > allocations. > > Heap allocations are expensive after all. @safe @nogc @noheap? :) Baby, you got a stew going! From aldacron at gmail.com Mon Jul 4 06:01:09 2022 From: aldacron at gmail.com (Mike Parker) Date: Mon, 04 Jul 2022 06:01:09 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote: > On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: >> You can find the final draft of the high-level goals for the D >> programming language at the following link: >> >> https://github.com/dlang/vision-document > > Under 'Memory safety': > >> Allow the continued use of garbage collection as the default >> memory management strategy without impact. The GC is one of >> D's strengths, and we should not "throw the baby out with the >> bath water". > > Under 'Phobos and DRuntime': > >> @nogc as much as possible. > > Aren't these the polar opposites of each other? The GC is one > of D's strengths, yet we should avoid it as much as possible in > the standard library. `@nogc` code in Phobos still allows the use of the GC in client code. Those are not opposite goals. > > Then it's not part of D's strengths. No, that's not what that means. When Phobos was originally implemented, `@nogc` wasn't a thing. There was no (or little) consideration given to whether a particular function absolutely needed to use the GC, or if there was an alternative. And later on, as demand grew for more `@nogc` support, that had to be bolted on. So what the `@nogc as much as possible` goal means is that it should be a consideration for the implementation of Phobos v2 from the beginning. The design of the API should allow `@nogc` client code to make use of it as much as possible. GC is a strength, but it's not a panacea. There are specific cases where people determine it's better to avoid it, and there are some people who don't want to use it at all. As long as we continue to support `@nogc` in the language, then we ought to provide support for it in Phobos to the extent that we can. The vision document is just making it clear that this will be a goal from the beginning with v2. From andrej.mitrovich at gmail.com Mon Jul 4 06:51:14 2022 From: andrej.mitrovich at gmail.com (Andrej Mitrovic) Date: Mon, 04 Jul 2022 06:51:14 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Monday, 4 July 2022 at 06:01:09 UTC, Mike Parker wrote: > So what the `@nogc as much as possible` goal means is that it > should be a consideration for the implementation of Phobos v2 > from the beginning. The design of the API should allow `@nogc` > client code to make use of it as much as possible. Fair enough. From starcanopy at protonmail.com Mon Jul 4 07:28:23 2022 From: starcanopy at protonmail.com (StarCanopy) Date: Mon, 04 Jul 2022 07:28:23 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: > [...] Firstly, thank you for composing this. Given the desire to reduce GC usage in PhobosV2, would it be fair to say this implies changing error handling schemes found therein, i.e. avoiding exceptions as they are implemented now, where reasonable? And if so, have core members mentioned any alternatives? With regards to moderation policy, are there specific issues; about which you feel comfortable speaking; that prompted this item's inclusion in the vision document? From ola.fosheim.grostad at gmail.com Mon Jul 4 07:39:46 2022 From: ola.fosheim.grostad at gmail.com (Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=) Date: Mon, 04 Jul 2022 07:39:46 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 21:06:40 UTC, rikki cattermole wrote: > We have a perfectly good Unicode handling library already. > > (Okay, little out of date and doesn't handle Turkic stuff, but > fixable). > > The standard one is called ICU. Yes, that is a common one that is maintained, but maybe there are BOOST licensed implementations too? One can do an exhaustive test for say two-character normalization against ICU to see if they are compliant. Anyway, normalization should not happen behind your back in a system level language. You might want to treat different encodings of the same string differently when comparing. > Anyway, we are straying from my original point, that limiting > ourselves to the string alias and not supporting wstring or > dstring in Phobos is going to bite us. I guess some Windows programmers want 16 bit? but I don't think the conversion matters all that much in that context? > There better be a good reason for this that isn't just removing > templates. The good reason would be that you can focus on fast SIMD optimized algoritms that makes sense for the byte-encoding of UTF-8, and get something competitive. From user1234 at 12.de Mon Jul 4 07:52:51 2022 From: user1234 at 12.de (user1234) Date: Mon, 04 Jul 2022 07:52:51 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Monday, 4 July 2022 at 05:51:48 UTC, Andrej Mitrovic wrote: > On Monday, 4 July 2022 at 05:35:20 UTC, rikki cattermole wrote: >> >> On 04/07/2022 5:30 PM, Andrej Mitrovic wrote: >>> Aren't these the polar opposites of each other? The GC is one >>> of D's strengths, yet we should avoid it as much as possible >>> in the standard library. >> >> Not necessarily. >> >> It could and should most likely mean that it won't do any heap >> allocations. >> >> Heap allocations are expensive after all. > > @safe @nogc @noheap? :) @noheap is not so necessary, at least for aggregates we have `@disable new(size_t);` From aldacron at gmail.com Mon Jul 4 08:34:14 2022 From: aldacron at gmail.com (Mike Parker) Date: Mon, 04 Jul 2022 08:34:14 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Monday, 4 July 2022 at 07:28:23 UTC, StarCanopy wrote: > On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: >> [...] >> > Given the desire to reduce GC usage in PhobosV2, would it be > fair to say this implies changing error handling schemes found > therein, i.e. avoiding exceptions as they are implemented now, > where reasonable? And if so, have core members mentioned any > alternatives? Walter and Atila have both talked about rethinking exceptions. Atila brought it up in his DConf Online 2021 talk here: https://youtu.be/UqW42_8kn0s?t=1429 You can see Walter's comments about it in the subsequent Q & A session here: https://youtu.be/g26eJcs2QB0?t=1809 > > With regards to moderation policy, are there specific issues; > about which you feel comfortable speaking; that prompted this > item's inclusion in the vision document? We've had a very, very lax moderation policy for years. Sometimes threads get derailed and posts become overly aggressive, but we've tended to let things slide as long as commenters avoid blatantly direct personal attacks, racist remarks, etc. I've always felt we have a great forum community compared to some others I've experienced, and I've found the need to delete forum posts, given the existing policy, to be relatively rare. The flip side of that is that the larger internet community has evolved over the past couple of decades. What I consider tolerable if annoying behavior, others view as toxic. What I view as sarcasm or biting wit or some such, others view as personal attacks. We've received a number of complaints in recent months, directly and indirectly, about our forums being toxic. And that's not the image we want out there. And we definitely don't want people to actively choose not to participate in the forums just to avoid what they see as toxicity. So we want to tighten the screws a little bit. In terms of directly deleting posts unprompted, the policy isn't changing. If I wouldn't have deleted a post before, I won't delete it now. What *is* changing is that we're going to be a bit more active in nudging threads back on topic when they stray too far off, and asking people to keep things toned down if their remarks become aggressive to the extent that it looks like they're going to derail the thread. We've had incidents in the past where one or two people upset a number of other forum users, and we didn't act as soon as we should have to keep things from getting out of hand. In the past, forum users have sometimes reported posts to me indicating that they felt it was a direct personal attack. Usually, if *I* didn't see it as a direct attack, I wouldn't delete it. I'd explain how I see it and explain my reason for letting it stand. Going forward, I'll instead give a warning to the author of the post in question, and ask them to refrain from such remarks in future posts. And once a warning is given (stay on topic, please tone it down, please avoid remarks like this one, etc.), any further posts in that thread that ignore the warning will be deleted. I think that's a reasonable policy. The last thing any of us want is to stifle debate or censor opinions, but we feel that it's reasonable to ask people to participate in debates and express their opinions without upsetting others. So we're going to do our best to find a middle ground. From templated at person.com Mon Jul 4 12:21:11 2022 From: templated at person.com (Templated Person) Date: Mon, 04 Jul 2022 12:21:11 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: > You can find the final draft of the high-level goals for the D > programming language at the following link: > > https://github.com/dlang/vision-document > > > I also want to reiterate that this is a living document. We > will modify the goals as needed as time goes by. > > Feedback is welcome. In the document it is said: > `@nogc` as much as possible. I think this should be extended to clarify how conversion to `@nogc` will be tackled. IMHO adding proper stable `@nogc` allocators to the stdlib is more important. When that's done, make sure we can set the allocator for stdlib types and add `@nogc` overloads that take an allocator parameter for non-`@nogc` functions. We aren't doing no-heap programming after all. If we have a stable allocator interface, replacing GC calls with allocator calls in Phobos shouldn't be too hard. From rikki at cattermole.co.nz Mon Jul 4 16:12:35 2022 From: rikki at cattermole.co.nz (rikki cattermole) Date: Tue, 5 Jul 2022 04:12:35 +1200 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On 04/07/2022 7:39 PM, Ola Fosheim Gr?stad wrote: > Yes, that is a common one that is maintained, but maybe there are BOOST > licensed implementations too? One can do an exhaustive test for say > two-character normalization against ICU to see if they are compliant. https://www.unicode.org/Public/14.0.0/ucd/NormalizationTest.txt My implementation passes this :3 It should be complete test cases. From razvan.nitu1305 at gmail.com Tue Jul 5 08:26:28 2022 From: razvan.nitu1305 at gmail.com (RazvanN) Date: Tue, 05 Jul 2022 08:26:28 +0000 Subject: Winners of the April 1st - July 1st 2022 Bugzilla Cycle Message-ID: Hello everyone, It is my pleasure to announce that the winners of the 2nd bugzilla cycle of the year are: 1. BorisCarvajal - 370 points 2. MoonlightSentinel - 135 points 3. FeepingCreature - 120 points Congratulations! The cycle standings are here: https://bot.dlang.io/contributor_stats_cycle The overall standings hierarchy, which counts all the points that have been collected since the system was put in place, is here: https://bot.dlang.io/contributor_stats A new bugzilla cycle has started on the 1st of July and will end on the 30th of September. Cheers, RazvanN From ola.fosheim.grostad at gmail.com Tue Jul 5 08:29:55 2022 From: ola.fosheim.grostad at gmail.com (Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=) Date: Tue, 05 Jul 2022 08:29:55 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Monday, 4 July 2022 at 16:12:35 UTC, rikki cattermole wrote: > https://www.unicode.org/Public/14.0.0/ucd/NormalizationTest.txt Argh, linking to large files... > My implementation passes this :3 > > It should be complete test cases. Well, you also have to test for the cases that should not trigger any change, and also for sequencing/parsing bugs. So, not complete, but a good start. From ryuukk.dev at gmail.com Tue Jul 5 11:49:20 2022 From: ryuukk.dev at gmail.com (ryuukk_) Date: Tue, 05 Jul 2022 11:49:20 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: > Pattern matching Hopefully that includes proper built in Tagged Union, non OOP people need that otherwise we are stuck in C's era of programming We can, and we should do better (import std.sumtype is embarrassing when other languages have it built in without template soup, i still refuse to touch it) > Tuples Awesome! hopefully they become built in and more integrated > Async/await This one will be tricky, done well means it scale from 0 to hearo, meaning i should be able to use it without the need of a GC Hopefully it's not one of these import `std.concurency: async, await, frame;` > Stronger traits That's awesome to hear, metaprogramming is one of D's strength On the tooling part: A language server is long overdue.. https://pkg.go.dev/golang.org/x/tools/gopls https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html https://rust-analyzer.github.io/ The one we have right now (serve-d) is nice, but uses the same backend as every other projects (DCD), and this project haven't evolved in years, the moment you step into template territory, it falls short ``T get(T)() { return T.init } auto myInt = get!int;`` it'll not know what myInt is.. wich is a shame when that feature is D's signature A better debugging story is also essential, without having to use external (incomplete) files like: https://github.com/Pure-D/dlang-debug msvc, clang, gcc: they should know what D types are, and they should be able to step properly into D syntax without the need of the user to do weird things Zig is a young language and yet has a better debugging story Onto the phobos/druntime: That's nice to hear that the goal is to reduce inter module dependencies Core APIs should be made independent and VERY simple, this allows them to be easily ported to other platforms, easier to extend I am sad that no word on the Allocator API, moving forward i personally think APIs that use memory should be required to ask for an Allocator and do their allocation using it, and only it A default GCAllocator could be used if none provided, this allows users of all kind to enjoy the APIs without having to complain about the GC or their inability to integrate the APIs in their game engine for example -- Overall this document is super encouraging, thanks for making it, D finally have a long term roadmap! Hopefully this allows everyone to align and coordinate their efforts I wish i could help, i tried, but language programming is definitely not my cup of tea, hopefully you guys are not sick of my suggestions A language is about allowing user to express their intent, making it easier for them to achieve that goal is a priority, compiler internal difficulties should not prevent language improvements, compiler internals doesn't exist from the user point of view From ryuukk.dev at gmail.com Tue Jul 5 12:34:57 2022 From: ryuukk.dev at gmail.com (ryuukk_) Date: Tue, 05 Jul 2022 12:34:57 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote: > On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: >> You can find the final draft of the high-level goals for the D >> programming language at the following link: >> >> https://github.com/dlang/vision-document > > Under 'Memory safety': > >> Allow the continued use of garbage collection as the default >> memory management strategy without impact. The GC is one of >> D's strengths, and we should not "throw the baby out with the >> bath water". > > Under 'Phobos and DRuntime': > >> @nogc as much as possible. > > Aren't these the polar opposites of each other? The GC is one > of D's strengths, yet we should avoid it as much as possible in > the standard library. > > Then it's not part of D's strengths. GC is one of D's strength because it is optional, not making core APIs bing-your-own-memory-allocation-strategy through nogc or allocators, is making it no longer optional, which is no longer a strength imo You don't want GC when you do microcontroller development, so as a result core APIs (most of them) becomes useless, moving forward that should make the story better for everyone Which becomes a strength again! From rikki at cattermole.co.nz Tue Jul 5 17:40:01 2022 From: rikki at cattermole.co.nz (rikki cattermole) Date: Wed, 6 Jul 2022 05:40:01 +1200 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On 05/07/2022 11:49 PM, ryuukk_ wrote: > Hopefully that includes proper built in Tagged Union, non OOP people > need that otherwise we are stuck in C's era of programming C's era of programming also happens to coincide with ML which had tagged unions ;) The C family has never been very expressive. From andrej.mitrovich at gmail.com Wed Jul 6 05:10:39 2022 From: andrej.mitrovich at gmail.com (Andrej Mitrovic) Date: Wed, 06 Jul 2022 05:10:39 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Tuesday, 5 July 2022 at 12:34:57 UTC, ryuukk_ wrote: > GC is one of D's strength because it is optional, not making > core APIs bing-your-own-memory-allocation-strategy through nogc > or allocators, is making it no longer optional, which is no > longer a strength imo > > You don't want GC when you do microcontroller development, so > as a result core APIs (most of them) becomes useless, moving > forward that should make the story better for everyone > > Which becomes a strength again! Sure, I agree with you. I think I was just being pedantic. :) From ola.fosheim.grostad at gmail.com Wed Jul 6 07:33:15 2022 From: ola.fosheim.grostad at gmail.com (Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=) Date: Wed, 06 Jul 2022 07:33:15 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Tuesday, 5 July 2022 at 11:49:20 UTC, ryuukk_ wrote: > I am sad that no word on the Allocator API, moving forward i > personally think APIs that use memory should be required to ask > for an Allocator and do their allocation using it, and only it > > A default GCAllocator could be used if none provided, this > allows users of all kind to enjoy the APIs without having to > complain about the GC or their inability to integrate the APIs > in their game engine for example It should not be resolved like this. Functions that does not return memory should just be nogc. Functions that return allocated memory that are nogc should use RAII and prevent GC pointers from pointing to it. So you need a new type system. Or just overload on @system. You also want to get rid of destructors on GC objects and replace it with a finalizer that isnt sensitive to order. From pjmlp at progtools.org Wed Jul 6 14:30:07 2022 From: pjmlp at progtools.org (Paulo Pinto) Date: Wed, 06 Jul 2022 14:30:07 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Tuesday, 5 July 2022 at 12:34:57 UTC, ryuukk_ wrote: > On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote: >> On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: >>> You can find the final draft of the high-level goals for the >>> D programming language at the following link: >>> >>> https://github.com/dlang/vision-document >> >> Under 'Memory safety': >> >>> Allow the continued use of garbage collection as the default >>> memory management strategy without impact. The GC is one of >>> D's strengths, and we should not "throw the baby out with the >>> bath water". >> >> Under 'Phobos and DRuntime': >> >>> @nogc as much as possible. >> >> Aren't these the polar opposites of each other? The GC is one >> of D's strengths, yet we should avoid it as much as possible >> in the standard library. >> >> Then it's not part of D's strengths. > > GC is one of D's strength because it is optional, not making > core APIs bing-your-own-memory-allocation-strategy through nogc > or allocators, is making it no longer optional, which is no > longer a strength imo > > You don't want GC when you do microcontroller development, so > as a result core APIs (most of them) becomes useless, moving > forward that should make the story better for everyone > > Which becomes a strength again Feel free to consider it a strength, when in reality it is a flaw against established market players. https://www.microej.com/ https://www.wildernesslabs.co/ https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ https://www.astrobe.com/ From ryuukk.dev at gmail.com Wed Jul 6 15:43:25 2022 From: ryuukk.dev at gmail.com (ryuukk_) Date: Wed, 06 Jul 2022 15:43:25 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Wednesday, 6 July 2022 at 14:30:07 UTC, Paulo Pinto wrote: > On Tuesday, 5 July 2022 at 12:34:57 UTC, ryuukk_ wrote: >> On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote: >>> On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote: >>>> You can find the final draft of the high-level goals for the >>>> D programming language at the following link: >>>> >>>> https://github.com/dlang/vision-document >>> >>> Under 'Memory safety': >>> >>>> Allow the continued use of garbage collection as the default >>>> memory management strategy without impact. The GC is one of >>>> D's strengths, and we should not "throw the baby out with >>>> the bath water". >>> >>> Under 'Phobos and DRuntime': >>> >>>> @nogc as much as possible. >>> >>> Aren't these the polar opposites of each other? The GC is one >>> of D's strengths, yet we should avoid it as much as possible >>> in the standard library. >>> >>> Then it's not part of D's strengths. >> >> GC is one of D's strength because it is optional, not making >> core APIs bing-your-own-memory-allocation-strategy through >> nogc or allocators, is making it no longer optional, which is >> no longer a strength imo >> >> You don't want GC when you do microcontroller development, so >> as a result core APIs (most of them) becomes useless, moving >> forward that should make the story better for everyone >> >> Which becomes a strength again > > Feel free to consider it a strength, when in reality it is a > flaw against established market players. > > https://www.microej.com/ > > https://www.wildernesslabs.co/ > > https://www.ptc.com/en/products/developer-tools/perc > > https://www.aicas.com/wp/products-services/jamaicavm/ > > https://www.astrobe.com/ People also use nodejs and npm, what is your point? If you invest in the future you must take the pragmatic approach and give options Those are not Oracle's products, companies took the JVM for what it is as a foundation and built their products They haven't picked the default Oracle JDK and the default concurrent GC D should enable similar stories with what it has and can provide, read on the challenges TinyGO faced, if D provides the tools for companies to experiment with it, with a proper set of efficient and minimal Core APIs, that alone makes it a proper and more efficient alternative solution From ajieskola at gmail.com Wed Jul 6 21:05:57 2022 From: ajieskola at gmail.com (Dukc) Date: Wed, 06 Jul 2022 21:05:57 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Monday, 4 July 2022 at 08:34:14 UTC, Mike Parker wrote: > [snip] > > I think that's a reasonable policy. The last thing any of us > want is to stifle debate or censor opinions, but we feel that > it's reasonable to ask people to participate in debates and > express their opinions without upsetting others. So we're going > to do our best to find a middle ground. Thanks for the explaination. I agree with all of this. I think we should get into habit to start a new thread for branching discussions with much lower bar than we currently do. Myself included. From ajieskola at gmail.com Wed Jul 6 21:30:44 2022 From: ajieskola at gmail.com (Dukc) Date: Wed, 06 Jul 2022 21:30:44 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 20:16:35 UTC, Ola Fosheim Gr?stad wrote: > On Sunday, 3 July 2022 at 19:32:56 UTC, rikki cattermole wrote: >> It is required for string equivalent comparisons (which is >> what you should be doing in a LOT more cases! Anything user >> provided when compared should be normalized first. > > Well, I think it is reasonable for a protocol to require that > the input is NFC, and just check it and reject it or call out > to an external library to convert it into NFC. > > Anyway, UTF-8 is the only format that isn't affected by network > byte order? So if you support more than UTF-8 then you have to > support UTF-8, UTF16-LE, UTF16-BE, UTF-32LE, UTF-32BE? It is pretty easy to convert those to native endian and back with functions in `std.bitmanip`. I recently did so to have a program to recognise files in all of those five. Also the Phobos functions are of high quality. They work extremely well with the range API (other than having to live with autodecoding), they are well documented and they are comprehensive enough for almost any task. I don't recall having ever considered another library for handling Unicode. And I think there is still pretty much value in handling UTF-16 strings because that's what many other languages use. With the current vision, Phobos V2 won't handle UTF16 in place. We'll have to convert it to UTF8 before manipulation, which is probably not optimal. And if the string functions have to deal with two formats anyway, also supporting UTF32 on top of them probably does not make much difference. That said, I don't feel strongly about this because if we kick UTF16 and UTF32 functions out of Phobos, they still are presumably available in Undead. From pjmlp at progtools.org Wed Jul 6 22:12:33 2022 From: pjmlp at progtools.org (Paulo Pinto) Date: Wed, 06 Jul 2022 22:12:33 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Wednesday, 6 July 2022 at 15:43:25 UTC, ryuukk_ wrote: > On Wednesday, 6 July 2022 at 14:30:07 UTC, Paulo Pinto wrote: >> On Tuesday, 5 July 2022 at 12:34:57 UTC, ryuukk_ wrote: >>> On Monday, 4 July 2022 at 05:30:10 UTC, Andrej Mitrovic wrote: >>>> [...] >>> >>> GC is one of D's strength because it is optional, not making >>> core APIs bing-your-own-memory-allocation-strategy through >>> nogc or allocators, is making it no longer optional, which is >>> no longer a strength imo >>> >>> You don't want GC when you do microcontroller development, so >>> as a result core APIs (most of them) becomes useless, moving >>> forward that should make the story better for everyone >>> >>> Which becomes a strength again >> >> Feel free to consider it a strength, when in reality it is a >> flaw against established market players. >> >> https://www.microej.com/ >> >> https://www.wildernesslabs.co/ >> >> https://www.ptc.com/en/products/developer-tools/perc >> >> https://www.aicas.com/wp/products-services/jamaicavm/ >> >> https://www.astrobe.com/ > > People also use nodejs and npm, what is your point? > > If you invest in the future you must take the pragmatic > approach and give options > > Those are not Oracle's products, companies took the JVM for > what it is as a foundation and built their products > > They haven't picked the default Oracle JDK and the default > concurrent GC > > D should enable similar stories with what it has and can > provide, read on the challenges TinyGO faced, if D provides the > tools for companies to experiment with it, with a proper set of > efficient and minimal Core APIs, that alone makes it a proper > and more efficient alternative solution My point is that GC hate is not a fixed problem in D, and the vision does little to fix it. Meanwhile the language communities that embraced GC in embedded deployment, are at least 20 years ahead in production deployments versus D, where no GC keeps being a reason to rejoice, like the the comment I replied to. The future was when Andrei book came out. From ola.fosheim.grostad at gmail.com Wed Jul 6 22:31:19 2022 From: ola.fosheim.grostad at gmail.com (Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=) Date: Wed, 06 Jul 2022 22:31:19 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Wednesday, 6 July 2022 at 21:30:44 UTC, Dukc wrote: > And I think there is still pretty much value in handling UTF-16 > strings because that's what many other languages use. With the > current vision, Phobos V2 won't handle UTF16 in place. We'll > have to convert it to UTF8 before manipulation, which is > probably not optimal. Oh, there is no doubt that handling UTF16 should be possible, but it can be done just as well, if not better, as a support library. But it is very much undesirable to have more than a single string format for library authors to deal with. From newshound2 at digitalmars.com Thu Jul 7 03:46:01 2022 From: newshound2 at digitalmars.com (Walter Bright) Date: Wed, 6 Jul 2022 20:46:01 -0700 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: Mike has our full support in his moderation policy and authority. From andrewlalisofficial at gmail.com Fri Jul 8 18:31:37 2022 From: andrewlalisofficial at gmail.com (Andrew) Date: Fri, 08 Jul 2022 18:31:37 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: Thanks for this. As a casual D user who is coming from a Java background, I'm of the opinion that we do indeed need to improve Phobos to either (a) include lots of stuff in the std lib itself, or (b) guide users to trusted, well-tested third-party libraries. I've tried doing things with asynchronous stuff, http, encrypted sockets, etc, for small utilities we use at my work, but a decent amount of time is spent on just looking for a good library that works. Specifically, a single unifying async library similar to JS promises or Java's futures would drastically improve the ecosystem, imo. From maxhaton at gmail.com Sat Jul 9 22:24:45 2022 From: maxhaton at gmail.com (max haughton) Date: Sat, 09 Jul 2022 22:24:45 +0000 Subject: Druntime merged into dmd repo Message-ID: Say thank you to Iain, Mathias, Vladimir, and Martin. This will make D better. More details to come. From rikki at cattermole.co.nz Sat Jul 9 22:32:33 2022 From: rikki at cattermole.co.nz (rikki cattermole) Date: Sun, 10 Jul 2022 10:32:33 +1200 Subject: Druntime merged into dmd repo In-Reply-To: References: Message-ID: Very well done! I do hope this isn't the end, because things like bindings really shouldn't be in the dmd repository. From vladimmi at gmail.com Sat Jul 9 22:59:19 2022 From: vladimmi at gmail.com (Vladimir Marchevsky) Date: Sat, 09 Jul 2022 22:59:19 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Sunday, 3 July 2022 at 17:09:46 UTC, monkyyy wrote: > Id suggest dropping std.experimental and get a std.community > sort of thing going. Well, it's named dub :) From crazymonkyyy at gmail.com Sat Jul 9 23:40:21 2022 From: crazymonkyyy at gmail.com (monkyyy) Date: Sat, 09 Jul 2022 23:40:21 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Saturday, 9 July 2022 at 22:59:19 UTC, Vladimir Marchevsky wrote: > On Sunday, 3 July 2022 at 17:09:46 UTC, monkyyy wrote: >> Id suggest dropping std.experimental and get a std.community >> sort of thing going. > Well, it's named dub :) Its not curated. Its enforces a vision. It changes the compiler options. and its randomly configured in js. From alexandru.ermicioi at gmail.com Sun Jul 10 10:42:48 2022 From: alexandru.ermicioi at gmail.com (Alexandru Ermicioi) Date: Sun, 10 Jul 2022 10:42:48 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Saturday, 9 July 2022 at 23:40:21 UTC, monkyyy wrote: > ... and its randomly configured in js. json or sdl, with well documented structure, not random js. From aldacron at gmail.com Sun Jul 10 16:17:11 2022 From: aldacron at gmail.com (Mike Parker) Date: Sun, 10 Jul 2022 16:17:11 +0000 Subject: D Community Conversations: Walter Bright on the Origins of D Part 1 Message-ID: I mentioned a little while back that I planned to start a D Community Conversations series on the Foundation's YouTube channel. In this series, I'll chat in depth with various people from the D community about their their projects, their programming backgrounds, their influences, how they got started with D, etc. I've just published the first episode here: https://youtu.be/-kkMYJN3MnA I had a nice chat with Walter starting with the earliest influences that set him on the path to becoming a compiler writer, and exploring how his life experiences influenced the design of D. As always, he throws in a number of anecdotes, many of which I'd never heard before. The inspiration and reference for this discussion is 'Origins of the D Programming Language', [the paper that Walter, Andrei, and I wrote](https://dl.acm.org/doi/abs/10.1145/3386323) for the HOPL IV conference. We carried the talk up to the early work he did on D. We'll pick up there for Part 2 in future episode, where we'll talk more specifically about the design decisions behind, and the evolution of, D1. Thanks to Walter for sitting down to do this with me. We actually had to do it twice, as I botched the recording of our first session last week. I enjoyed both chats, and I'm looking forward to the next one. I'll plan to do one of these every other month, so I'll be reaching out to people around the D community as time goes on. From nise at nise.com Sun Jul 10 17:17:30 2022 From: nise at nise.com (IGotD-) Date: Sun, 10 Jul 2022 17:17:30 +0000 Subject: Druntime merged into dmd repo In-Reply-To: References: Message-ID: On Saturday, 9 July 2022 at 22:24:45 UTC, max haughton wrote: > Say thank you to Iain, Mathias, Vladimir, and Martin. > > This will make D better. More details to come. Does this mean that druntime for LDC and GDC were also moved into the same repo? Same branch? From no at spam.net Sun Jul 10 18:26:13 2022 From: no at spam.net (bachmeier) Date: Sun, 10 Jul 2022 18:26:13 +0000 Subject: D Community Conversations: Walter Bright on the Origins of D Part 1 In-Reply-To: References: Message-ID: On Sunday, 10 July 2022 at 16:17:11 UTC, Mike Parker wrote: [...] This is really good. Have you considered uploading the audio to Spotify or somewhere as a podcast? No idea what that would involve, but for a lot of us there are more opportunities to listen to a podcast rather than watch a YT video. From aldacron at gmail.com Mon Jul 11 03:26:35 2022 From: aldacron at gmail.com (Mike Parker) Date: Mon, 11 Jul 2022 03:26:35 +0000 Subject: D Community Conversations: Walter Bright on the Origins of D Part 1 In-Reply-To: References: Message-ID: On Sunday, 10 July 2022 at 18:26:13 UTC, bachmeier wrote: > On Sunday, 10 July 2022 at 16:17:11 UTC, Mike Parker wrote: > > [...] > > This is really good. Thanks! > > Have you considered uploading the audio to Spotify or somewhere > as a podcast? No idea what that would involve, but for a lot of > us there are more opportunities to listen to a podcast rather > than watch a YT video. That hadn't crossed my mind. I'll look into it. From matheus at gmail.com Mon Jul 11 13:09:37 2022 From: matheus at gmail.com (matheus) Date: Mon, 11 Jul 2022 13:09:37 +0000 Subject: D Community Conversations: Walter Bright on the Origins of D Part 1 In-Reply-To: References: Message-ID: On Sunday, 10 July 2022 at 16:17:11 UTC, Mike Parker wrote: > ... Very nice interview, and if you don't mind can I give you a suggestion? I'd like to suggest that you don't make these "micro-cuts" through the interview/discussion, let it flow. I've been seeing this around these videos and I think it's better to let it go as is (Like it was live). Or if possible have the 2 versions (With and without cuts). Thanks, Matheus. From aldacron at gmail.com Mon Jul 11 13:37:10 2022 From: aldacron at gmail.com (Mike Parker) Date: Mon, 11 Jul 2022 13:37:10 +0000 Subject: D Community Conversations: Walter Bright on the Origins of D Part 1 In-Reply-To: References: Message-ID: On Monday, 11 July 2022 at 13:09:37 UTC, matheus wrote: > On Sunday, 10 July 2022 at 16:17:11 UTC, Mike Parker wrote: >> ... > > Very nice interview, and if you don't mind can I give you a > suggestion? > > I'd like to suggest that you don't make these "micro-cuts" > through the interview/discussion, let it flow. I've been seeing > this around these videos and I think it's better to let it go > as is (Like it was live). Or if possible have the 2 versions > (With and without cuts). > Thanks! Unfortunately, I disagree about the cuts. The primary motivation is to trim the length of the video down. I think that's important for YouTube videos. The cuts I make can cumulatively lop several minutes off the video. I wasn't as aggressive with this one as I have been with the DConf Online vids. Most of what I cut out was dead air, but I also got rid of a few uhs and ahhs, a handful of tied tongues, and a couple of instances where one of us had to start over again. As for two versions, I'm not really interested in adding the extra time for that to my workflow :-) From salihdb at hotmail.com Mon Jul 11 13:51:27 2022 From: salihdb at hotmail.com (Salih Dincer) Date: Mon, 11 Jul 2022 13:51:27 +0000 Subject: D Community Conversations: Walter Bright on the Origins of D Part 1 In-Reply-To: References: Message-ID: On Sunday, 10 July 2022 at 18:26:13 UTC, bachmeier wrote: > On Sunday, 10 July 2022 at 16:17:11 UTC, Mike Parker wrote: > > [...] > > This is really good. > > Have you considered uploading the audio to Spotify or somewhere > as a podcast? No idea what that would involve, but for a lot of > us there are more opportunities to listen to a podcast rather > than watch a YT video. I mostly use this site: https://mp3y.download/en The intro music and the beginning of the video were great. SDB at 79 From destructionator at gmail.com Mon Jul 11 15:33:32 2022 From: destructionator at gmail.com (Adam D Ruppe) Date: Mon, 11 Jul 2022 15:33:32 +0000 Subject: D Community Conversations: Walter Bright on the Origins of D Part 1 In-Reply-To: References: Message-ID: 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! The average youtube show I watch now is over 90 minutes long and these are pretty popular so it isn't just me. (Of course, I listen to them at 2x speed...) Though, I don't expect there'd be much of a difference either way between 55 and 60 minutes anyway... it'd depend more on how it sounds and flows to see if it worth your time I guess. I do think it turned out ok as it is btw. From john.michael.hall at gmail.com Mon Jul 11 15:53:40 2022 From: john.michael.hall at gmail.com (jmh530) Date: Mon, 11 Jul 2022 15:53:40 +0000 Subject: D Community Conversations: Walter Bright on the Origins of D Part 1 In-Reply-To: References: Message-ID: 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. From no at spam.net Mon Jul 11 21:18:44 2022 From: no at spam.net (bachmeier) Date: Mon, 11 Jul 2022 21:18:44 +0000 Subject: D Community Conversations: Walter Bright on the Origins of D Part 1 In-Reply-To: References: Message-ID: On Monday, 11 July 2022 at 15:53:40 UTC, jmh530 wrote: > Many podcasts edit for the uhs and ahhs. Nothing wrong with > that. One reason is that the editing can be done automatically by services like Descript. I don't know if Mike does it manually. From no at spam.net Mon Jul 11 21:51:07 2022 From: no at spam.net (bachmeier) Date: Mon, 11 Jul 2022 21:51:07 +0000 Subject: D Community Conversations: Walter Bright on the Origins of D Part 1 In-Reply-To: References: Message-ID: On Monday, 11 July 2022 at 13:51:27 UTC, Salih Dincer wrote: > On Sunday, 10 July 2022 at 18:26:13 UTC, bachmeier wrote: >> On Sunday, 10 July 2022 at 16:17:11 UTC, Mike Parker wrote: >> >> [...] >> >> This is really good. >> >> Have you considered uploading the audio to Spotify or >> somewhere as a podcast? No idea what that would involve, but >> for a lot of us there are more opportunities to listen to a >> podcast rather than watch a YT video. > > I mostly use this site: > > https://mp3y.download/en > > The intro music and the beginning of the video were great. > > SDB at 79 I've used those tools before, but it's not the same as following a podcast on Podbean, and you're not going to get into anyone's search on the podcast services. From starcanopy at protonmail.com Tue Jul 12 03:36:42 2022 From: starcanopy at protonmail.com (StarCanopy) Date: Tue, 12 Jul 2022 03:36:42 +0000 Subject: Druntime merged into dmd repo In-Reply-To: References: Message-ID: On Saturday, 9 July 2022 at 22:24:45 UTC, max haughton wrote: > Say thank you to Iain, Mathias, Vladimir, and Martin. > > This will make D better. More details to come. I'm ignorant. Why is this significant? From starcanopy at protonmail.com Tue Jul 12 05:19:05 2022 From: starcanopy at protonmail.com (StarCanopy) Date: Tue, 12 Jul 2022 05:19:05 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Monday, 4 July 2022 at 08:34:14 UTC, Mike Parker wrote: > Walter and Atila have both talked about rethinking exceptions. > > Atila brought it up in his DConf Online 2021 talk here: > > https://youtu.be/UqW42_8kn0s?t=1429 > > You can see Walter's comments about it in the subsequent Q & A > session here: > > https://youtu.be/g26eJcs2QB0?t=1809 Thank you. I hope to see something more tangible in the future as it's an interesting area to explore. > I think that's a reasonable policy. The last thing any of us > want is to stifle debate or censor opinions, but we feel that > it's reasonable to ask people to participate in debates and > express their opinions without upsetting others. So we're going > to do our best to find a middle ground. Bit of shame you feel the need to make a change given the circumstances you've detailed. I think you've done a fine job thus far. Appreciate your response! From razvan.nitu1305 at gmail.com Tue Jul 12 07:10:17 2022 From: razvan.nitu1305 at gmail.com (RazvanN) Date: Tue, 12 Jul 2022 07:10:17 +0000 Subject: Druntime merged into dmd repo In-Reply-To: References: Message-ID: On Sunday, 10 July 2022 at 17:17:30 UTC, IGotD- wrote: > On Saturday, 9 July 2022 at 22:24:45 UTC, max haughton wrote: >> Say thank you to Iain, Mathias, Vladimir, and Martin. >> >> This will make D better. More details to come. > > Does this mean that druntime for LDC and GDC were also moved > into the same repo? Same branch? No. From razvan.nitu1305 at gmail.com Tue Jul 12 07:12:25 2022 From: razvan.nitu1305 at gmail.com (RazvanN) Date: Tue, 12 Jul 2022 07:12:25 +0000 Subject: Druntime merged into dmd repo In-Reply-To: References: Message-ID: On Tuesday, 12 July 2022 at 03:36:42 UTC, StarCanopy wrote: > On Saturday, 9 July 2022 at 22:24:45 UTC, max haughton wrote: >> Say thank you to Iain, Mathias, Vladimir, and Martin. >> >> This will make D better. More details to come. > > I'm ignorant. Why is this significant? This is not something a user is going to be affected by. But it will make it much easier for the compiler/druntime devs to do work. DMD and druntime are very strictly coupled and sometimes modifying one requires changes in the other. That lead to situations where it was practically impossible to integrate changes without temporarily breaking the CI. Moreover, it was a pain to bisect bugs that were affected by both druntime/dmd changes. From destructionator at gmail.com Wed Jul 13 20:59:00 2022 From: destructionator at gmail.com (Adam D Ruppe) Date: Wed, 13 Jul 2022 20:59:00 +0000 Subject: Blog post on extending attribute inference to more functions Message-ID: A lot of people ask for more inferred attributes - safe, nogc, etc. I have some thoughts. Inferred Attributes Run-time dispatch Function documentation Compatibility contracts Attributes dependent on arguments ABI and .di file compatibility Compile speeds Conclusion Read the details on my website here: http://dpldocs.info/this-week-in-d/Blog.Posted_2022_07_11.html I try to post something there once a week btw, but work+child can make that difficult to find time. So they are often a little late and many weeks I only post the auto-generated summary. But if you want to look down the index, you can find a lot of things I've talked about. I very rarely announce them here since I don't want to spam too much. So while you might only hear from me here a couple times a year, I am probably actually writing something on the website once or twice a month. From no at spam.net Wed Jul 13 21:42:20 2022 From: no at spam.net (bachmeier) Date: Wed, 13 Jul 2022 21:42:20 +0000 Subject: Blog post on extending attribute inference to more functions In-Reply-To: References: Message-ID: On Wednesday, 13 July 2022 at 20:59:00 UTC, Adam D Ruppe wrote: > I very rarely announce them here since I don't want to spam too > much. > > So while you might only hear from me here a couple times a > year, I am probably actually writing something on the website > once or twice a month. It would be nice if you'd spam our subreddit. There have been eight posts in the last month. From destructionator at gmail.com Wed Jul 13 22:48:27 2022 From: destructionator at gmail.com (Adam D Ruppe) Date: Wed, 13 Jul 2022 22:48:27 +0000 Subject: Blog post on extending attribute inference to more functions In-Reply-To: References: Message-ID: On Wednesday, 13 July 2022 at 21:42:20 UTC, bachmeier wrote: > It would be nice if you'd spam our subreddit. I don't like reddit. It is hard to use. Of course if someone else wanted to post, you can. I might see it and comment but no promises since the UI is just really hard to keep up on and most reddit comments are low quality. From jacobbauss at gmail.com Thu Jul 14 06:22:58 2022 From: jacobbauss at gmail.com (bauss) Date: Thu, 14 Jul 2022 06:22:58 +0000 Subject: Blog post on extending attribute inference to more functions In-Reply-To: References: Message-ID: On Wednesday, 13 July 2022 at 22:48:27 UTC, Adam D Ruppe wrote: > On Wednesday, 13 July 2022 at 21:42:20 UTC, bachmeier wrote: >> It would be nice if you'd spam our subreddit. > > I don't like reddit. It is hard to use. > It's arguably harder to use these forums From ozan.sueel at gmail.com Thu Jul 14 08:31:58 2022 From: ozan.sueel at gmail.com (Ozan =?UTF-8?B?U8O8ZWw=?=) Date: Thu, 14 Jul 2022 08:31:58 +0000 Subject: Blog post on extending attribute inference to more functions In-Reply-To: References: Message-ID: On Wednesday, 13 July 2022 at 21:42:20 UTC, bachmeier wrote: > On Wednesday, 13 July 2022 at 20:59:00 UTC, Adam D Ruppe wrote: >> I very rarely announce them here since I don't want to spam >> too much. >> >> So while you might only hear from me here a couple times a >> year, I am probably actually writing something on the website >> once or twice a month. > > It would be nice if you'd spam our subreddit. There have been > eight posts in the last month. I like this kind of spams ;-) Please more of them Regards Ozan From aldacron at gmail.com Thu Jul 14 17:23:03 2022 From: aldacron at gmail.com (Mike Parker) Date: Thu, 14 Jul 2022 17:23:03 +0000 Subject: DConf '22 Guest Keynote Details Message-ID: I've just published the title and abstract of Roberto Ierusalimschy's Day 2 keynote at: https://dconf.org/2022/index.html#day2 **Lua and Pallene** Lua is a scripting language widely used in several fields, with strong niches in games and embedded systems. Pallene is a companion language for Lua, that is, a system language specifically designed to interoperate with Lua in a scripting architecture. The first part of this talk will present the main features of Lua, in particular those that set it apart from other scripting languages: portability, simplicity, and embeddability. The second part will discuss Pallene and the concept of a companion language, which brings together ideas from scripting, jit compilation, and gradual typing, focusing on a design that aims to bring more performance for Lua programs. From rushsteve1 at rushsteve1.us Thu Jul 14 19:57:26 2022 From: rushsteve1 at rushsteve1.us (rushsteve1) Date: Thu, 14 Jul 2022 19:57:26 +0000 Subject: trash-d version 18 Message-ID: Hello! It's been a while, and few releases, since I [last posted](https://forum.dlang.org/post/nuyhauebgkximglforsw at forum.dlang.org) about `trash-d` here, so I figured I would give an update. [Version 18 was just tagged today!](https://github.com/rushsteve1/trash-d/releases/tag/18) A lot of improvements have been made since the last post, mostly of bug-fixes. Including a number by the first contributor other than me! The biggest change is that `trash-d` no longer ignores unknown options and is now roughly at parity with `rm`, with full flag compatibility. Other changes include a variety of code and tooling improvements, fleshing out documentation, and making better use of D's features like CTFE and DIP 1000. Overall the project is beginning to stabilize and development is slowing, so the next goal is to get `trash-d` packaged and available everywhere we can! I also [wrote a blog post](https://repo.rushsteve1.us/wiki?name=Developing+trash-d) about my experience working on this project, which is a re-write of a presentation I gave almost a year ago. As always feedback and suggestions are appreciated! From schveiguy at gmail.com Thu Jul 14 20:36:21 2022 From: schveiguy at gmail.com (Steven Schveighoffer) Date: Thu, 14 Jul 2022 20:36:21 +0000 Subject: Beerconf July 2022 In-Reply-To: References: Message-ID: On Saturday, 2 July 2022 at 19:52:28 UTC, Steven Schveighoffer wrote: > # BEERCONF! > > So this month is going to be a bit different. We are going to > have beerconf *early*! It's like early Christmas, but with beer > instead of presents! > > The reason for the early date is that the normal > end-of-the-month date would be just before real dconf > (literally one day before). While this might be a nice time to > get together, some of the usual participants are likely going > to be dealing with travel for dconf, or dconf itself. The dates > this month are going to be July 16-17 (in 2 weeks). Just a friendly reminder, this is happening in 2 days. See you then! -Steve From starcanopy at protonmail.com Fri Jul 15 05:46:53 2022 From: starcanopy at protonmail.com (StarCanopy) Date: Fri, 15 Jul 2022 05:46:53 +0000 Subject: Druntime merged into dmd repo In-Reply-To: References: Message-ID: On Tuesday, 12 July 2022 at 07:12:25 UTC, RazvanN wrote: > This is not something a user is going to be affected by. But it > will make it much easier for the compiler/druntime devs to do > work. DMD and druntime are very strictly coupled and sometimes > modifying one requires changes in the other. That lead to > situations where it was practically impossible to integrate > changes without temporarily breaking the CI. Moreover, it was a > pain to bisect bugs that were affected by both druntime/dmd > changes. Thank you for the elucidation! I might be wrong, but some time ago, there was talk of deprecating druntime or something to that effect, and I wondering whether this was step in that direction, but it appears that is not the case. From razvan.nitu1305 at gmail.com Fri Jul 15 06:49:28 2022 From: razvan.nitu1305 at gmail.com (RazvanN) Date: Fri, 15 Jul 2022 06:49:28 +0000 Subject: Druntime merged into dmd repo In-Reply-To: References: Message-ID: On Friday, 15 July 2022 at 05:46:53 UTC, StarCanopy wrote: > On Tuesday, 12 July 2022 at 07:12:25 UTC, RazvanN wrote: >> This is not something a user is going to be affected by. But >> it will make it much easier for the compiler/druntime devs to >> do work. DMD and druntime are very strictly coupled and >> sometimes modifying one requires changes in the other. That >> lead to situations where it was practically impossible to >> integrate changes without temporarily breaking the CI. >> Moreover, it was a pain to bisect bugs that were affected by >> both druntime/dmd changes. > > Thank you for the elucidation! > I might be wrong, but some time ago, there was talk of > deprecating druntime or something to that effect, and I > wondering whether this was step in that direction, but it > appears that is not the case. No, there is no talk about deprecating druntime. However, work is being done to templatize druntime as much as possible so that it becomes a pay-as-you-go library. From rikki at cattermole.co.nz Sat Jul 16 02:56:09 2022 From: rikki at cattermole.co.nz (rikki cattermole) Date: Sat, 16 Jul 2022 14:56:09 +1200 Subject: Beerconf July 2022 In-Reply-To: References: Message-ID: I've been getting a few pings about setting this up, so here it is: https://meet.jit.si/Dlang2022JulyBeerConf No password. From ajieskola at gmail.com Sat Jul 16 16:07:36 2022 From: ajieskola at gmail.com (Dukc) Date: Sat, 16 Jul 2022 16:07:36 +0000 Subject: D Community Conversations: Walter Bright on the Origins of D Part 1 In-Reply-To: References: Message-ID: On Sunday, 10 July 2022 at 16:17:11 UTC, Mike Parker wrote: > I'll plan to do one of these every other month, so I'll be > reaching out to people around the D community as time goes on. This was great, looking forward to more of these. I've thought that you could well write a blog series about D history. This is pretty much it, except that it's a video series, not a post series. Plus you're also giving a talk about a similar subject at DConf. From newshound2 at digitalmars.com Sat Jul 16 18:34:35 2022 From: newshound2 at digitalmars.com (Walter Bright) Date: Sat, 16 Jul 2022 11:34:35 -0700 Subject: D Community Conversations: Walter Bright on the Origins of D Part 1 In-Reply-To: References: Message-ID: On 7/10/2022 8:26 PM, Mike Parker wrote: > On Sunday, 10 July 2022 at 18:26:13 UTC, bachmeier wrote: >> Have you considered uploading the audio to Spotify or somewhere as a podcast? >> No idea what that would involve, but for a lot of us there are more >> opportunities to listen to a podcast rather than watch a YT video. > > That hadn't crossed my mind. I'll look into it. A podcast channel for D stuff sounds like a great idea! From newshound2 at digitalmars.com Sat Jul 16 18:36:41 2022 From: newshound2 at digitalmars.com (Walter Bright) Date: Sat, 16 Jul 2022 11:36:41 -0700 Subject: D Community Conversations: Walter Bright on the Origins of D Part 1 In-Reply-To: References: Message-ID: On 7/11/2022 2:18 PM, bachmeier wrote: > One reason is that the editing can be done automatically by services like > Descript. I don't know if Mike does it manually. Doing it automatically means then you've got to spend time comparing the two to ensure it cut in the right places :-( From animuspexus at protonmail.com Sun Jul 17 18:33:47 2022 From: animuspexus at protonmail.com (AnimusPEXUS) Date: Sun, 17 Jul 2022 18:33:47 +0000 Subject: Blog post on extending attribute inference to more functions In-Reply-To: References: Message-ID: On Wednesday, 13 July 2022 at 20:59:00 UTC, Adam D Ruppe wrote: > I'm holding this Your post for a few days already in my mind, ADR. I've just coded something and come with the idea of @todo/@fixme/@issueid attributes, so compiler write messages each time it finds those. Just as a thought.. maybe It can be useful, although it's already can be done with pragma(msg, "txt").. From none at none.com Sun Jul 17 19:58:03 2022 From: none at none.com (LeMondaide) Date: Sun, 17 Jul 2022 19:58:03 +0000 Subject: How do I download the Windows DMD installer? Message-ID: When I try (https://dlang.org/ or https://dlang.org/download.html) I am sent here: https://s3.us-west-2.amazonaws.com/downloads.dlang.org/releases/2022/dmd-2.100.1.exe and get this message "AccessDeniedAccess Denied4TMZ12PKCBCER6SAQQ7FpshcuoQ3ied0qGEHZ+lSz+qD9+aJmqH24qD5pkCWrGANGD6Lk6eT5d4wAG1n3kYvhWNJsig=" I have not found an alternative download location. From Bastiaan at Veelo.net Sun Jul 17 21:37:07 2022 From: Bastiaan at Veelo.net (Bastiaan Veelo) Date: Sun, 17 Jul 2022 21:37:07 +0000 Subject: How do I download the Windows DMD installer? In-Reply-To: References: Message-ID: On Sunday, 17 July 2022 at 19:58:03 UTC, LeMondaide wrote: > When I try (https://dlang.org/ or > https://dlang.org/download.html) I am sent here: > https://s3.us-west-2.amazonaws.com/downloads.dlang.org/releases/2022/dmd-2.100.1.exe and get this message "AccessDeniedAccess Denied4TMZ12PKCBCER6SAQQ7FpshcuoQ3ied0qGEHZ+lSz+qD9+aJmqH24qD5pkCWrGANGD6Lk6eT5d4wAG1n3kYvhWNJsig=" > > I have not found an alternative download location. The download for 2.100.1 is currently broken. Find 2.100.0 from http://downloads.dlang.org/releases/2022/ for now. -- Bastiaan. From vladimmi at gmail.com Sun Jul 17 21:37:57 2022 From: vladimmi at gmail.com (Vladimir Marchevsky) Date: Sun, 17 Jul 2022 21:37:57 +0000 Subject: The D Programming Language Vision Document In-Reply-To: References: Message-ID: On Saturday, 9 July 2022 at 23:40:21 UTC, monkyyy wrote: > Its not curated Well, limit yourself to usage of `std` or `phobos` or whatever official implementation is called - and voila, it's curated. > It changes the compiler options So? Most of the people prefer to have build tool managing possible compiler options for them instead of typing the manually for each compiler, digging through all dependencies involved to find required options for them, etc, finally resulting in reinventing the same build tool. Especially when you have an option to manually override anything you dont like. > and its randomly configured in js Dub has nothing common to JS. If you mean `dub.json` format - well, JSON is not a JS. And if you are allergic to human-readable formats, you can always use `dub.sdl` flavor. From none at none.com Sun Jul 17 22:02:03 2022 From: none at none.com (LeMondaide) Date: Sun, 17 Jul 2022 22:02:03 +0000 Subject: How do I download the Windows DMD installer? In-Reply-To: References: Message-ID: On Sunday, 17 July 2022 at 21:37:07 UTC, Bastiaan Veelo wrote: > > Find 2.100.0 from http://downloads.dlang.org/releases/2022/ for > now. Thanks. From Bastiaan at Veelo.net Mon Jul 18 08:33:15 2022 From: Bastiaan at Veelo.net (Bastiaan Veelo) Date: Mon, 18 Jul 2022 08:33:15 +0000 Subject: [i18n] Gettext 1.0.1 released Message-ID: Two years ago, H. S. Teoh presented a proof of concept for [automatic extraction of gettext-style translation strings](https://forum.dlang.org/post/mailman.2526.1585832475.31109.digitalmars-d at puremagic.com). I recently combined that idea with the existing [mofile](https://code.dlang.org/packages/mofile) package for reading translation tables in GNU gettext format, and the result is a feature rich solution for the support of multiple natural languages in D applications: https://code.dlang.org/packages/gettext. Perhaps not surprisingly, it can do more than GNU gettext itself. I'd like to thank Steven Schveighoffer and Adam Ruppe for [valuable forum assistance](https://forum.dlang.org/post/afkbwsdrspndwgkairaz at forum.dlang.org), and SARC B.V. for sponsoring. Some extracts from the [readme](https://github.com/veelo/gettext#readme) are included below: # Features - Concise translation markers that can be aliased to your preference. - All marked strings that are seen by the compiler are extracted automatically. - All (current and future) [D string literal formats](https://dlang.org/spec/lex.html#string_literals) are supported. - Static initializers of fields, constants, immutables, manifest constants and anonimous enums can be marked as translatable (a D specialty). - Concatenations of translatable strings, untranslated strings and single chars are supported, even in initializers. - Arrays of translatable strings are supported, also when statically initialized. - Plural forms are language dependent, and play nice with format strings. - Multiple identical strings are translated once, unless they are given different contexts. - Notes to the translator can be attached to individual translatable strings. - Code occurrences of strings are communicated to the translator. - Available languages are discovered and selected at run-time. - Platfom independent, not linked with C libraries. - Automated generation of the translation table template. - Automated merging into existing translations (requires [GNU `gettext` utilities](https://www.gnu.org/software/gettext/)). - Automated generation of binary translation tables (requires [GNU `gettext` utilities](https://www.gnu.org/software/gettext/)). - Includes utility for listing unmarked strings in the project. # Usage ## Marking strings Prepend `tr!` in front of every string literal that needs to be translated. For instance: ```d writeln(tr!"This string is to be translated"); writeln("This string will remain untranslated."); ``` ## Plural forms Sentences that should change in plural form depending on a number should supply both singlular and plural forms with the number like this: ```d // Before: writefln("%d green bottle(s) hanging on the wall", n); // After: writeln(tr!("one green bottle hanging on the wall", "%d green bottles hanging on the wall")(n)); ``` Note that the format specifier (`%d`, or `%s`, etc.) is optional in the singular form. Many languages have not just two forms like the English language does, and translations in those languages can supply all the forms that the particular language requires. This is handled by the translator, and is demonstrated in [the example below](https://github.com/veelo/gettext#example-1). ## Custom markers If `tr` is too verbose for you, you can change it to whatever you want: ```d import gettext : _ = tr; writeln(_!"No green bottles..."); ``` ## Marking format strings Translatable strings can be format strings, used with `std.format` and `std.stdio.writefln` etc. These format strings do support plural forms, but the argument that determines the form must be supplied to `tr` and not to `format`. The corresponding format specifier will not be seen by `format` as it will have been replaced with a string by `tr`. Example: ```d format(tr!("Welcome %s, you may make a wish", "Welcome %s, you may make %d wishes")(n), name); ``` The format specifier that selects the form is the last specifier in the format string (here `%d`). In many sentences, however, the specifier that should select the form cannot be the last. In these cases, format specifiers must be given a position argument, where the highest position determines the form: ```d foreach (i, where; [tr!"hand", tr!"bush"]) format(tr!("One bird in the %1$s", "%2$d birds in the %1$s")(i + 1), where); ``` Again, the specifier with the highest position argument will never be seen by `format`. On a side note, some translations may need a reordering of words, so translators may need to use position arguments in their translated format strings anyway. Note: Specifiers with and without a position argument must not be mixed. ## Concatenations Translators will be able to produce the best translations if they get to work with full sentences, like ```d auto message = format(tr!`Could not open the file "%s" for reading.`, file); ``` However, in support of legacy code, concatenations of strings do work: ```d auto message = tr!`Could not open the file "` ~ file ~ tr!`" for reading.`; ``` ## Passing attributes Optionally, two kinds of attributes can be passed to `tr`, in the form of an associative array initializer. These are for passing notes to the translator and for disambiguating identical sentences with different meanings. ### Passing notes to the translator Sometimes a sentence can be interpreted to mean different things, and then it is important to be able to clarify things for the translator. Here is an example of how to do this: ```d auto name = tr!("Walter Bright", [Tr.note: "Proper name. Phonetically: ?w?lt?r bra?t"]); ``` The GNU `gettext` manual has a section [about the translation of proper names](https://www.gnu.org/software/gettext/manual/html_node/Names.html). ### Disambiguate identical sentences Multiple occurrences of the same sentence are combined into one translation by default. In some cases, that may not work well. Some language, for example, may need to translate identical menu items in different menus differently. These can be disambiguated by adding a context like so: ```d auto labelOpenFile = tr!("Open", [Tr.context: "Menu|File"]); auto labelOpenPrinter = tr!("Open", [Tr.context: "Menu|File|Printer"]); ``` Notes and comments can be combined in any order: ```d auto message1 = tr!("Review the draft.", [Tr.context: "document"]); auto message2 = tr!("Review the draft.", [Tr.context: "nautical", Tr.note: `Nautical term! "Draft" = how deep ` ~ `the bottom of the ship is below ` ~ `the water level.`]); ``` ## Selecting a translation Use the [following functions](https://gettext.dpldocs.info/v1.0.1/gettext.html#function) to discover translation tables, get the language code for a table and activate a translation: ```d string[] availableLanguages(string moPath = null) string languageCode() @safe string languageCode(string moFile) @safe void selectLanguage(string moFile) @safe ``` Note that any translation that happens before a language is selected, results in the value of the hard coded string. # There's more See the [full readme](https://github.com/veelo/gettext#readme) for adding and updating translations, impact on footprint and performance, limitations, and lots more. Here's the result of two runs of one of the [examples](https://github.com/veelo/gettext/tree/main/tests): ``` Hello! My name is Joe. I'm counting one apple. Hello! My name is Schmoe. I'm counting 3 apples. Hello! My name is Jane. I'm counting 5 apples. Hello! My name is Doe. I'm counting 7 apples. ``` ``` ??????! ???? ????? Joe. ? ????? 1 ??????. ??????! ???? ????? Schmoe. ? ????? 3 ??????. ??????! ???? ????? Jane. ? ????? 5 ?????. ??????! ???? ????? Doe. ? ????? 7 ?????. ``` Notice how the translation of "apple" in the last translation changes with three different endings dependent on the number of apples. -- Bastiaan. From singingbush at hotmail.com Mon Jul 18 11:58:24 2022 From: singingbush at hotmail.com (singingbush) Date: Mon, 18 Jul 2022 11:58:24 +0000 Subject: Intellij D Language plugin v1.28.2 Message-ID: I've just pushed a new release to the Jetbrains plugin repository: https://plugins.jetbrains.com/plugin/8115-d-language/ Again there's a bunch of fixes: https://github.com/intellij-dlanguage/intellij-dlanguage/milestone/34?closed=1 but there's a growing list of issues to work through: https://github.com/intellij-dlanguage/intellij-dlanguage/issues So if you have interest in improving the D development experience on Intellij please get involved. From pro.mathias.lang at gmail.com Mon Jul 18 16:07:02 2022 From: pro.mathias.lang at gmail.com (Mathias LANG) Date: Mon, 18 Jul 2022 16:07:02 +0000 Subject: Vibe.d v0.9.5 released! Message-ID: Hi everyone, A new version of Vibe.d has been released today. You can see the list of changes [on Github](https://github.com/vibe-d/vibe.d/releases/tag/v0.9.5). Of particular interest to me is the bump of the deimos/OpenSSL dependency to v3.x.x. deimos/OpenSSL v3.x.x is something I worked on a few months ago when Ubuntu 22.04, which includes OpenSSL3 was released. The code in Deimos is now compatible with all OpenSSL versions (v1.0.2 through v3), removing the need for a lot of workaround OpenSSL users previous needed to support multiple versions. With this version, projects depending on Vibe.d and using OpenSSL directly can upgrade to the newest version and take full advantage of it. And if you're an Ubuntu 22.04 user, or need to support it, it will make your life a whole lot simpler! Note that while using dub, the OpenSSL version is auto-detected. If that detection fails, or if you are using another build system (or want to force a specific version), make sure to check [the compatibiliy guide](https://github.com/D-Programming-Deimos/openssl#compatibility) of deimos/OpenSSL. From Bastiaan at Veelo.net Mon Jul 18 22:48:27 2022 From: Bastiaan at Veelo.net (Bastiaan Veelo) Date: Mon, 18 Jul 2022 22:48:27 +0000 Subject: Blog post on extending attribute inference to more functions In-Reply-To: References: Message-ID: On Sunday, 17 July 2022 at 18:33:47 UTC, AnimusPEXUS wrote: > I've just coded something and come with the idea of > @todo/@fixme/@issueid attributes, so compiler write messages > each time it finds those. Just as a thought.. maybe It can be > useful, although it's already can be done with pragma(msg, > "txt").. I abuse `@deprecated` for that purpose in my own code, to remind myself of some holes that need patching. ? Bastiaan. From madric at gmail.com Mon Jul 18 22:51:06 2022 From: madric at gmail.com (Vijay Nayar) Date: Mon, 18 Jul 2022 22:51:06 +0000 Subject: Vibe.d v0.9.5 released! In-Reply-To: References: Message-ID: On Monday, 18 July 2022 at 16:07:02 UTC, Mathias LANG wrote: > Hi everyone, > A new version of Vibe.d has been released today. > You can see the list of changes [on > Github](https://github.com/vibe-d/vibe.d/releases/tag/v0.9.5). > > Of particular interest to me is the bump of the deimos/OpenSSL > dependency to v3.x.x. Great news! I've definitely run into the SSL configuration issues before, and this should help make Vibe.d adoption easier for new users. From pro.mathias.lang at gmail.com Tue Jul 19 01:37:43 2022 From: pro.mathias.lang at gmail.com (Mathias LANG) Date: Tue, 19 Jul 2022 01:37:43 +0000 Subject: D-YAML v0.9.0 released (DIP1000 compatibility) Message-ID: Hi everyone, A few days ago, I released [v0.9.0](https://github.com/dlang-community/D-YAML/releases/tag/v0.9.0) of D-YAML. D-YAML is the most used package for parsing YAML file, and part of dlang-community. This new release makes the library compatible with DIP1000, which required getting rid of Variant (but forking `std.sumtype`). From first.last at gmail.com Tue Jul 19 09:55:52 2022 From: first.last at gmail.com (Guillaume Piolat) Date: Tue, 19 Jul 2022 09:55:52 +0000 Subject: Blog post on extending attribute inference to more functions In-Reply-To: References: Message-ID: On Monday, 18 July 2022 at 22:48:27 UTC, Bastiaan Veelo wrote: > I abuse `@deprecated` for that purpose in my own code, to > remind myself of some holes that need patching. > > ? Bastiaan. I put tags in comments, to text search later. Usually: ``` // TODO: actually blocks a release // PERF: a TODO but performance related // MAYDO: a TODO but too tiring // HACK: a TODO for a bad workaround // FUTURE: a TODO but long term ``` A way to have them be "first-class" would be interesting. Though, technically you can with UDAs. From ola.fosheim.grostad at gmail.com Tue Jul 19 13:20:57 2022 From: ola.fosheim.grostad at gmail.com (Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=) Date: Tue, 19 Jul 2022 13:20:57 +0000 Subject: Blog post on extending attribute inference to more functions In-Reply-To: References: Message-ID: On Tuesday, 19 July 2022 at 09:55:52 UTC, Guillaume Piolat wrote: > I put tags in comments, to text search later. > Usually: > > ``` > // TODO: actually blocks a release > ``` Yes, this form is also recognized by some editors, might even compile a todo-list in the IDE interface for you (with no setup). From ogion.art at gmail.com Tue Jul 19 20:20:29 2022 From: ogion.art at gmail.com (Ogi) Date: Tue, 19 Jul 2022 20:20:29 +0000 Subject: [i18n] Gettext 1.0.1 released In-Reply-To: References: Message-ID: On Monday, 18 July 2022 at 08:33:15 UTC, Bastiaan Veelo wrote: > ... Is this tested on Windows? ``` Performing "debug" build using C:\Apps\dmd\windows\bin64\dmd.exe for x86_64. gettexttest ~master: building configuration "default"... Running pre-build commands... Performing "debug" build using C:\Apps\dmd\windows\bin64\dmd.exe for x86_64. gettexttest ~master: target for configuration "xgettext" is up to date. Target is a library. Skipping execution. Command failed with exit code 2: dub run --config=xgettext ``` Gettext is installed and present in PATH. From Bastiaan at Veelo.net Wed Jul 20 09:27:01 2022 From: Bastiaan at Veelo.net (Bastiaan Veelo) Date: Wed, 20 Jul 2022 09:27:01 +0000 Subject: [i18n] Gettext 1.0.1 released In-Reply-To: References: Message-ID: On Tuesday, 19 July 2022 at 20:20:29 UTC, Ogi wrote: > Is this tested on Windows? Yes, it is developed on Windows. Do the included tests work for you? > ``` > Target is a library. Skipping execution. > ``` That is not right. Are you developing a library or an application? If you cannot get it to work, feel free to [open an issue](https://github.com/veelo/gettext/issues) and include your `dub.json`. -- Bastiaan. From noone at nowhere.com Wed Jul 20 18:43:05 2022 From: noone at nowhere.com (kinke) Date: Wed, 20 Jul 2022 18:43:05 +0000 Subject: LDC 1.30.0 Message-ID: Glad to announce LDC 1.30.0. Major changes: - Based on D 2.100.1. - LLVM for prebuilt packages bumped to v14.0.3. All target architectures supported by LLVM are enabled now. - Dropped LDC ltsmaster (v0.17.x) as supported host compiler. Like DMD, the min D version for bootstrapping is v2.079 (or GDC v9.x) now. - Dropped support for LLVM < 9. - New LeakSanitizer support via `-fsanitize=leak`. - New prebuilt universal macOS package, runnable on both x86_64 and arm64, and enabling x86_64/arm64 macOS/iOS cross-compilation targets out of the box. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.30.0 Thanks to all contributors & sponsors! From hsteoh at qfbox.info Wed Jul 20 19:00:49 2022 From: hsteoh at qfbox.info (H. S. Teoh) Date: Wed, 20 Jul 2022 12:00:49 -0700 Subject: LDC 1.30.0 In-Reply-To: References: Message-ID: On Wed, Jul 20, 2022 at 06:43:05PM +0000, kinke via Digitalmars-d-announce wrote: > Glad to announce LDC 1.30.0. Major changes: > > - Based on D 2.100.1. > - LLVM for prebuilt packages bumped to v14.0.3. All target architectures > supported by LLVM are enabled now. > - Dropped LDC ltsmaster (v0.17.x) as supported host compiler. Like DMD, the > min D version for bootstrapping is v2.079 (or GDC v9.x) now. > - Dropped support for LLVM < 9. > - New LeakSanitizer support via `-fsanitize=leak`. > - New prebuilt universal macOS package, runnable on both x86_64 and arm64, > and enabling x86_64/arm64 macOS/iOS cross-compilation targets out of the > box. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.30.0 > > Thanks to all contributors & sponsors! Awesome stuff! Thanks LDC team for all their hard work in continuing to bring us a top-of-the-line D compiler! --T From christian.koestlin at gmail.com Thu Jul 21 10:18:22 2022 From: christian.koestlin at gmail.com (=?UTF-8?Q?Christian_K=c3=b6stlin?=) Date: Thu, 21 Jul 2022 12:18:22 +0200 Subject: LDC 1.30.0 In-Reply-To: References: Message-ID: On 2022-07-20 20:43, kinke wrote: > Glad to announce LDC 1.30.0. Major changes: > > - Based on D 2.100.1. > - LLVM for prebuilt packages bumped to v14.0.3. All target architectures > supported by LLVM are enabled now. > - Dropped LDC ltsmaster (v0.17.x) as supported host compiler. Like DMD, > the min D version for bootstrapping is v2.079 (or GDC v9.x) now. > - Dropped support for LLVM < 9. > - New LeakSanitizer support via `-fsanitize=leak`. > - New prebuilt universal macOS package, runnable on both x86_64 and > arm64, and enabling x86_64/arm64 macOS/iOS cross-compilation targets out > of the box. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.30.0 > > Thanks to all contributors & sponsors! Thanks for the new release. On a sidenote I am having problem downloading any 2.100.1 dmd version from dlang.org. Is it just me? Old releases are available on http://downloads.dlang.org/releases but not the 2.100.1. Kind regards, Christian From Jesse.K.Phillips+D at gmail.com Thu Jul 21 14:24:09 2022 From: Jesse.K.Phillips+D at gmail.com (Jesse Phillips) Date: Thu, 21 Jul 2022 14:24:09 +0000 Subject: [i18n] Gettext 1.0.1 released In-Reply-To: References: Message-ID: Nice. I've really enjoyed gettext in C# in my verification of an application without gettext usage. From j at j.nl Thu Jul 21 17:58:17 2022 From: j at j.nl (Johan) Date: Thu, 21 Jul 2022 17:58:17 +0000 Subject: Godbolt now shows optimization pipeline steps for LDC Message-ID: Godbolt now shows optimization pipeline steps for LDC, giving great insight into the LLVM optimization process, including some D-specific optimization passes (by LDC). See an example with D-specific optimization (GC to stack): https://d.godbolt.org/z/rjbEPaehn cheers, Johan From ola.fosheim.grostad at gmail.com Thu Jul 21 18:03:45 2022 From: ola.fosheim.grostad at gmail.com (Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?=) Date: Thu, 21 Jul 2022 18:03:45 +0000 Subject: Godbolt now shows optimization pipeline steps for LDC In-Reply-To: References: Message-ID: On Thursday, 21 July 2022 at 17:58:17 UTC, Johan wrote: > Godbolt now shows optimization pipeline steps for LDC, giving > great insight into the LLVM optimization process, including Thanks for pointing this out, this was fun! From ogion.art at gmail.com Thu Jul 21 20:09:40 2022 From: ogion.art at gmail.com (Ogi) Date: Thu, 21 Jul 2022 20:09:40 +0000 Subject: [i18n] Gettext 1.0.1 released In-Reply-To: References: Message-ID: On Wednesday, 20 July 2022 at 09:27:01 UTC, Bastiaan Veelo wrote: > That is not right. Are you developing a library or an > application? Hmm, I got it working by explicitly setting `targetType` to `executable`. It seems configuration recommended by Readme breaks Dub?s automatic target recognition. From james.blachly at gmail.com Sat Jul 23 01:28:16 2022 From: james.blachly at gmail.com (James Blachly) Date: Fri, 22 Jul 2022 21:28:16 -0400 Subject: LDC 1.30.0 In-Reply-To: References: Message-ID: On 7/21/22 6:18 AM, Christian K?stlin wrote: > Thanks for the new release. > On a sidenote I am having problem downloading any 2.100.1 dmd version > from dlang.org. Is it just me? Old releases are available on > http://downloads.dlang.org/releases but not the 2.100.1. > > Kind regards, > Christian There is a known problem with this for at least a week or two. I believe ryukk_ filed a PR to fix, not sure if has been merged yet. From electricface at qq.com Mon Jul 25 02:59:41 2022 From: electricface at qq.com (electricface) Date: Mon, 25 Jul 2022 02:59:41 +0000 Subject: From the D Blog -- Interfacing D with C: Strings Part One Message-ID: https://forum.dlang.org/post/gsztclsvxdhnvfhbiwhs at forum.dlang.org On Thursday, 27 May 2021 at 03:54:11 UTC, ??????? ?????? wrote: > On Thursday, 27 May 2021 at 03:52:32 UTC, ??????? ?????? wrote: >> On Thursday, 27 May 2021 at 03:40:02 UTC, ??????? ?????? wrote: >>> On Wednesday, 26 May 2021 at 16:35:36 UTC, Ali ?ehreli wrote: >>>> On 5/25/21 9:00 PM, ??????? ?????? wrote: >>>> >> // cString[ $-1 ] != '\'0'; > > // cString[ $ ] != '\'0'; Looking forward to part 2 and part 3 From aldacron at gmail.com Mon Jul 25 13:41:59 2022 From: aldacron at gmail.com (Mike Parker) Date: Mon, 25 Jul 2022 13:41:59 +0000 Subject: From the D Blog -- Interfacing D with C: Strings Part One In-Reply-To: References: Message-ID: On Monday, 25 July 2022 at 02:59:41 UTC, electricface wrote: > https://forum.dlang.org/post/gsztclsvxdhnvfhbiwhs at forum.dlang.org > > Looking forward to part 2 and part 3 Me, too! I'm hoping to make time for this and a couple of other series that are long overdue for updates before the end of the year. From aldacron at gmail.com Mon Jul 25 13:52:51 2022 From: aldacron at gmail.com (Mike Parker) Date: Mon, 25 Jul 2022 13:52:51 +0000 Subject: DConf '22 Livestream Links Message-ID: 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: * Day 1: https://youtu.be/V6KFtzF2Hx8 * Day 2: https://youtu.be/04gJXpJ1i8M * Day 3: https://youtu.be/ksNGwLTe0Ps Thanks to Symmetry Investments for making this possible once again. I'm very happy the time has come to announce this because it means I'm heading to the airport in a few hours for my flight to London. I'm making an extended vacation out of this, so excluding the four days of DConf I'll be mostly incommunicado until after August 17th. However, later this week I do plan to post the summary of the quarterly meeting we held on July 8. And I'll still check in periodically on the forums and my email, but please expect that any communication with me may have a delayed response. If you're going to London, I look forward to seeing you there! Don't forget we've got a limited open tab at The Fox pub (directions [at DConf.org]) each night of August 1, 2, and 3 courtesy of Funkwerk. Flash your DConf name tag at the staff for each round you order for yourself until the tab runs out! From spam at here.lot Mon Jul 25 18:56:19 2022 From: spam at here.lot (Kagamin) Date: Mon, 25 Jul 2022 18:56:19 +0000 Subject: LDC 1.30.0 In-Reply-To: References: Message-ID: On Thursday, 21 July 2022 at 10:18:22 UTC, Christian K?stlin wrote: > On a sidenote I am having problem downloading any 2.100.1 dmd > version from dlang.org. A great moment, ldc is released before dmd :D From newshound2 at digitalmars.com Thu Jul 28 07:06:57 2022 From: newshound2 at digitalmars.com (Walter Bright) Date: Thu, 28 Jul 2022 00:06:57 -0700 Subject: LDC 1.30.0 In-Reply-To: References: Message-ID: On 7/20/2022 11:43 AM, kinke wrote: > Glad to announce LDC 1.30.0. Yay! From alphaglosined at gmail.com Thu Jul 28 16:09:46 2022 From: alphaglosined at gmail.com (Rikki Cattermole) Date: Thu, 28 Jul 2022 16:09:46 +0000 Subject: DConf 2022 pre+watch party! Message-ID: Hello everyone! It is back, DConf IRL. To celebrate we will have a bit of a pre-party over in the Discord voice channel, as well as a bit of a watch party going on during the conference live streams. We may switch over to Jitsi later on depending on how the IRL BeerConf goes and if someone ends up joining from there. Discord invite link: https://discord.gg/bMZk9Q4 It all starts tomorrow, so stock up because it's going to be 6 days of D! From first.last at gmail.com Fri Jul 29 10:59:02 2022 From: first.last at gmail.com (Guillaume Piolat) Date: Fri, 29 Jul 2022 10:59:02 +0000 Subject: gamut v0.0.7 ask for what you want Message-ID: Using D and images I ended up with a problem. The problem was that parts of my code wanted to decode just specific image metadata, other just pixels. Others were interested in 10-bit, and others in this or that format. Finally, some were concerned about aligned layout and others just wanted "dense" pixels without gap between rows. The goal of Gamut is to cater to a reasonably large set of needs with D and images. I'll be at Dconf if you want to **ask for your particular use case.** The library is not super usable yet, it's still in the design phase. **Features:** - monomorphic image type, as opposed to a templated type, for all pixel format types The problem is that templated image library ends up taking compile-time when used at scale. The Image type will also act as "view". - loading images: PNG (8-bit and 10-bit) / JPEG (baseline and progressive) / QOI - writing images: PNG (8-bit) / JPEG (baseline) / BC7 in DDS / QOI - `nothrow @nogc`, all structs, no exceptions, standalone except `intel-intrinsics`. - (near future): control over the image layout for easy SIMD access. For example, you can ask for: * 64-bytes aligned row of pixels (for aligned SIMD access), * or a border of 2 pixels around the data (for resampling), * trailing pixels after each row (for unaligned SIMD access), * and that each row has a multiple of 4x pixels (for SIMD) - API inspired by FreeImage. Gamut has support for an evolving "QOIX" format that mostly improves upon QOI. Can be interesting if you have lots of PNG to distribute and want more compression than QOI. In the future I'd like to extend QOIX to support 10-bit. DUB: https://code.dlang.org/packages/gamut GitHub: https://github.com/AuburnSounds/gamut From ryuukk.dev at gmail.com Fri Jul 29 14:28:55 2022 From: ryuukk.dev at gmail.com (ryuukk_) Date: Fri, 29 Jul 2022 14:28:55 +0000 Subject: gamut v0.0.7 ask for what you want In-Reply-To: References: Message-ID: That's a very cool library, i might ditch stb_image for yours, thanks for sharing! I went ahead and added it to the list of libraries that supports QOI file format here: https://github.com/phoboslab/qoi/pull/235 One suggestion, have a little struct with function pointers for malloc/free/realloc, so that we can plug our own allocator From murilomiranda92 at hotmail.com Sat Jul 30 04:17:44 2022 From: murilomiranda92 at hotmail.com (Murilo) Date: Sat, 30 Jul 2022 04:17:44 +0000 Subject: DUB packages announce Telegram bot In-Reply-To: References: Message-ID: On Sunday, 22 April 2018 at 07:49:00 UTC, Denis Feklushkin wrote: > Hi! > > I also made a tool which periodically monitors code.dlang.org > for new packages and a notifies its Telegram subscribers. > > To subscribe just write something to @dlang_announce_bot > Also it can be added to groups. > > Code: https://github.com/denizzzka/paper_plane_bot Hi Denis, I'm checking out the source code on github to try to figure it out but could you help me learn how to make a Telegram bot? From menodinulla at gmail.com Sun Jul 31 02:46:47 2022 From: menodinulla at gmail.com (godmyoh) Date: Sun, 31 Jul 2022 02:46:47 +0000 Subject: Another Windows Bindings by win32metadata Message-ID: Hi everyone! I have been using the rumbu13's Windows Bindings (https://github.com/rumbu13/windows-d), but it does not work well with the latest metadata. So I have created my own bindings. https://github.com/godmyoh/windows-win32-d This is incomplete due to my lack of knowledge. Opinions are welcome! From ibuclaw at gdcproject.org Sun Jul 31 13:04:37 2022 From: ibuclaw at gdcproject.org (Iain Buclaw) Date: Sun, 31 Jul 2022 13:04:37 +0000 Subject: DConf 2022 pre+watch party! In-Reply-To: References: Message-ID: On Thursday, 28 July 2022 at 16:09:46 UTC, Rikki Cattermole wrote: > Hello everyone! > > It is back, DConf IRL. > > To celebrate we will have a bit of a pre-party over in the > Discord voice channel, as well as a bit of a watch party going > on during the conference live streams. > > We may switch over to Jitsi later on depending on how the IRL > BeerConf goes and if someone ends up joining from there. > > Discord invite link: https://discord.gg/bMZk9Q4 > > It all starts tomorrow, so stock up because it's going to be 6 > days of D! How did this work out? :-) Shall we start a jitsi meet-up? From first.last at gmail.com Sun Jul 31 13:23:07 2022 From: first.last at gmail.com (Guillaume Piolat) Date: Sun, 31 Jul 2022 13:23:07 +0000 Subject: gamut v0.0.7 ask for what you want In-Reply-To: References: Message-ID: On Friday, 29 July 2022 at 14:28:55 UTC, ryuukk_ wrote: > > One suggestion, have a little struct with function pointers for > malloc/free/realloc, so that we can plug our own allocator Hello, thanks for the heads-up! A few question about your use case (I believe you are using WebASM), to better understand. - Is it just for image pixel data, or all that could be allocated? - Are you OK with a global allocator struct that you assign in an initialization call to the library? Or you want each image to know about its own allocator potentially. - Are you asking that it is WebASM compatible? I'm not sure how feasible that is, because of the amount of core.stdc that is used. From rikki at cattermole.co.nz Sun Jul 31 14:54:18 2022 From: rikki at cattermole.co.nz (rikki cattermole) Date: Mon, 1 Aug 2022 02:54:18 +1200 Subject: DConf 2022 pre+watch party! In-Reply-To: References: Message-ID: On 01/08/2022 1:04 AM, Iain Buclaw wrote: > How did this work out? :-) It has been low turn out so far, but since everything has had low amount of chatter that isn't too surprising. > Shall we start a jitsi meet-up? I'm waiting to hear about the IRL beerconf, see if somebody will join in from there. If they do yeah we should.