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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:3a0d:: with SMTP id m13mr2995265itm.34.1554533373621; Fri, 05 Apr 2019 23:49:33 -0700 (PDT) X-Received: by 2002:a9d:618d:: with SMTP id g13mr11727633otk.254.1554533373394; Fri, 05 Apr 2019 23:49:33 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!78no186101itl.0!news-out.google.com!l81ni264itl.0!nntp.google.com!136no186050itk.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 5 Apr 2019 23:49:33 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=70.109.61.2; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 70.109.61.2 References: <1e27ce78-217d-4adc-8380-30f6d4fc5fdc@googlegroups.com> <878swq2q1m.fsf@nightsong.com> <1352f43a-e549-4ddd-8e67-2e1c2ca25395@googlegroups.com> <2252d440-e11e-4afb-8a69-207c531c0846@googlegroups.com> <3db67a14-6509-4222-a89e-3dcaa4fbf712@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <490dc520-b858-4e7e-b1b6-2ada86737e03@googlegroups.com> Subject: Re: Intervention needed? From: Jere Injection-Date: Sat, 06 Apr 2019 06:49:33 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:56086 Date: 2019-04-05T23:49:33-07:00 List-Id: On Saturday, April 6, 2019 at 12:25:48 AM UTC-4, alby....@gmail.com wrote: > On Saturday, April 6, 2019 at 12:38:57 PM UTC+11, Jere wrote: > > On Friday, April 5, 2019 at 11:17:55 AM UTC-4, Optikos wrote: > > > On Friday, April 5, 2019 at 1:45:20 AM UTC-4, Maciej Sobczak wrote: > > > > > As gdb can be scripted, the tests that Maciej describes can proba= bly be=20 > > > > > automated, > > > >=20 > > > > Yes. > > > >=20 > > > > > albeit with considerable effort, > > > >=20 > > > > Not really. I would say there is no need for this effort to be high= er than with any other form of test automation. Note that as with anything = else in software, recurring problems can be mitigated by additional code. T= hat is, if testing this way is difficult, then the difficulty is similar fo= r the whole class of similar tests and as such that difficulty can be refac= tored away to additional utility (library/framework/etc.) with simpler (hig= her-level) interface. > > > >=20 > > > > > especially if the scripts=20 > > > > > should be robust to evolution of the SW under test (changing the = line=20 > > > > > numbers of the required breakpoints, etc.) > > > >=20 > > > > This is a wider problem of traceability. You have to solve this pro= blem anyway for the coverage analysis, for example. And the solution, whate= ver you happen to use (like tool-readable labels in source comments), will = help with debugging, too. > > > >=20 > > > > In any case, yes, some projects need the debugger to test individua= l memory locations. The lack of proper tools is a technology risk. > > > >=20 > > > > > However, I don't think that gdb or other current debuggers are=20 > > > > > ideal tools for automated checking of internal states. > > > >=20 > > > > They are not. But a non-ideal working debugger is still better than= a not working one. > > >=20 > > > Which features do you consider as missing in GDB regarding GNAT Ada t= hat make GDB non-ideal? > >=20 > > I can't speak for GDB specifically, but at some point (2015 maybe?) the= y > > redid the GUI interface in GPS to the debugger and it became completely= =20 > > unintuitive for me. The few times I have had to debug Ada code involve= d > > access types and manual memory management. They used to have a really > > good interface that would visually display records and fields, and when > > I clicked on an access type variable, it would pop open another box wit= h > > the record that variable pointed to. For custom containers this was re= ally > > handy for debugging. It was a very handy and visual way to map out mem= ory > > for those rarer times I had to actually manage it. Now I just use my > > Smart_Access packages (once they fixed the GNAT bugs), though I still= =20 > > don't expose those to clients. >=20 > Has anyone tried the debugging support in VisualAda. It supports both GDB= via > the MI interface and if you opt in to use the MS linker, you can also use= the > native MS debugger. >=20 > Both options support setting breakpoints, view/change symbols/variables, = etc.. >=20 > Note the native debugger will also present the internal symbols/variables= , not > sure if this is a good or a bad thing?.=20 >=20 > One of the enhancements that I plan for the next release is adding some d= ebug > visualizers for types such as strings and unbounded strings, which by def= ault > are not presented / shown in a user friendly manner >=20 > Suggestions on other improvements are welcome >=20 > Alex I started to try it out seriously a while back, but it required a specific= =20 installation path of some things and I did not have that setup the way it wanted. I've been meaning to take a stab at it again. I've just been=20 distracted.