From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Record operations (Algebraic Data Types and printing) Date: Thu, 11 Oct 2018 16:32:35 -0500 Organization: JSA Research & Innovation Message-ID: References: <0f5608ef-0038-491c-b15f-f67bcc76fae8@googlegroups.com> <00285ebf-6ede-44da-848f-456930dc7475@googlegroups.com> <3620199a-f025-4099-83ad-a1e5042dc6c0@googlegroups.com> <8903c94f-efc7-4a2c-9513-ee17890b49d2@googlegroups.com> Injection-Date: Thu, 11 Oct 2018 21:35:48 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="18602"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:54545 Date: 2018-10-11T16:32:35-05:00 List-Id: "G. B." wrote in message news:pplfgr$63i$1@dont-email.me... ... > But are all Ada debuggers and simulators in such a state? I find staring > at > trace logs unproductive in comparison. Maybe, though, some programmers > like the challenge. Debuggers have their place, but a lot of problems either don't lend themselves to using a debugger (because they're not reproducible) or don't need it (because the failure itself gave enough information to fix it). In both of these cases, trace information can be very valuable. And (IMHO) in a well-designed program, you aren't recompling to add it because it is already there (almost all of my programs have a way - GUI box, command line option, etc. - to get additional tracing/logging from the norm). The "don't need it" case might need a bit of explanation: failure of language-defined checks in Janus/Ada have always contained information about the failures and a call walkback with line numbers and subprogram names. (No wacky tools needed to get that!) That's also triggerable from program code, so we use the same mechanism for internal errors. (Also to note: for servers like our web server and spam filter, we can log that information into the usual server log.) With information like that, it's possible at least 75% of the time to figure out what the actual problem was and how to fix it. Turning on the existing tracing for the affected subsystems will figure out many of the remaining cases. So I tend to use debuggers only when reproducible (it's always going to take more than one attempt to figure out what is going wrong, 'cause backwards execution isn't a realistic option) and mysterious. The top case of that is when a hardware fault occurs rather than a language-defined check failure. Those are generally considered bugs in the Janus/Ada compilation system (although users can write erroneous code that will cause them, thru interfacing, unchecked_conversion, or streaming), and thus one can't really trust what was *supposed* to happen - the generated code is likely wrong and needs fixing. Image for all types should make it easier to construct those logs and give better information in exception messages for user-defined exceptions. So that seems like a net win, regardless of whether a debugger could have given somewhat similar information. Randy.