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!aioe.org!peer01.am4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx22.iad.POSTED!not-for-mail Subject: Re: Ada Community and GDB/Python problems Newsgroups: comp.lang.ada References: <4cc63bc8-ff8a-4f9e-8649-4e50d7448674@googlegroups.com> From: Rick Newbie User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Message-ID: NNTP-Posting-Date: Sun, 09 Feb 2020 17:28:12 UTC Date: Sun, 9 Feb 2020 09:28:12 -0800 X-Received-Bytes: 3958 X-Received-Body-CRC: 1914622014 Xref: reader01.eternal-september.org comp.lang.ada:58015 Date: 2020-02-09T09:28:12-08:00 List-Id: On 2/7/2020 10:19 PM, J-P. Rosen wrote: > Le 07/02/2020 à 23:39, joakimds@kth.se a écrit : >> I would recommend tracing to "debug" what your application is doing >> (either print messages to standard out or logging to a file). In a >> multi-task application I've preferred tracing for a long time over >> stepping through code using a debugger like gdb. > > I agree, I use tracing every day, and gdb no more than 2-3 times a year. > Not that there is any problem with gdb, but (at least for my kind of > debugging), I find tracing more efficient. > > Especially if you are using multiple tasks, I recommend the > "Debug" package that you can get (free) from > http://adalog.fr/en/components.html#Debug > > Among other things, it shows task switches and allows you to trace > protected calls (reminder: you are not allowed to print from within a > protected operation). > On 2/7/2020 10:19 PM, J-P. Rosen wrote: > Le 07/02/2020 à 23:39, joakimds@kth.se a écrit : >> I would recommend tracing to "debug" what your application is doing >> (either print messages to standard out or logging to a file). In a >> multi-task application I've preferred tracing for a long time over >> stepping through code using a debugger like gdb. Thanks, also thnks for the link to the Ada tools. Actually I use tracing in my current C++ program and it is helpful, but I still prefer to step through new code at least once to see that the logic works as intended and the variables are computed correctly. As for my original problems, I have finally figured out what the problem is and will post a solution further down. I must say I find it astounding though that Adacore releases a package like the community edition that contains these obvious bugs. A simple install on a clean Windows machine should have revealed the problem. My guess is they have multiple Python installations and never loaded the script from the location that is shipped with the Community pack. ------- The following environment variables must be set PYTHONHOME = D:\GNAT\2019\share\gdb-8.3\python-2.7.16 PYTHONPATH=D:\GNAT\2019\share\gdb-8.3\python-2.7.16\lib In PATH make sure D:\GNAT\2019\bin is set before the path to slickedit if you have slickedit. Slickedit comes with python it might interfere with the GPS version of Python. In D:\GNAT\2019\share\gdb-8.3\python-2.7.16\Lib\weakref.py there is an error: from _weakref import ( getweakrefcount, getweakrefs, ref, proxy, CallableProxyType, ProxyType, ReferenceType), _remove_dead_weakref) Change to: from _weakref import ( getweakrefcount, getweakrefs, ref, proxy, CallableProxyType, ProxyType, ReferenceType) #from _weakref import _remove_dead_weakref the _remove_dead_weakrefimport will not be found, so we must comment it out. GDB will now run, but complain that it can't find a path to an index directory which may or may not be related but seems to cause no more errors