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!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.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: Intervention needed? Date: Thu, 4 Apr 2019 19:13:07 -0500 Organization: JSA Research & Innovation Message-ID: References: <1e27ce78-217d-4adc-8380-30f6d4fc5fdc@googlegroups.com> <878swq2q1m.fsf@nightsong.com> Injection-Date: Fri, 5 Apr 2019 00:13:08 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="4830"; 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; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader01.eternal-september.org comp.lang.ada:56078 Date: 2019-04-04T19:13:07-05:00 List-Id: "Niklas Holsti" wrote in message news:gglu1uFlu3fU1@mid.individual.net... ... > That is exactly the form of trial-and-error "debugging" that I abhor, > because it usually provides a mass of instances from which I find it hard > to extract any general understanding. Moreover, I find it less troublesome > to modify the logging/tracing set-up before a re-run. The recompilation > time is insignificant compared to the thinking time. On top of which, "logging" doesn't have to be a fully static, on-off proposition. Most of my programs have multiple levels of logging that can be controlled for a running program. So if a problem shows up in some area, turning on the logging for that area often will show enough information to eliminate the problem without any recompilation (well, until deploying the actual fix). For instance, the Janus/Ada compiler has an extensive tracing menu that can be accessed with both a compiler option, and by placing a pragma in the problematic source code. I almost never change the compiler code until/unless that tracing proves insufficient. I've had to write substantial new tracing occassionally, but that often is a worthwhile permanent addition to the code. The number of times I have to write new, one-time tracing code is probably less than one in twenty bugs. Using a debugger isn't very practical for Janus/Ada, because each compiler pass depends on the previous one, and thus one can't just run some pass of the compiler without a complete set of temporary files from the previous pass. Plus, the temporary files are named with the process id that created them, and of course the debugger uses a different PID. And of course a completed run of a pass deletes or modifies some of the temporary files. There are ways around those issues, but there rarely is a problem that justifies going to that level. (I only recall doing it once, and that may have been more about testing the debugger rather than using it for an actual purpose.) The other programs that I've worked on in recent years (the Claw Builder, the Trash-Finder spam filter, and the AdaIC web server) also would be difficult to run under a debugger (the first because of GUI interference, and the latter two because of the real-time and never-terminating nature). Logging/tracing has worked well in all of those. Randy.