www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Beta 2.098.0

reply Martin Nowak <code dawg.eu> writes:
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
Sep 29
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
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!
Sep 29
prev sibling next sibling parent Dennis <dkorpel gmail.com> writes:
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
Sep 30
prev sibling next sibling parent reply kinke <noone nowhere.com> writes:
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).
Oct 01
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
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).
😮
Oct 02
prev sibling next sibling parent reply Temtaime <temtaime gmail.com> writes:
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
Oct 04
next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
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.
Oct 05
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
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
Oct 05
parent reply ag0aep6g <anonymous example.com> writes:
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.
Oct 05
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Oct 05
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
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...
Oct 05
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 10
next sibling parent russhy <russhy gmail.com> writes:
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
Oct 10
prev sibling next sibling parent reply surlymoor <surlymoor cock.li> writes:
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.
Oct 10
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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.
Oct 10
next sibling parent surlymoor <surlymoor cock.li> writes:
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.
Oct 10
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
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?
Oct 10
next sibling parent max haughton <maxhaton gmail.com> writes:
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)
Oct 10
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Oct 19
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
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.
Oct 19
parent reply Tejas <notrealemail gmail.com> writes:
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.
Oct 19
parent Paul Backus <snarwin gmail.com> writes:
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.
Oct 19
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 19
parent reply max haughton <maxhaton gmail.com> writes:
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.
Oct 19
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 20 October 2021 at 05:08:51 UTC, max haughton wrote:
 On Wednesday, 20 October 2021 at 01:48:24 UTC, Walter Bright 
 wrote:
 On 10/19/2021 6:35 AM, Timon Gehr wrote:
 [...]
Timon and I famously disagree over the concept behind live. Nevertheless, we do agree that ImportC is more important. Iain and I have decided that changing the build process so that Phobos' zlib code is built with dmd rather than gcc is going to be our goalpost for declaring ImportC ready to use.
Why is compiling zlib a goalpost for *Import*C? Hopefully that doesn't make it "finished, because that goalpost has almost no effect on the issues actually plaguing C interop at the moment - i.e. the preprocessor.
I interpreted it as "a goalpost", not *the* goal. I hope at least 🍀 ImportC has the potential to be really powerful. But maybe the later steps doesn't have to be made by Walter?
Oct 19
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/19/2021 10:08 PM, max haughton wrote:
 Why is compiling zlib a goalpost for *Import*C?
Dogfooding.
Oct 20
prev sibling parent surlymoor <surlymoor cock.li> writes:
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.
Oct 10
prev sibling next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
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?
Oct 12
next sibling parent reply Dennis <dkorpel gmail.com> writes:
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.
Oct 17
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
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.
Oct 17
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
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.
Oct 17
parent reply Adam D Ruppe <destructionator gmail.com> writes:
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?
Oct 17
next sibling parent max haughton <maxhaton gmail.com> writes:
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.
Oct 17
prev sibling parent Guillaume Piolat <first.last gmail.com> writes:
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.
Oct 18
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
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 😍
Oct 12
prev sibling parent workman <workman gmail.com> writes:
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)
Oct 20
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Oct 05
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Oct 10
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
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
Oct 07
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
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
💕
Oct 08