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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021