Re: Beta 2.098.0
On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote: On 10/5/2021 10:36 AM, ag0aep6g wrote: it's also true that Walter prioritizes new features instead (ImportC is the latest fad) ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Unfortunately, ImportC is useless if it only half works. It has to work with existing C headers, which is why I'm concentrating on it to get to that point. Lack of ImportC has wasted a *lot* of developer time, making it a high leverage investment of time. Just think of all the time lost doing manual conversion of .h files, and then doing them again and again as they evolve. Then not one, not two, but *three* different automated programs were developed to try and resolve this (one of which I wrote). Then think of all the projects *not* done because of the barrier of trying to deal with several thousand lines of .h files. The Diemos project was an effort to crowdsource conversion of .h files to D, but it just was not adequate. In summary, ImportC is totally worth the effort. I should have done it 15 years ago. ImportC is more important to me then @live, because I think I will have a very hard time to make @live to work in my project. I suppose with ImportC, I an use all the meta programming ability with C header file ? (for example find all struct from a header.h and every details at CTFE time)
Re: Beta 2.098.0
On 10/19/2021 10:08 PM, max haughton wrote: Why is compiling zlib a goalpost for *Import*C? Dogfooding.
Re: Beta 2.098.0
On Wednesday, 20 October 2021 at 01:48:24 UTC, Walter Bright wrote: On 10/19/2021 6:35 AM, Timon Gehr wrote: I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise. Timon and I famously disagree over the concept behind @live. Nevertheless, we do agree that ImportC is more important. Iain and I have decided that changing the build process so that Phobos' zlib code is built with dmd rather than gcc is going to be our goalpost for declaring ImportC ready to use. Why is compiling zlib a goalpost for *Import*C? Hopefully that doesn't make it "finished, because that goalpost has almost no effect on the issues actually plaguing C interop at the moment - i.e. the preprocessor.
Re: Beta 2.098.0
On 10/19/2021 6:35 AM, Timon Gehr wrote: I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise. Timon and I famously disagree over the concept behind @live. Nevertheless, we do agree that ImportC is more important. Iain and I have decided that changing the build process so that Phobos' zlib code is built with dmd rather than gcc is going to be our goalpost for declaring ImportC ready to use.
Re: Beta 2.098.0
On Tuesday, 19 October 2021 at 14:48:20 UTC, Tejas wrote: On Tuesday, 19 October 2021 at 13:53:04 UTC, Paul Backus wrote: I this specific case, I agree completely. But there is a broader pattern in D of projects getting "stuck" because a specific individual is unable to continue work on them (e.g., std.experimental.allocator and Andrei), and I think it is worth considering whether we can do anything to make future projects robust against this mode of failure. The obvious solution is more people who get paid to work on D the language/stdlib/rt-env full-time. Where to get money to pay those individuals? Well there's no obvious solution to that (that I know of). We can say community, but, like the vision documents, they will be a bust because one can't _make_ volunteers meet deadlines, code in a particular way, or incorporate all feedback language maintainers think should be acted on. That would help. But also, I think there are probably steps we could take that would make it easier for people other than the original author to pick up existing stalled projects and help move them towards completion. To return to the `std.experimental.allocator` example: there are many people in the community who'd be happy to contribute towards getting it moved out of `experimental`. The problem is, nobody knows what needs to be done, or what the criteria are to consider the project "finished." If the original author(s) had written down, say, a design document and a TODO list, and posted them somewhere publicly visible (maybe the D Wiki?), we would not have this problem.
Re: Beta 2.098.0
On Tuesday, 19 October 2021 at 13:53:04 UTC, Paul Backus wrote: On Tuesday, 19 October 2021 at 13:35:16 UTC, Timon Gehr wrote: On 11.10.21 03:08, Paul Backus wrote: Perhaps worth asking why Walter, specifically, is required to work on @live in order for it to make progress. Is it just because no one else is willing to step up to the plate, or is he the only person qualified/capable enough? I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise. I this specific case, I agree completely. But there is a broader pattern in D of projects getting "stuck" because a specific individual is unable to continue work on them (e.g., std.experimental.allocator and Andrei), and I think it is worth considering whether we can do anything to make future projects robust against this mode of failure. The obvious solution is more people who get paid to work on D the language/stdlib/rt-env full-time. Where to get money to pay those individuals? Well there's no obvious solution to that (that I know of). We can say community, but, like the vision documents, they will be a bust because one can't _make_ volunteers meet deadlines, code in a particular way, or incorporate all feedback language maintainers think should be acted on.
Re: Beta 2.098.0
On Tuesday, 19 October 2021 at 13:35:16 UTC, Timon Gehr wrote: On 11.10.21 03:08, Paul Backus wrote: Perhaps worth asking why Walter, specifically, is required to work on @live in order for it to make progress. Is it just because no one else is willing to step up to the plate, or is he the only person qualified/capable enough? I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise. I this specific case, I agree completely. But there is a broader pattern in D of projects getting "stuck" because a specific individual is unable to continue work on them (e.g., std.experimental.allocator and Andrei), and I think it is worth considering whether we can do anything to make future projects robust against this mode of failure.
Re: Beta 2.098.0
On 11.10.21 03:08, Paul Backus wrote: On Monday, 11 October 2021 at 00:34:28 UTC, Mike Parker wrote: On Sunday, 10 October 2021 at 23:36:56 UTC, surlymoor wrote: Meanwhile @live is in the language, and it's half-baked. Then there's preview switches that will linger on into perpetuity; DIPs' implementations that haven't been finished. And Walter has prioritized this issue over those. No matter what he works on, people will moan that he isn’t working on something else. Maybe we should clone him. Perhaps worth asking why Walter, specifically, is required to work on @live in order for it to make progress. Is it just because no one else is willing to step up to the plate, or is he the only person qualified/capable enough? I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise.
Re: Beta 2.098.0
On Sunday, 17 October 2021 at 17:55:05 UTC, Adam D Ruppe wrote: Why did dstep fail for them? I don't know; never tried it. Not qualified for an opinion there. I mean we both use stb_vorbis and many other stuff translated by ketmar by hand to (Alice)D ; not everyone is at his level to do it well. How would importC help the bindBC project? I guess for small libraries you would be able to just embed the file instead of creating bindings. I also assume that ImportC would eat pre-declarations but not sure.
Re: Beta 2.098.0
On Sunday, 17 October 2021 at 17:55:05 UTC, Adam D Ruppe wrote: On Sunday, 17 October 2021 at 17:09:40 UTC, Guillaume Piolat wrote: Doing it by hand, until now, has been the preffered way to translate C and C++ headers. Why did dstep fail for them? How would importC help the bindBC project? I think this is actually an issue with process rather than technology. The ideal way to do bindings, in my opinion, is to rigorous lock in to / check-in a certain header file, then generate the bindings at build time. ImportC might make that less of a hassle but fundamentally I think the abstraction wrong at the moment.
Re: Beta 2.098.0
On Sunday, 17 October 2021 at 17:09:40 UTC, Guillaume Piolat wrote: Doing it by hand, until now, has been the preffered way to translate C and C++ headers. Why did dstep fail for them? How would importC help the bindBC project?
Re: Beta 2.098.0
On Sunday, 17 October 2021 at 15:54:46 UTC, Dennis wrote: On Tuesday, 12 October 2021 at 12:55:16 UTC, Adam Ruppe wrote: On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote: ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Why have the other approaches fallen short? How does importC address these problems? A bit late, but I really want to make [a reference](https://xkcd.com/927/). Situation: There are 4 competing tools/approaches for interfacing with C .h files. Walter: 4?! Ridiculous! We need to develop one universal tool that covers everyone's use cases. [Soon] Situation: There are 5 competing tools/approaches. I kinda agree here. Although all tools are splendid in their own way, the ultimate solution would be some kind of hybrid.
Re: Beta 2.098.0
On Tuesday, 12 October 2021 at 12:55:16 UTC, Adam Ruppe wrote: On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote: ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Why have the other approaches fallen short? How does importC address these problems? One of D's ecosystem most valuable set of libraries (BindBC formerly Derelict) are exactly that: translation of C headers by hand. Doing it by hand, until now, has been the preffered way to translate C and C++ headers.
Re: Beta 2.098.0
On Tuesday, 12 October 2021 at 12:55:16 UTC, Adam Ruppe wrote: On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote: ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Why have the other approaches fallen short? How does importC address these problems? A bit late, but I really want to make [a reference](https://xkcd.com/927/). Situation: There are 4 competing tools/approaches for interfacing with C .h files. Walter: 4?! Ridiculous! We need to develop one universal tool that covers everyone's use cases. [Soon] Situation: There are 5 competing tools/approaches.
Re: Beta 2.098.0
On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote: On 10/5/2021 10:36 AM, ag0aep6g wrote: it's also true that Walter prioritizes new features instead (ImportC is the latest fad) ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Unfortunately, ImportC is useless if it only half works. It has to work with existing C headers, which is why I'm concentrating on it to get to that point. Lack of ImportC has wasted a *lot* of developer time, making it a high leverage investment of time. Just think of all the time lost doing manual conversion of .h files, and then doing them again and again as they evolve. Then not one, not two, but *three* different automated programs were developed to try and resolve this (one of which I wrote). Then think of all the projects *not* done because of the barrier of trying to deal with several thousand lines of .h files. The Diemos project was an effort to crowdsource conversion of .h files to D, but it just was not adequate. In summary, ImportC is totally worth the effort. I should have done it 15 years ago. Agreed. I'm eager to try ImportC in it's full glory when it arrives :) And when it's "complete" it would be cool to integrate it even further. Maybe some stuff could be automated for example or even be done at design time
Re: Beta 2.098.0
On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote: ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Why have the other approaches fallen short? How does importC address these problems?
Re: Beta 2.098.0
On Sunday, 10 October 2021 at 23:36:56 UTC, surlymoor wrote: Meanwhile @live is in the language, and it's half-baked. Then there's preview switches that will linger on into perpetuity; DIPs' implementations that haven't been finished. In retrospect, this is a rather crude message, especially from someone who doesn't contribute anything. Apologies.
Re: Beta 2.098.0
On Monday, 11 October 2021 at 01:08:30 UTC, Paul Backus wrote: On Monday, 11 October 2021 at 00:34:28 UTC, Mike Parker wrote: On Sunday, 10 October 2021 at 23:36:56 UTC, surlymoor wrote: Meanwhile @live is in the language, and it's half-baked. Then there's preview switches that will linger on into perpetuity; DIPs' implementations that haven't been finished. And Walter has prioritized this issue over those. No matter what he works on, people will moan that he isn’t working on something else. Maybe we should clone him. Perhaps worth asking why Walter, specifically, is required to work on @live in order for it to make progress. Is it just because no one else is willing to step up to the plate, or is he the only person qualified/capable enough? FWIW The code isn't great. Maybe I'll have another crack at it some day but it wasn't very well structured compared to similar efforts I have seen (e.g. https://developers.redhat.com/blog/2020/03/26/static-analysis-in-gcc-10 's implementation)
Re: Beta 2.098.0
On Monday, 11 October 2021 at 00:34:28 UTC, Mike Parker wrote: On Sunday, 10 October 2021 at 23:36:56 UTC, surlymoor wrote: Meanwhile @live is in the language, and it's half-baked. Then there's preview switches that will linger on into perpetuity; DIPs' implementations that haven't been finished. And Walter has prioritized this issue over those. No matter what he works on, people will moan that he isn’t working on something else. Maybe we should clone him. Perhaps worth asking why Walter, specifically, is required to work on @live in order for it to make progress. Is it just because no one else is willing to step up to the plate, or is he the only person qualified/capable enough?
Re: Beta 2.098.0
On Monday, 11 October 2021 at 00:34:28 UTC, Mike Parker wrote: On Sunday, 10 October 2021 at 23:36:56 UTC, surlymoor wrote: Meanwhile @live is in the language, and it's half-baked. Then there's preview switches that will linger on into perpetuity; DIPs' implementations that haven't been finished. And Walter has prioritized this issue over those. No matter what he works on, people will moan that he isn’t working on something else. Maybe we should clone him. My cousin has a vat filled with neon green liquid. Just let me know.
Re: Beta 2.098.0
On Sunday, 10 October 2021 at 23:36:56 UTC, surlymoor wrote: Meanwhile @live is in the language, and it's half-baked. Then there's preview switches that will linger on into perpetuity; DIPs' implementations that haven't been finished. And Walter has prioritized this issue over those. No matter what he works on, people will moan that he isn’t working on something else. Maybe we should clone him.
Re: Beta 2.098.0
On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote: ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Unfortunately, ImportC is useless if it only half works. It has to work with existing C headers, which is why I'm concentrating on it to get to that point. Lack of ImportC has wasted a *lot* of developer time, making it a high leverage investment of time. [...] Meanwhile @live is in the language, and it's half-baked. Then there's preview switches that will linger on into perpetuity; DIPs' implementations that haven't been finished.
Re: Beta 2.098.0
On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote: On 10/5/2021 10:36 AM, ag0aep6g wrote: it's also true that Walter prioritizes new features instead (ImportC is the latest fad) ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Unfortunately, ImportC is useless if it only half works. It has to work with existing C headers, which is why I'm concentrating on it to get to that point. Lack of ImportC has wasted a *lot* of developer time, making it a high leverage investment of time. Just think of all the time lost doing manual conversion of .h files, and then doing them again and again as they evolve. Then not one, not two, but *three* different automated programs were developed to try and resolve this (one of which I wrote). Then think of all the projects *not* done because of the barrier of trying to deal with several thousand lines of .h files. The Diemos project was an effort to crowdsource conversion of .h files to D, but it just was not adequate. In summary, ImportC is totally worth the effort. I should have done it 15 years ago. I agree 100%, ImportC is a needed feature Zig people understood that and made it one of their strength C ecosystem is way too big to just ignore it, we seen it with rust, people are not interested in rewriting their libraries in the *insert what's trending* language, they want to take their luggage with them, and they are right, ImportC enables that
Re: Beta 2.098.0
On 10/5/2021 10:36 AM, ag0aep6g wrote: it's also true that Walter prioritizes new features instead (ImportC is the latest fad) ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Unfortunately, ImportC is useless if it only half works. It has to work with existing C headers, which is why I'm concentrating on it to get to that point. Lack of ImportC has wasted a *lot* of developer time, making it a high leverage investment of time. Just think of all the time lost doing manual conversion of .h files, and then doing them again and again as they evolve. Then not one, not two, but *three* different automated programs were developed to try and resolve this (one of which I wrote). Then think of all the projects *not* done because of the barrier of trying to deal with several thousand lines of .h files. The Diemos project was an effort to crowdsource conversion of .h files to D, but it just was not adequate. In summary, ImportC is totally worth the effort. I should have done it 15 years ago.
Re: Beta 2.098.0
On 10/5/2021 8:57 AM, Steven Schveighoffer wrote: On 10/4/21 6:40 PM, Temtaime wrote: https://issues.dlang.org/show_bug.cgi?id=22115 was created for no reason and fixed same day. Aside from the tasteless (and incorrect) attack here, creating an issue, even for a small change, puts something into the changelog automatically. So there is a reason to open an issue for a PR you are just about to merge. In fact, sometimes it's noted as a prerequisite for a PR to reference a given issue. Right. And the reason was also given in the bug report - enabling the front end to be written in a more readable manner.
Re: Release Candidate [was: Re: Beta 2.098.0]
On Thursday, 7 October 2021 at 23:18:39 UTC, Martin Nowak wrote: On Wednesday, 29 September 2021 at 20:53:53 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.098.0 release, ♥ to the 62 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.098.0.html Release candidate is live now ([pending dlang.org PR](https://github.com/dlang/dlang.org/pull/3108)) This release is quite a bit delayed due to [OSX build woes](https://github.com/dlang/installer/pull/487) and some personal lack of time. As usual please report any bugs at https://issues.dlang.org -Martin
Release Candidate [was: Re: Beta 2.098.0]
On Wednesday, 29 September 2021 at 20:53:53 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.098.0 release, ♥ to the 62 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.098.0.html Release candidate is live now ([pending dlang.org PR](https://github.com/dlang/dlang.org/pull/3108)) This release is quite a bit delayed due to [OSX build woes](https://github.com/dlang/installer/pull/487) and some personal lack of time. As usual please report any bugs at https://issues.dlang.org -Martin
Re: Beta 2.098.0
On Tuesday, 5 October 2021 at 17:36:28 UTC, ag0aep6g wrote: On 05.10.21 11:28, Imperatorn wrote: On Tuesday, 5 October 2021 at 07:55:11 UTC, FeepingCreature wrote: On Monday, 4 October 2021 at 22:40:19 UTC, Temtaime wrote: [...] This is just uncalled for. I'm sure you can express what you mean without pointlessly and wrongly insulting the *reason we have this language,* a person who put more than twenty years of their life into this project. Agreed. It's totally OK to criticize, but one should do it in a constructive way Temtaime said that Walter is setting the wrong priorities. Saying that he is doing "nothing useful" is a bit polemic, of course, but that probably stems from frustration. In context, it's hardly an "insult". It's absolutely true that many reported issues don't get fixed for *years*. And that very much includes serious bugs. As far as I can tell, it's also true that Walter prioritizes new features instead (ImportC is the latest fad). I sympathize with Temtaime. Their criticism wasn't sugar-coated, but it is constructive and it is valid in my opinion. Idk, maybe it's just poorly worded. I can also sympathize, but saying someone is doing nothing useful is over the limit in my book. We all have stuff to deal with and making the right choices can be challenging. Just saying...
Re: Beta 2.098.0
On Tue, Oct 05, 2021 at 07:36:28PM +0200, ag0aep6g via Digitalmars-d-announce wrote: [...] > > > On Monday, 4 October 2021 at 22:40:19 UTC, Temtaime wrote: > > > > What is really discourages me that persons like Walter instead > > > > of making D great just do nothing helpful. [...] > It's absolutely true that many reported issues don't get fixed for > *years*. And that very much includes serious bugs. As far as I can > tell, it's also true that Walter prioritizes new features instead > (ImportC is the latest fad). > > I sympathize with Temtaime. Their criticism wasn't sugar-coated, but > it is constructive and it is valid in my opinion. I don't agree with the tone of the criticism, but I do sympathize with the sentiment. The sad reality is that it's much more fun to write new code than to debug old code. Especially when you just had a cool idea that feels like it would revolutionize everything. And it very well might do just that; but in the meantime, "boring" stuff like fixing bugs in the current (probably hairy, messy, unclean) code gets neglected. This is a particularly pronounced problem in groups consisting mostly of experts or highly-experienced people. Everybody wants to do the cool, innovative stuff, nobody feels like doing the boring grunt work. Worse yet, in high-expertise areas like debugging the D compiler even those who are willing to do the grunt work may not actually feel qualified enough to do it. But grunt work is just as necessary as the innovative, ground-breaking stuff. *Somebody* has to step up and be willing to do it. It's a thankless, unrewarding job, but a very necessary one. T -- Don't modify spaghetti code unless you can eat the consequences.
Re: Beta 2.098.0
On 05.10.21 11:28, Imperatorn wrote: On Tuesday, 5 October 2021 at 07:55:11 UTC, FeepingCreature wrote: On Monday, 4 October 2021 at 22:40:19 UTC, Temtaime wrote: What is really discourages me that persons like Walter instead of making D great just do nothing helpful. This is just uncalled for. I'm sure you can express what you mean without pointlessly and wrongly insulting the *reason we have this language,* a person who put more than twenty years of their life into this project. Agreed. It's totally OK to criticize, but one should do it in a constructive way Temtaime said that Walter is setting the wrong priorities. Saying that he is doing "nothing useful" is a bit polemic, of course, but that probably stems from frustration. In context, it's hardly an "insult". It's absolutely true that many reported issues don't get fixed for *years*. And that very much includes serious bugs. As far as I can tell, it's also true that Walter prioritizes new features instead (ImportC is the latest fad). I sympathize with Temtaime. Their criticism wasn't sugar-coated, but it is constructive and it is valid in my opinion.
Re: Beta 2.098.0
On 10/4/21 6:40 PM, Temtaime wrote: What is really discourages me that persons like Walter instead of making D great just do nothing helpful. https://issues.dlang.org/show_bug.cgi?id=22115 was created for no reason and fixed same day. Aside from the tasteless (and incorrect) attack here, creating an issue, even for a small change, puts something into the changelog automatically. So there is a reason to open an issue for a PR you are just about to merge. In fact, sometimes it's noted as a prerequisite for a PR to reference a given issue. -Steve
Re: Beta 2.098.0
On Tuesday, 5 October 2021 at 07:55:11 UTC, FeepingCreature wrote: On Monday, 4 October 2021 at 22:40:19 UTC, Temtaime wrote: What is really discourages me that persons like Walter instead of making D great just do nothing helpful. This is just uncalled for. I'm sure you can express what you mean without pointlessly and wrongly insulting the *reason we have this language,* a person who put more than twenty years of their life into this project. Agreed. It's totally OK to criticize, but one should do it in a constructive way
Re: Beta 2.098.0
On Monday, 4 October 2021 at 22:40:19 UTC, Temtaime wrote: What is really discourages me that persons like Walter instead of making D great just do nothing helpful. This is just uncalled for. I'm sure you can express what you mean without pointlessly and wrongly insulting the *reason we have this language,* a person who put more than twenty years of their life into this project.
Re: Beta 2.098.0
On Wednesday, 29 September 2021 at 20:53:53 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.098.0 release, ♥ to the 62 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.098.0.html This release is quite a bit delayed due to [OSX build woes](https://github.com/dlang/installer/pull/487) and some personal lack of time. As usual please report any bugs at https://issues.dlang.org -Martin What is really discourages me that persons like Walter instead of making D great just do nothing helpful. https://issues.dlang.org/show_bug.cgi?id=22115 was created for no reason and fixed same day. While these ones will rest for some years i think ... https://issues.dlang.org/show_bug.cgi?id=22148 https://issues.dlang.org/show_bug.cgi?id=22283
Re: Beta 2.098.0
On Friday, 1 October 2021 at 11:13:28 UTC, kinke wrote: On Wednesday, 29 September 2021 at 20:53:53 UTC, Martin Nowak wrote: [...] and some personal lack of time. Thanks for your time! - Tests with latest beta3 are looking good for the Symmetry code base, incl. significant RAM reductions when building huge static libs (saving ~3 GB in one case).
Re: Beta 2.098.0
On Wednesday, 29 September 2021 at 20:53:53 UTC, Martin Nowak wrote: [...] and some personal lack of time. Thanks for your time! - Tests with latest beta3 are looking good for the Symmetry code base, incl. significant RAM reductions when building huge static libs (saving ~3 GB in one case).
Re: Beta 2.098.0
On Wednesday, 29 September 2021 at 20:53:53 UTC, Martin Nowak wrote: http://dlang.org/changelog/2.098.0.html The changelog is outdated, the entries in master should be moved to stable and then the changelog folder on the master branch can be purged. https://github.com/dlang/dmd/pull/13113 https://github.com/dlang/dmd/pull/13114
Re: Beta 2.098.0
On Wednesday, 29 September 2021 at 20:53:53 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.098.0 release, ♥ to the 62 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.098.0.html This release is quite a bit delayed due to [OSX build woes](https://github.com/dlang/installer/pull/487) and some personal lack of time. As usual please report any bugs at https://issues.dlang.org -Martin Hurray!
Beta 2.098.0
Glad to announce the first beta for the 2.098.0 release, ♥ to the 62 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.098.0.html This release is quite a bit delayed due to [OSX build woes](https://github.com/dlang/installer/pull/487) and some personal lack of time. As usual please report any bugs at https://issues.dlang.org -Martin
