🚀 go-pugleaf

In article <d#lnmz+.daveb@netcom.com>,
daveb@netcom.com (Dave Briccetti) writes:
>
>dic5340@hertz.njit.edu (David Charlap) writes:
>: Not really.  You'll have to remote-debug it.  You can't run a debugger
>: on the same machine as the PM code you're debugging.  It halts lots of
>: things.
>
>What???  I've been doing it for years.  Occasionally I'll have to put
>printf's in, but most of the time I do quite well with Codeview or IPMD.

There can be problems debugging PM programs, so IPMD actually has two
modes for PM debugging - synchronous and asynchronous.  From the on-line
help:

 When the C Set/2* debugger is operating in synchronous mode, the
 messages that are passed between PM applications are answered by their
 target applications in the order that they were created.  Messages are
 not lost.  The messages that are passed within the C Set/2* debugger,
 however, take priority over any other messages that are passed in the
 system.

 When the program being debugged is stopped and the debugger is in
 synchronous mode, other PM applications are locked, leaving the
 debugger free to operate.  In synchronous mode, you will not be able
 to use any other PM applications that are running.

 When the C Set/2* debugger is operating in asynchronous mode and the
 program you are debugging is stopped, the debugger immediately
 responds to messages that have been sent to the program being debugged
 on this program's behalf.  The C Set/2* debugger answers the messages
 with a simple default response, freeing up other processes to operate
 while the debugger has control.  When you are running the C Set/2*
 debugger in asynchronous mode, other PM applications running in the
 system are not blocked when the program being debugged stops.

 Warning:  Do not operate the C Set/2* debugger in asynchronous mode if
 the PM application that you are debugging requires the appropriate
 response to its messages.  For example, a dynamic data exchange (DDE)
 message would require the appropriate response.

-tim