Re: Adding Modules to C in 10 Lines of Code
On 6/5/2022 7:26 AM, mee6 wrote: On Saturday, 4 June 2022 at 19:26:27 UTC, Walter Bright wrote: On 6/4/2022 5:29 AM, Paulo Pinto wrote: I guess going around the horn is a synonym for lets pretend there wasn't prior art and keep arguing D did it first, as usual. Writing a paper is not doing it first. Why do you care so much about being "first"? Would you not have implemented and made a presentation about it if you didn't think it was the first implementation? Because it's fun to be first!
Re: Adding Modules to C in 10 Lines of Code
On 6/4/2022 5:29 AM, Paulo Pinto wrote: I guess going around the horn is a synonym for lets pretend there wasn't prior art and keep arguing D did it first, as usual. Writing a paper is not doing it first.
Re: Adding Modules to C in 10 Lines of Code
On 5/29/2022 11:13 PM, Paulo Pinto wrote: Stepstone did it for Objective-C with #import, Not the same as C doing the importing of C code. and Apple with module maps for C and Objective-C, the modules design that preceeded C++ modules on clang. Then we have those failed attempts at fixing C like SafeC. And if we count research work, Bjarne Stroustoup and Gabriel dos Reis, did it back when they were teaching in Texas university, here is the 2009 paper, "A Principled, Complete, and Efficient Representation of C++" https://www.stroustrup.com/gdr-bs-macis09.pdf Going around the horn, really doing it the hard way. Besides, writing a paper is not the same thing as implementing a working system. There were many proposals about adding modules to C, they just all went nowhere. Both Visual Age for C++ v0.4 and Lucid's Energize C++ did 40 years ago, by serializing C++ code into database representation, both failed due to high hardware requirements for late 80's/early 90's PCs. Yee gods, doing it with a database representation is certainly going around the horn. Note that neither D nor ImportC rely on some database or symbol table file. Lucid Energize Demo in 1993 https://www.youtube.com/watch?v=pQQTScuApWk Its database system, Cadillac, "Foundation for a C++ Programming Environment" https://dreamsongs.com/Files/Energize.pdf Visual Age for C++ v4, http://www.edm2.com/0704/vacpp4/vacpp4.html The build environment is totally different from traditional compilers. The concept of header files and source code files is obsolete. VAC++ utilizes a global approach to definitions and implementations. That is, once a definition is processed it stays in memory for the duration of the build. To maintain compatibility, header files can still be #included. This new approach to handling source code is disorienting at first and will make migrating existing code to the compiler somewhat difficult. Errors pertaining to objects being defined more than once will likely occur while migrating. Often these errors are incorrect. The work around is to remove the #include line in the source file that contains the offending “redefinition”. https://books.google.de/books?id=ZwHxz0UaB54C=PA206_esc=y#v=onepage=false Additionally the way pre-compiled headers work on C++ Builder and Visual C++, versus the UNIX way, meant that on Windows the reward of the action did not outweigh the costs incurred, and ironically Visual C++ is the one leading the C++ modules support anyway, thanks to Gabriel dos Reis being part of the team, and pinging back on those 2009 learnings. Precompiled headers for C and C++ were certainly a module-like system (I know because I wrote one), but they are horrific kludges.
Re: LDC 1.30.0-beta1
On 5/16/2022 11:31 AM, kinke wrote: Glad to announce the first beta for LDC 1.30. Excellent work!
Re: Release D 2.100.0
As always, stellar work, Martin! Thank you!
IntelliJ D Language support
Now on front page of hackernews! https://news.ycombinator.com/news
Re: GCC 12.1 Released (D v2.100-rc.1)
On 5/6/2022 4:57 AM, Iain Buclaw wrote: I am proud to announce another major GCC release, 12.1. Very impressive work, Iain!
Re: Beta 2.100.0
On 4/23/2022 7:45 AM, Guillaume Piolat wrote: Those are not super critical bugs. It would just be nice to be able to use D_SIMD one day, as DMD compile speed benefits are enticing. I've addressed all three. The latter two are the result of incorrect usage, so I added some examples here: https://github.com/dlang/druntime/pull/3808 which should help.
Re: Beta 2.100.0
On 4/22/2022 2:24 AM, Martin Nowak wrote: Glad to announce the first beta for the 2.100.0 release, ♥ to the 40 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.100.0.html As usual please report any bugs at https://issues.dlang.org -Martin Yay! Thanks, Martin + 40!
Re: Adding Modules to C in 10 Lines of Code
On 4/17/2022 1:12 PM, Walter Bright wrote: https://nwcpp.org/ An online presentation. Monday at 7PM PST. Slides: https://nwcpp.org/talks/2022/modules_in_c.pdf Video: https://www.youtube.com/watch?v=2ImfbGm0fls
Re: Adding Modules to C in 10 Lines of Code
On 4/19/2022 5:41 AM, jmh530 wrote: Will there be a recording available? Yes. NWCPP routinely posts the video a few days later.
Re: Adding Modules to C in 10 Lines of Code
On 4/17/2022 5:40 PM, Ali Çehreli wrote: On 4/17/22 13:12, Walter Bright wrote: https://nwcpp.org/ An online presentation. Monday at 7PM PST. (My earlier post disappeared.) April 20 is Wednesday. Ali Gak! My bad. You're right.
Adding Modules to C in 10 Lines of Code
https://nwcpp.org/ An online presentation. Monday at 7PM PST.
Re: Teaching D at a Russian University
On 2/19/2022 12:26 PM, Elronnd wrote: I think it is fine as is. So do I. I enjoy the unusual phrasings some ESL people use. For example, a long time ago in a circle of friends of mine one ESL person would say things like: "time for go" instead of "time to go" "make some shoppings" instead of "go shopping" and the circle just adopted his way of saying things. I find myself still doing it :-)
Re: Beta 2.099.0
Now that the beta is released (Thank you, Martin!) could we get the documentation for __import pulled? https://github.com/dlang/dlang.org/pull/3182
Re: Beta 2.099.0
On 2/15/2022 10:55 PM, Rainer Schuetze wrote: The PR was too late for the beta, but this is the basic change: https://github.com/dlang/druntime/pull/3740/files#diff-5cbe9748431681a766784b1bd997444d58d436a26a345b32397daae478f85c5dR907 Sweet!
Re: DConf 2022 in London?
On 2/15/2022 4:22 AM, Mike Parker wrote: Personally, I'm super pumped about this. I hope to see a lot of you in London in August! I'm in!
Re: Added copy constructors to "Programming in D"
On 2/10/2022 12:34 PM, Walter Bright wrote: On 2/10/2022 12:06 AM, Mathias LANG wrote: I think an *immediate* improvement we could make to ease people's life is to make `auto` peel the outermost qualifier level inside functions. So that: ```D const int* ptr; auto p2 = ptr; static assert(is(typeof(p2) == const(int)*)); ``` I really can't think of any downside to it, only upsides: - It is still predictable / consistent; - It *might* reduce the number of template instantiations in some cases; - It just flows more naturally... If you want full constness, there's still `const`; It sounds sensible to me. By the way, `cast()ptr` will peal off the outermost const/immutable/etc from the type.
Re: Added copy constructors to "Programming in D"
On 2/10/2022 12:06 AM, Mathias LANG wrote: I think an *immediate* improvement we could make to ease people's life is to make `auto` peel the outermost qualifier level inside functions. So that: ```D const int* ptr; auto p2 = ptr; static assert(is(typeof(p2) == const(int)*)); ``` I really can't think of any downside to it, only upsides: - It is still predictable / consistent; - It *might* reduce the number of template instantiations in some cases; - It just flows more naturally... If you want full constness, there's still `const`; It sounds sensible to me.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On 2/7/2022 6:21 PM, Paul Backus wrote: On Monday, 7 February 2022 at 23:40:38 UTC, Walter Bright wrote: On 2/6/2022 9:05 PM, forkit wrote: only to have the compiler complain, that its' actually @mustUse I have to agree. All D keywords and imports and compiler-recognized attributes are lower case, @mustuse should be consistent with that. I guess core.attribute.gnuAbiTag sneaked in behind your back, huh? Indeed it did. I did not notice it until this moment. A lot of people work on D, and I have to trust them. Anyway, I'm happy to change it if that's your call, although it would have been nice to have caught this before the DIP was officially accepted. Yes, please change it. Thank you!
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On 2/6/2022 7:14 AM, Daniel N wrote: However by choosing "use" we could avoid the entire discussion about which case to use... "mustuse" is much more greppable.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On 2/7/2022 5:10 PM, forkit wrote: Suppose I don't want to 'use it'. That should be allowed, as long as I don't discard it. With mustuse, I'm being told I can't discard it, and that i must use it. Sorry, all those negations made my brain explode. P.S. English has examples of negation issues, such as: "I could care less." which makes no sense at all, until you realize it's just a shortened version of "I couldn't care less." The addition or subtraction of the negation does not change the meaning, as the brain doesn't do a good job recognizing it. The phrases "not no-way", and "not no-how" use multiple negations to emphasize, rather than negate.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On 2/6/2022 9:05 PM, forkit wrote: only to have the compiler complain, that its' actually @mustUse I have to agree. All D keywords and imports and compiler-recognized attributes are lower case, @mustuse should be consistent with that.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On 2/6/2022 7:17 AM, Paul Backus wrote: To be honest, though, I can see where he's coming from. When writing DIP 1038, I made a conscious effort to avoid using the term "non-`@nodiscard`", due to the double negative. With a positively-phrased name like `@mustUse`, that problem disappears. Andrei once asked me for scientific evidence that negations are cognitively more difficult for human brains to understand. I didn't have it at the time, but did eventually find it and forwarded it to Andrei, who was satisfied with it. I didn't keep a copy, though. It's not just my opinion that negations are to be avoided, there's research justifying it. I remember back in the olden daze when I was designing digital logic circuits that using NAND and NOR gates would cause me endless confusion. I eventually decided to design with AND and OR gates, then mechanically convert them to NAND and NOR using deMorgan's Theorem. NANDs and NORs require fewer transistors to function, so are preferred. This was later built into the ABEL programming language that I designed for Data I/O. ABEL was used to burn logic equations into programmable logic devices. It had a pass that converted everything to NANDs and NORs. Positive logic in computer code, however, has no such penalty. Hence I try to write code that eschews negative logic. Anytime you find yourself writing not-nohow, not-noway, etc., it's time to redesign the state of the variables. Try to organize logic so ! is not necessary. I mean, try to organize logic so ! is absent.
Re: The DIID series (Do It In D)
On 1/25/2022 12:44 AM, Guillaume Piolat wrote: I'll consider fixing this. I always read "How good really is X?" as "this is bad" and "How bad really is X?" as "this is good" probably because for the french the best appreciation you can get is "not bad!" Thanks for considering it.
Re: The DIID series (Do It In D)
On 1/24/2022 4:34 PM, Elronnd wrote: On Monday, 24 January 2022 at 23:33:29 UTC, Walter Bright wrote: The phrase "How bad really is the D ecosystem?" only asks a question, but people tend to interpret such sentences as "D's ecosystem is really bad". What works better is: "How good really is the D ecosystem?" Your suggested phrasing sounds overly trite to me. I would maybe go for 'Is the D ecosystem really that bad?' Again, never write "Is the D ecosystem really that bad?" unless one wants to give the impression that the D ecosystem is bad. Because all the dear reader actually sees is: D ecosystem bad
Re: The DIID series (Do It In D)
This is a nice initiative, Thanks! But may I offer a suggestion: The phrase "How bad really is the D ecosystem?" only asks a question, but people tend to interpret such sentences as "D's ecosystem is really bad". What works better is: "How good really is the D ecosystem?"
Re: From the D Blog: The Binary Language of Moisture Vaporators
On 1/24/2022 1:57 PM, Moth wrote: first: how exactly does assembly output relate to moisture vaporators? Vaporators run on compiled code, so do understand the binary code of vaporators, you'll need a disassembler. I wanted to make looking at the binary code easy and fun. second: what on earth is an ""alpha programmer""? The top tier of programmers. In my career, I've noticed a very strong correlation between the top tier of programmers, and programmers who had a solid understanding of assembler code and what their compiler was doing. i do hope walter has not subscribed to the pseudoscientific views of mysogynists. Gender never occurred to me when speaking about alpha programmers.
Re: From the D Blog: The Binary Language of Moisture Vaporators
On 1/24/2022 10:22 AM, Imperatorn wrote: On Monday, 24 January 2022 at 14:22:21 UTC, Mike Parker wrote: Some of you may be aware that Walter recently added a disassembler to DMD. He writes about it in his latest post for the D blog. The blog: https://dlang.org/blog/2022/01/24/the-binary-language-of-moisture-vaporators/ Reddit: https://www.reddit.com/r/programming/comments/sbn7n6/the_binary_language_of_moisture_vaporators/ Nice It's also on https://news.ycombinator.com/news currently at number 76
Re: On the D Blog: Using the GCC Static Analyzer on the D Programming Language
Nice work, Max!
Re: Why I Like D
On 1/12/2022 8:14 AM, Steven Schveighoffer wrote: I wonder if there is just so much fear of the GC vs people who actually tried to use the GC and it failed to suit their needs. I've never been afraid of the GC in my projects, and it hasn't hurt me at all. My experience with people who don't want to use a product I've worked on is: 1. they'll give reason X, which is usually something that sounds convenient 2. I fix X, they can use it now! 3. they then give reason Y, after thinking about it for a minute What's happening is neither X nor Y is the real reason. They just don't want to tell me the real reason, usually because it's an emotional one. The GC issue fits all of that. For example, back in the olden days (the 1980s), as related to me by a friend: X: The most important thing I want in a C++ compiler is speed! I cannot emphasize enough how important that is! Y: No, that isn't the reason. The most important thing to you in a C++ compiler is brand name. X: (Dumbfounded) Why would you say that? Y: Because you are using Microsoft C++, which is 4 times slower than Zortech C++. X: Oh. Another one: Friend: You should write a native Java compiler! It'll take over the world! I really want a native Java compiler! Me: I already wrote one, Symantec's Java compiler. You can get it and use it today! Friend: Oh. [Changes the subject] Now, consider BetterC, a 90% subset of D, and no GC in sight. It changed nobody's mind who didn't use D "because of the GC", because that is not the real reason.
Why I Like D
"Why I like D" is on the front page of HackerNews at the moment at number 11. https://news.ycombinator.com/news
Re: DMD now incorporates a disassembler
On 1/9/2022 11:33 AM, max haughton wrote: https://stackoverflow.com/questions/2511018/how-does-objdump-manage-to-display-source-code-with-the-s-option obj2asm does the same thing: https://www.digitalmars.com/ctg/obj2asm.html
Re: DMD now incorporates a disassembler
On 1/8/2022 10:04 PM, max haughton wrote:
For GCC/Clang you'd want -S
I know about that, but take a look at it:
> cat fred.c
int fred(int a[10])
{
return a[11];
}
> cc -S test.c
> cat test.s
.file "test.c"
.text
.globl test
.type test, @function
test:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movl$0, %eax
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size test, .-test
.ident "GCC: (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4"
.section.note.GNU-stack,"",@progbits
Contrast with what -vasm does:
> cat test.d:
int fred(int* a)
{
return a[11];
}
> dmd -c test.d -vasm
_D4test4fredFPiZi:
: 8B 47 2Cmov EAX,02Ch[RDI]
0003: C3 ret
***
-vasm gives me what I want to see. There aren't extra steps to getting it, the
object code is included, and all the boilerplate is omitted.
It's all about the friction.
Re: DMD now incorporates a disassembler
On 1/8/2022 10:04 PM, max haughton wrote: Anyway, I've been playing with -vasm and I think it seems pretty good so far. There are some formatting issues which shouldn't be hard to fix at all (this is why we asked for some basic tests of the shape of the output), put I think I've only found one (touch wood) situation where it actually gets the instruction *wrong* so far. Testing it has led to me finding some fairly bugs in the dmd inline assembler, which I am in the process of filing. Thanks. This helps a lot!
Re: DMD now incorporates a disassembler
On 1/7/2022 7:25 PM, Brian Callahan wrote: Thanks Walter. This is quite useful. Welcs. I'm already productively using it myself.
Re: DMD now incorporates a disassembler
On 1/7/2022 4:43 PM, Elronnd wrote: On Friday, 7 January 2022 at 21:41:55 UTC, Walter Bright wrote: : 89 F8 mov EAX,EDI Feature request: octal. I buried my PDP-11 long ago. Sob.
Re: DMD now incorporates a disassembler
On 1/7/2022 10:39 PM, ag0aep6g wrote: With feature creep in full swing now, when can I expect to read my email with DMD? The real question is why doesn't your email reader have an option to disassemble the email?
Re: DMD now incorporates a disassembler
On 1/8/2022 12:50 PM, max haughton wrote: On Saturday, 8 January 2022 at 18:47:11 UTC, Vladimir Marchevsky wrote: On Friday, 7 January 2022 at 21:41:55 UTC, Walter Bright wrote: Compile with -vasm to see it! Enjoy! Any practical reason to put disassembler into compiler instead of making it a separate tool? Any ETA for renaming it into DMD Burning ROM? :) Most other compilers have been able to do this for years. I've never seen one. What's the switch for gcc to do the same thing? The only difference is that the way the dmd backend is designed basically means that it never knows the instructions in a given basic block until they are actually emitted, so it has to disassemble it's own output rather than printing it's internal representation with (say) Intel assembly syntax. See https://llvm.org/doxygen/classllvm_1_1MachineInstr.html from LLVM GCC actually *only* uses an assembler to build object files. Compilers that take a detour through an assembler to generate code are inherently slower. It doesn't have a distinct IR like LLVM does but the final stage of the RTL is basically a 1:1 representation of the instruction set: That looks like intermediate code, not assembler.
Re: DMD now incorporates a disassembler
On 1/8/2022 10:47 AM, Vladimir Marchevsky wrote: On Friday, 7 January 2022 at 21:41:55 UTC, Walter Bright wrote: Compile with -vasm to see it! Enjoy! Any practical reason to put disassembler into compiler instead of making it a separate tool? Any ETA for renaming it into DMD Burning ROM? :) https://www.digitalmars.com/ctg/obj2asm.html
DMD now incorporates a disassembler
Compile with -vasm to see it! Enjoy!
For the file test.d:
int demo(int x)
{
return x * x;
}
Compiling with:
dmd test.d -c -vasm
prints:
_D4test4demoFiZi:
: 89 F8 mov EAX,EDI
0002: 0F AF C0imulEAX,EAX
0005: C3 ret
https://github.com/dlang/dmd/pull/13447
Re: GDC has just landed v2.098.0-beta.1 into GCC
On 11/30/2021 11:37 AM, Iain Buclaw wrote: The latest version of the D language has [now landed](https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5fee5ec362f7a243f459e6378fd49dfc89dc9fb5) in GCC. Excellent!
Re: DConf Online 2021 Links
Mike, the conference went great and very smoothly! You did a great job on all aspects! And thanks to all the presenters for great work, too!
Classes in D with betterC
https://lsferreira.net/posts/zet-1-classes-betterc-d/ by Luís Ferreira It's currently on the front page of Hacker News: https://news.ycombinator.com/
Re: Gordon programming language
On 10/25/2021 1:38 AM, Tero Hänninen wrote: On Monday, 25 October 2021 at 00:39:07 UTC, Walter Bright wrote: The Emperor would shoot you for interrupting his wedding with this news! Fire when Gordon's in range! Ohh sh*t, I've got to runnn! Thanks for creating D, Walter. I liked the core D language the moment I first saw it and got immediately sucked in. Also wrote my boot compiler in it :) Thanks for the kind words! P.S. The quote is from Flash Gordon.
Re: Gordon programming language
The Emperor would shoot you for interrupting his wedding with this news! Fire when Gordon's in range!
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 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: DConf Online 2021 Schedule Published
Use #dconf2021 on twitter! https://twitter.com/hashtag/dconf2021
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: GCC 11.2 Released
On 7/29/2021 7:51 AM, Iain Buclaw wrote: GCC version 11.2 was released on the 28th. Thank you!
Re: LDC 1.27.0-beta3
On 7/14/2021 12:38 PM, kinke wrote: Glad to announce the third beta for LDC 1.27. Some noteworthy changes since beta2: Nice work!
Re: Keep up with ImportC using hashtag #ImportC
On 6/10/2021 9:08 AM, Imperatorn wrote: On Tuesday, 8 June 2021 at 06:39:51 UTC, Walter Bright wrote: https://twitter.com/hashtag/ImportC?src=hashtag_click There are a couple ancient tweets there, just ignore them. ImportC will actually be kinda cool Yup, that's why I'm putting the effort into it.
Keep up with ImportC using hashtag #ImportC
https://twitter.com/hashtag/ImportC?src=hashtag_click There are a couple ancient tweets there, just ignore them.
Re: Destroy All Memory Corruption
On 4/24/2021 2:53 PM, Paul Backus wrote: I assume it's to ensure that objects are destroyed properly when unwinding the stack. Might be possible to avoid in `nothrow` code. Yes, you can avoid this in nothrow code.
Re: Destroy All Memory Corruption
On 4/21/2021 6:31 PM, Ali Çehreli wrote: This is happening in half an hour. It requires MS Teams, which requires a MS (or Skype) account. I was a bit concerned about this, so a couple days earlier Lloyd and I worked to get everything configured and working at my end. It worked smoothly, but one thing I didn't like was I couldn't see anyone else on my screen. It was kinda hard to talk to my slides, trying to imagine the audience. Perhaps I had it set up wrong.
Destroy All Memory Corruption
I'll be doing a reprise of my DConf 2020 talk on Destroy All Memory Corruption on April 21, 2021 at 7PM PST. https://nwcpp.org/ Except this time it'll be live, not prerecorded. All are welcome!
Re: Beta 2.096.1
On 4/14/2021 8:10 AM, Martin Nowak wrote: Glad to announce the first beta for the 2.096.1 point release, ♥ to the 15 contributors. Thank you, Martin!
Re: Dr Callahan ports D compiler to OpenBSD
No problem, Brian. I just assumed that since the article used Dr, that you preferred it. It's a good idea to sign up on Reddit and HN, if only to help support your work and articles.
Dr Callahan ports D compiler to OpenBSD
https://briancallahan.net/blog/20210320.html https://news.ycombinator.com/item?id=26520996#26531423 https://reddit.com/r/programming/comments/m9xu8s/a_working_d_compiler_on_openbsd/ Thanks to Dr Brian Callahan!
Re: Release D 2.096.0
Thank you, Martin!
Re: Windows Bindings v1.0
On 2/17/2021 2:09 PM, Dennis wrote: On Wednesday, 17 February 2021 at 20:53:49 UTC, tchaloupka wrote: Thanks for this, looks great. Could the generated code be annotated with nothrow @nogc too? +1 This is actually missing in many core.sys.windows modules. Please file bugzilla issues for them!
Re: Idioms for the D programming language
On 2/13/2021 7:57 AM, James Lu wrote: I once resubmitted with an AMA-style comment, which was the difference between getting 12 points and not getting on the frontpage, and getting on the frontpage with 158 points. Yup. Another critical thing is to make the first post. The first post has a strong tendency to set the tone for the entire topic. The first post should be a brief synopsis of what the article is about, said in a positive manner. Leaving this to chance has led too many times to having a topic essentially sabotaged by someone making a first post that is strongly negative. The topic never recovers. Always always when submitting a link, make the first post.
Re: Idioms for the D programming language
On 2/11/2021 5:53 PM, James Lu wrote: On Thursday, 11 February 2021 at 20:12:36 UTC, Walter Bright wrote: Now #5 on the front page of https://news.ycombinator.com/news I've gotten Dlang to the frontpage of HN 3 other times: Specification for the D Programming Language https://news.ycombinator.com/item?id=21993208 D 2.0.93.0 https://news.ycombinator.com/item?id=23859448 Ask HN: Why do you use Rust, when D is available? https://news.ycombinator.com/item?id=23494490 Thank you! If you have any particularly interesting and specific pages on D, feel free to send them to me, so I can post them to HN at the optimal time. (Furthermore, if you authored it, you should a comment that explains why you made it and offering to answer questions– I have found this can turn a regular post into a frontpage post.) Yes, having the author do an AMA is very productive.
Idioms for the D programming language
Now #5 on the front page of https://news.ycombinator.com/news The page being discussed: https://p0nce.github.io/d-idioms/ and on reddit: https://www.reddit.com/r/programming/comments/lhssjp/idioms_for_the_d_programming_language/
Re: Article: Why I use the D programming language for scripting
On 1/31/2021 12:36 PM, aberba wrote: It's finally out! https://opensource.com/article/21/1/d-scripting Very nice and informative article!
Re: Please Congratulate My New Assistant
On 1/24/2021 10:46 PM, Imperatorn wrote: Imo it's reasonable to close or archive issues that are older than 10 years. We are not going to do that just because they are old. If a bug still exists in the current DMD, the bug report stays open.
Re: Please Congratulate My New Assistant
On 1/24/2021 5:49 AM, Timon Gehr wrote: There is certainly useful work to be done in the issue tracker. I am here objecting to certain systematic destructive practices that do not even have any upside. I wish this kind of behavior would stop forever. You are not the first person to engage into careless issue closing sprees. I think the underlying issue is a bad understanding of the value of issues in the issue tracker and some sort of irrational assignment of cost to open issues. Walter always says: Put this in bugzilla, it will get lost on the forums, and he is right. You're right this has come up before. I strongly oppose closing Issues and PRs just because they are old. There must be a better and conclusive reason to close them. We had a recent discussion about what to do with stale PRs that are years old. I opposing closing them without a conclusive reason for closing. The stale PRs do pose "drag" on things like the autotester. What I'd like is a "backburner" category for PRs, but there doesn't seem to be such a feature. So what we came up with was: 1. If it doesn't have a bugzilla issue, make a bugzilla issue for it. 2. Put a link to the stale PR in that issue. 3. Close, but do not delete, the PR. This makes these PRs still accessible via bugzilla, and bugzilla has much better categorization abilities than github PRs do.
Re: Please Congratulate My New Assistant
Welcome Max and congratulations!
Re: Say Hello to Our Two New Pull-Request/Issue Managers
This is great news! Congrats to Andrew and Razvan. I'm looking forward to working with them.
Re: Printing shortest decimal form of floating point number with Mir
On 1/9/2021 11:18 PM, Jacob Carlborg wrote: On 2021-01-06 03:30, Walter Bright wrote: The baseline Linux target does not have SSE. What about this changelog entry: https://dlang.org/changelog/2.087.0.html#xmm-linux-changelog ? Eh, you're right. It's FreeBSD32
Re: Printing shortest decimal form of floating point number with Mir
On 1/6/2021 1:31 AM, 9il wrote: > [...] This is the same problem as https://issues.dlang.org/show_bug.cgi?id=21526 It has been provided in the thread https://forum.dlang.org/post/gqzdiicrvtlicurxy...@forum.dlang.org In general, I strongly reiterate that posting bugs to the n.g. means they likely won't get fixed. They have to go into bugzilla, that's why we have bugzilla. The n.g. is not a bug tracking system.
Re: Printing shortest decimal form of floating point number with Mir
On 1/6/2021 4:26 AM, Jacob Carlborg wrote: On 2021-01-06 03:30, Walter Bright wrote: The baseline Linux target does not have SSE. Other compilers solve this by having a flag to specify the minimum target CPU. DMD has flags for that, too.
Re: Printing shortest decimal form of floating point number with Mir
On 1/5/2021 9:57 PM, Timon Gehr wrote: Anyway, I wouldn't necessarily say occasional accidental correctness is the only upside, you also get better performance and simpler code generation on the deprecated x87. I don't see any further upsides though, and for me, it's a terrible trade-off, because possibility of incorrectness and lack of portability are among the downsides. There are algorithms in Phobos that can break when certain operations are computed at a higher precision than specified. Higher does not mean better; not all adjectives specify locations on some good/bad axis. As far as I can tell, the only algorithms that are incorrect with extended precision intermediate values are ones specifically designed to tease out the roundoff to the reduced precision. I don't know of straightforward algorithms, which is what most people write, being worse off because of more precision. For example, if you're summing values in an array, the straightforward approach of simply summing them will not become incorrect with extended precision. In fact, it is likely to be more correct. > I want to execute the code that I wrote, not what you think I should have > instead written, because sometimes you will be wrong. With programming languages, it does not matter what you think you wrote. What matters is how the language semantics are defined to work. In writing professional numerical code, one must carefully understand it, knowing that it does *not* work like 7th grade algebra. Different languages can and do behave differently, too.
Re: Printing shortest decimal form of floating point number with Mir
On 1/5/2021 2:42 AM, 9il wrote: On Tuesday, 5 January 2021 at 09:47:41 UTC, Walter Bright wrote: On 1/4/2021 11:22 PM, 9il wrote: I can't reproduce the same DMD output as you. I did it on Windows 32 bit. I tried it on Linux 32, which does indeed show the behavior you mentioned. At the moment I don't know why the different behaviors. https://issues.dlang.org/show_bug.cgi?id=21526 It just uses SSE, which I think a good way to go, haha. As I mentioned upthread, it will use SSE when SSE is baseline on the CPU target, and it will always round to precision. Does this mean that DMD Linux 32-bit executables should compile with SSE codes? The baseline Linux target does not have SSE. I ask because DMD compiles Linux 32-bit executables with x87 codes when -O is passed and with SSE if no -O is passed. That is very weird. Example, please?
Re: Printing shortest decimal form of floating point number with Mir
On 1/5/2021 5:30 AM, Guillaume Piolat wrote: It would be nice if no excess precision was ever used. It can sometimes gives a false sense of correctness. It has no upside except accidental correctness that can break when compiled for a different platform. That same argument could be use to always use float instead of double. I hope you see it's fallacious What about this plan? - use SSE all the time in DMD That was done for OSX because their baseline CPU had SSE. - drop real :) No.
Re: Printing shortest decimal form of floating point number with Mir
On 1/4/2021 11:22 PM, 9il wrote: I can't reproduce the same DMD output as you. I did it on Windows 32 bit. I tried it on Linux 32, which does indeed show the behavior you mentioned. At the moment I don't know why the different behaviors. https://issues.dlang.org/show_bug.cgi?id=21526 It just uses SSE, which I think a good way to go, haha. As I mentioned upthread, it will use SSE when SSE is baseline on the CPU target, and it will always round to precision. The only D compiler that uses excess precision is DMD and only if -O flag is passed. The same example compiled with GDC uses write-read codes. LDC uses SSE codes. DMD still supports baseline 32 bit Windows that does not have XMM registers. As for C, it allows an intuitive built-in way to work with exact precision when an assignment works like a directive to use exact precision for the expression result, unlike D. It doesn't cover all cases but an intuitive and very easy way to do things the right way. It's a rarity of cases that require the rounding, and DMD does have the functions in druntime to do it for those cases. It's what people doing numerics have asked for. It means the write/read penalty is only there when it is actually required. In any case, this is an issue for the past. The future is XMM code, and DMD does the round-to-precision in all XMM code generation. If you find a case where it isn't, please file a bugzilla and let me know so I can fix it.
Re: Printing shortest decimal form of floating point number with Mir
On 1/4/2021 4:11 AM, 9il wrote:
[...]
The reason those switches are provided is because the write/read is a
performance hog.
D provides a couple functions in druntime which guarantee rounding intermediate
values to float/double precision. Those can be used as required. This is better
than a compiler switch because having compiler switches that influence floating
point results is poor design.
> Since C99 the default x87 behavior is precise.
Not entirely:
float f(float a, float b) {
float d = (a + b) - b;
return d;
}
f:
sub esp, 4
fld DWORD PTR [esp+12]
fld st(0)
faddDWORD PTR [esp+8]
[no write/read to memory here, so no round to float]
fsubrp st(1), st
fstpDWORD PTR [esp]
fld DWORD PTR [esp]
add esp, 4
ret
In any case, let's try your example https://cpp.godbolt.org/z/7sa8dP with dmd
for 32 bits:
pushEAX
pushEAX
fld float ptr 010h[ESP]
faddfloat ptr 0Ch[ESP]
fstpfloat ptr [ESP] // there's the write
fld float ptr [ESP] // there's the read!
fsubfloat ptr 0Ch[ESP]
fstpfloat ptr 4[ESP]// the write
fld float ptr 4[ESP]// the read
add ESP,8
ret 8
It's semantically equivalent to the godbolt asm you posted.
Re: Printing shortest decimal form of floating point number with Mir
On 1/3/2021 8:37 PM, 9il wrote: I didn't believe it when I got a similar answer about IEEE floating-point numbers: D doesn't pertinent to be IEEE 754 compatible language and the extended precision bug is declared to be a language feature. The "extended precision bug" is how all x87 code works, C to C++ to Java. The reason is simple - to remove the problem requires all intermediate results to be written to memory and read back in, which is a terrible performance problem. Early Java implementations did this write/read, and were forced to change it. The advent of the XMM registers resolved this issue, and all the x86 D compilers now use XMM for 32 and 64 bit floating point math, when compiled for a CPU that has XMM registers. Extended precision only happens when the `real` 80 bit type is used, and that is IEEE conformant. If you are aware of an FP bug in the XMM code generation, please file an issue on bugzilla, and I'll be happy to take care of it. The SIMD buglist is now down to one issue (32 byte stack alignment) which is something else. The conversion to and from strings is a different problem.
Re: Beta 2.095.0
On 12/20/2020 5:21 AM, Martin Nowak wrote: Glad to announce the first beta for the 2.095.0 release, ♥ to the 61 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.095.0.html As usual please report any bugs at https://issues.dlang.org -Martin Thank you, Martin and the Sixty-One!
Re: Printing shortest decimal form of floating point number with Mir
If you don't want the formatting code to be part of Phobos, I respect your choice.
Re: Printing shortest decimal form of floating point number with Mir
On 12/21/2020 8:51 PM, 9il wrote: ... I just have thought maybe I have missed something and DLF helps Mir with advertising at least a bit, maybe at least with two-three tweets per year? The last time @D_Programming tweeted something about Mir was in 2016. I thought anything in D.announce got automatically tweeted. Anyhow, if you have a message that you'd like @D_Programming to tweet, please send it to Mike Parker.
Re: Printing shortest decimal form of floating point number with Mir
On 12/21/2020 8:33 PM, 9il wrote: These functions in Phobos would make a great advertisement for Mir. How this possible? A lot more people will have Phobos than Phobos+Mir. If they are perusing the source code and see Mir contributed excellent floating point formatting code, they may have never heard of Mir but have now. Then they'll be likely to be positively disposed towards using Mir because of the high quality code. It's the same idea as HBO offering the first episode for free in a miniseries. People watch the first episode, like it, and then subscribe to HBO. Having them in Mir is already a great advertisement for Mir Since they exist in the C standard library (except for DMC :-( ) they by themselves aren't a compelling reason for someone to use Mir.
Re: Printing shortest decimal form of floating point number with Mir
On 12/20/2020 9:42 PM, 9il wrote: On Sunday, 20 December 2020 at 22:21:56 UTC, Walter Bright wrote: Can the improved parsing be added to D? (It would need to be Boost licensed.) If I am correct there is open PR that set DMD to use C’s primitives for literals parsing. So, for compiler itself we don’t need Mir. That's not correct for the targets that use Digital Mars C. If you mean Phobos - one can use Mir instead. These functions in Phobos would make a great advertisement for Mir.
Re: Printing shortest decimal form of floating point number with Mir
On 12/13/2020 10:47 PM, 9il wrote: Note that D's compiler floating-point literals parsing and Phobos floating-point literals parsing are not precise [5,6,7,8]. It is recommended to use Mir's to!double/float/real to convert floating-point numbers from a string. Can the improved parsing be added to D? (It would need to be Boost licensed.)
Re: Mir vs. Numpy: Reworked!
On 12/3/2020 8:27 AM, 9il wrote: Since the first announcement [0] the original benchmark [1] has been boosted [2] with Mir-like implementations. This is really great! Can you write an article about it? Such would be really helpful in letting people know about it.
DConf Online 2020 was a big success!
I enjoyed #DConfOnline very much, though I miss seeing everyone in person. Thanks go out to all the people who helped out by asking questions that made the chats interesting and informative. Special thanks go out to our speakers who provided the technical presentations: Stefan Koch Steven Schveighoffer Ali Çehreli Mathis Beer Átila Neves Adam D. Ruppe Mathias Lang Alexandru Militaru Robert Schadek And Extra Special Double-Secret Thanks to Mike Parker, who: * created the DConf web site * helped everyone edit and assemble their video presentations * figured out how to run an online conference * organized and ran all the sessions * acted as MC for the entire conference * was on screen running the show and providing running commentary the entire conference * interviewed all speakers * asked intelligent questions to fill in any gaps * took care of all the logistics * took care of managing the contests and handing out swag * and surely number of other critical tasks I haven't even thought of that were necessary for a smooth operation * kept his trademark cool and genial manner through it all * basically was the glue that kept everything together and running smoothly Even after we return to in-person conferences, I'd like to supplement it with these when the Earth is on the opposite side of the Sun. P.S. I'm old enough to still be amazed by having a video conference with people all over the world, and for free! Don't we live in incredible times?
Re: DConf Online 2020...
What's the hashtag? #dconf2020 ?
Re: DIP 1030-- Named Arguments--Formal Assessment
On 9/23/2020 7:01 AM, Arun wrote: How does the compiler handle function lookup when there is an ambiguous match, but the ambiguous function is in a different module? What would be the solution? The same way it handles it without named arguments - an error.
Re: DIP 1030-- Named Arguments--Formal Assessment
On 9/17/2020 6:42 AM, Jean-Louis Leroy wrote: That being said, does the new feature imply any change in the *parameters* themselves? No. I.e. are there changes in the way the function is defined, No. not only in the way it is called? It only affects calling syntax in providing an alternative way to call a function.
Re: Beta 2.094.0
On 9/12/2020 5:26 PM, Manu wrote: What a monster release! We haven't had one like this for a while! Should be something for everyone in it :-)
Re: Beta 2.094.0
On 9/11/2020 12:48 AM, Martin Nowak wrote: As usual please report any bugs at https://issues.dlang.org https://issues.dlang.org/show_bug.cgi?id=21241 (The changelog is basically illegible on Chrome.)
Re: Beta 2.094.0
On 9/11/2020 12:48 AM, Martin Nowak wrote: Glad to announce the first beta for the 2.094.0 release, ♥ to the 49 contributors. This is the first release to be built with LDC on all platforms, so we'd welcome some more thorough beta testing. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.094.0.html As usual please report any bugs at https://issues.dlang.org -Martin Thanks, Martin! Looks like 9 DMD regressions fixed and 69 DMD bugs fixed! (It's hard to tell because the changelog won't render properly on Chrome.)
Re: Beta 2.093.1
On 8/11/2020 2:30 AM, Martin Nowak wrote: Glad to announce the first beta for the 2.093.1 point release, ♥ to the 11 contributors. Thank you, Martin and the 11!
Re: Article: The surprising thing you can do in the D programming language
On 8/20/2020 3:12 AM, aberba wrote: Wrote something on OpenSource.com https://opensource.com/article/20/8/nesting-d Very nice! Thank you, Lawrence!
Re: Github Actions now support D out of the box!
Very nice! Thanks to everyone who helped make this happen.
Re: The ABC's of Templates in D
On 7/31/2020 10:57 AM, H. S. Teoh wrote: Not sure how blog-worthy this is, It is. Please do it!
Re: Beerconf July 2020
On 7/10/2020 12:56 PM, Steven Schveighoffer wrote: But on July 25-26, we will do another online beerconf like was done in June. This went off very nicely! Thanks to all to participated, and especially to Steven for finding good video conferencing software (much better than Skype is) and running it well.
Re: Release D 2.093.0
On 7/12/2020 2:04 AM, Martin Nowak wrote: Glad to announce D 2.093.0, ♥ to the 54 contributors. This release comes with a preview for shared variable initialization, template instantiation statistics, better Windows support of the install.sh script, and higher accuracy GC memory options. http://dlang.org/download.html http://dlang.org/changelog/2.093.0.html -Martin Thank you, Martin! It's on hacker news now, second page. https://news.ycombinator.com/news
