Re: Assertions in production code on Reddit
On Fri, Aug 31, 2018 at 02:02:39PM -0700, Walter Bright via Digitalmars-d-announce wrote: > On 8/31/2018 1:19 PM, Nick Sabalausky (Abscissa) wrote: > > (IF the programmer in question even has the expertise to implement > > such a system correctly anyway - and most don't). > > The closer you can get to the ideal, the better. It's not all or > nothing. > > I'll have done my job if people would just quit justifying sticking > their fingers in their ears and shouting lalalalalalalalal when a bug > is detected. > > Don't you find it terrifying that nobody has even written a book on > the topic? Maybe you should write the first one. :-D T -- Never wrestle a pig. You both get covered in mud, and the pig likes it.
Re: Assertions in production code on Reddit
On 8/31/2018 1:19 PM, Nick Sabalausky (Abscissa) wrote: (IF the programmer in question even has the expertise to implement such a system correctly anyway - and most don't). The closer you can get to the ideal, the better. It's not all or nothing. I'll have done my job if people would just quit justifying sticking their fingers in their ears and shouting lalalalalalalalal when a bug is detected. Don't you find it terrifying that nobody has even written a book on the topic?
Re: Assertions in production code on Reddit
On 08/30/2018 05:31 PM, Walter Bright wrote: https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/ > >High reliability is not achieved by making perfect designs, it is >achieved by making designs that are tolerant of failure. Runtime >checking is essential to this, as when a fault is detected the program >can go into a controlled state doing things like: > >aborting before more harm is done >alerting the user that the results are not reliable >saving any work in process >engaging any backup system >restarting the system from a known good state >going into a 'safe mode' to await further instructions > I'm totally all for all of this in principle. But here's the problem: Aside from "abort the process immediately once...uhh, once the faulty process itself has already successfully *detected itself to be faulty*" (ie, already a violation of the basic principles being promoted in the article), we don't actually HAVE ready-to-use facilities for any of this. Since we don't actually have such facilities, getting people to actually code by them IS going to be an even bigger uphill battle than trying to get them to unittest without any ready-to-use unittesting facilities. And then THAT leads to yet another problem: If they're not actually coding by those principles (which they're obviously not doing because the facilities to do so aren't there), then they ARE occasionally going to be needing *some* code to be run after the fault occurs: For example: - Evaluating the assert condition to even detect something went wrong at all. - Generating the assert failure reporting string. - Generating the stack trace. - Sending the failure string and stack trace to the logging process. Oh wait, we don't have an external logging process facility... - Directly reporting and logging and the failure string and stack trace. (And that list still ignores any cleanup the OS can't/doesn't know to do on our behalf.) And, shit, if it's even POSSIBLE to do any of that within "the process that's already in an undefined state", then clearly we already have enough successful intra-process compartmentalization that the "At this point, we can't rely on ANYTHING!!!" notion is demonstrably bogus anyway. Don't get me wrong, I'd LOVE to be able to do things as you suggest: To have all my fault-handling functionality and STILL have zero-reliance on the faulty process. But we DON'T have those facilities, therefore, nobody outside aeronautics, pacemaker firmware, etc, is realistically going to be able to justify going to all bother of creating such facilities to go along with their website, or text editor, or number-crunching tool, or videogame, etc... (IF the programmer in question even has the expertise to implement such a system correctly anyway - and most don't).
Re: Copr repository providing dmd and dub for Fedora, EPEL and Mageia
On Friday, 31 August 2018 at 19:41:59 UTC, Martin Nowak wrote: Nice one. I see that you're using ldc as bootstrap/host compiler. While that will result in faster binaries (in particular useful for dmd), the official binaries releases are still built with dmd for now. Just worth noting as it might lead to specific bugs not present in the official binaries. I actually used dmd until very recently, and still use dmd on Mageia and EPEL. I switched to ldc because of weird linker errors on Fedora 29, but since it's still in development I have no idea if this is the problem comes from dmd or Fedora. I might go back to using dmd if it turns out to work again.
Re: Copr repository providing dmd and dub for Fedora, EPEL and Mageia
On Friday, 31 August 2018 at 18:44:23 UTC, Laurent Tréguier wrote: The repo is used just like any other Copr repo: sudo dnf copr enable tcg/devel sudo dnf install dmd dub Since Copr also allows building packages for EPEL and Mageia, I'm launching builds for them as well. [1] https://copr.fedorainfracloud.org/coprs/tcg/devel/ Nice one. I see that you're using ldc as bootstrap/host compiler. While that will result in faster binaries (in particular useful for dmd), the official binaries releases are still built with dmd for now. Just worth noting as it might lead to specific bugs not present in the official binaries.
Copr repository providing dmd and dub for Fedora, EPEL and Mageia
Hello D people! (and especially, for this thread, RPM-based Linux users) As dmd 2.082.0 is coming very soon, I thought I'd share this here. I've been using Fedora for quite a while now, and have made a Copr repository to have some tools I didn't find in official Fedora repositories [1]. It contains a few development related packages, among which dmd, phobos and dub at their latest stable version. The repo is used just like any other Copr repo: sudo dnf copr enable tcg/devel sudo dnf install dmd dub Since Copr also allows building packages for EPEL and Mageia, I'm launching builds for them as well. [1] https://copr.fedorainfracloud.org/coprs/tcg/devel/