[Pydev-cvs] org.python.pydev.debug/docs jpydbg_doc_email.txt,NONE,1.1

[Aleksandar T. <at...@us...>]

Update of /cvsroot/pydev/org.python.pydev.debug/docs
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv32727/docs

Added Files:
	jpydbg_doc_email.txt 
Log Message:
jpydbg documentation

--- NEW FILE: jpydbg_doc_email.txt ---
Subject:
Re: jpydbg protocol documentation?
From:
jean-yves MENGANT <jym...@if...>
Date:
Fri, 26 Mar 2004 12:16:56 +0100
To:
Aleks Totic <a...@to...>

Hi ,

Since I mainly use this protocol internally , I never take the time to 
document it , nevertheless I'll provide you with first basic semantics 
with jpydbg interaction and client side syntax right now  :

first jpydbg is started waiting for incoming commands on a socket 
(this is the same principle as the Java Debugging interface) the 
socket listener may either be the jpydbg client or jpydbg server 
itself depending on the parameters provided to the main jpydbg entry.
(jpydbg server listening will usually implies security problems when  
remote debugging over a firewall) 
>From a gui debugging standpoint with jedit I have handled that inside 
a jpydbg configurable option pane.

So I'll will also here provide you with entries to look at inside 
jpydbg.py in order to better understand the debugger's semantics :  

at that initial start state the jpydbg state is : active not debugging
 
when a command is populated to jpydbg it is first handled by the
jpydbg parseSingleCommand entry where you'll see the available list of 
command :
CMD : execute a single python command and return the result back (OK 
meaning that the python command completed successfully) 
READSRC : Read source and populate it to client side (FOR REMOTE 
DEBUGGING)
SETARGS : set debugging arguments
DBG : enter DEBUG mode( Only once )
STOP : terminate jpydbg

each command before is handle by a simple decicated method , the 
arguments requested by the above command are parsed by each of this 
method ; this parsing is straightforward and looking at the code 
should be sufficient there.

Entering in DEBUG mode is a two step semantics :

issue a SETARG command to populate parameters to jpydbg
issue a DBG command to start debug mode.

When jpydbg enters DEBUG mode no more COMMANDS may be handled only 
debugger's SUBCOMMAND will be accepted ; looking at parseSubCommand 
inside jpydbg provides you the list :

CMD : execute a single python command using the current DEBUGGEE stack 
context (interesting to manipulate the debuggee data from a context 
console)
READSRC : same as in non debugging context.(used mainly when a new 
module comes into debugging scope)
NEXT : stop on next python instruction
STEP : step into next instruction
RUN : resume execution until the end of the PGM or the next Breakpoint
BP+ : set a breakpoint
BP- : unset a breakpoint
STACK : populate back the python stack infos.
LOCALS : populate  the local variables infos
GLOBALS : populate the global variables infos

Debugging events are handled by overridding the basic debugging python 
module event handlers (bdb.py provided with the python package)
populated events are :
user_call : entering function call. <CALL ..... /CALL> xml message 
populated
user_line : entering new user line <LINE .... /LINE> xml message 
populated
user_return : leaving function <RETURN .... /RETURN> xml message 
populated
user_exception : python exception handler <RETURN .... /RETURN> xml 
message populated

stdout is captured and populated a STDOUT xml message to the client 
side where it's up to the client side implementer to display the 
information where he wants.

events populate XML EVENT to the client side , those event may be 
captured  and handled from there then 

in DEBUG mode jpydbg is always waiting for the next command over the 
wire , when not in RUN state ( RUN requested and no breakpoint reached 
yet)
When in RUN state no interrupt capability is provided today.

stdin : I did nothing special here for the moment, I did not even test 
it for now , but I suspect it should block the debugger server now 
(I'll look at that)

hope it helps
Let me know if you need complementary infos
Jean-Yves

On Thu, 25 Mar 2004 17:25:02 -0800, Aleks Totic wrote:

>> Hi,
>> after hacking some more, I understand your protocol a little better:
>> STOP: exits the debugger
>> READSRC <filename>: reads in a file
>> SETARGS <arguments>: sets arguments before execution
>>
>> The mystery commands are still:
>> CMD: what are its arguments, etc. For example CMD RUN gave me OK,
>> but I could not see any evidence of my program running? It looks
>> like the string is just compiled and executed straight.
>>
>> DBG: just like CMD. What are the arguments?
>>
>> Also, what happens with stdio when your program runs? It looks
>> like you capture it, and send it back. How does stdin work?
>>
>> Aleks
>>
>> jean-yves MENGANT wrote:
>
>>>> Hi Alek ,
>>>>
>>>> That's a cool idea , I was also on my side pondering on the way to
>>>> integrate the jpydbg python debugging backend into Eclipse at some
>>>> times since the debugger backend just send XML messages and is not
>>>> neither JEdit nor Swing dependant it may be integrated in any IDE.
>>>>
>>>> So I am very happy to help on this :
>>>>
>>>> - All the Python stuff should be reusable as is for Eclipse :
>>>> jpydbg.py : module is the debugger core just inheriting the
>>>> standard bdb.py basic python debugging module.
>>>> you may also use Inspector.py to generate an xml tree
>>>> representation
>>>> of a given python source to integrate into an IDE tree
>>>>
>>>> - From a Java standpoint I have tried to cleanly isolate both the
>>>> swing and Jedit idiosynchrasis inside isolated packages , which
>>>> are
>>>> dealing with the JEdit / Swing gui sides. Since Eclipse will rely
>>>> upon
>>>> swt those packages won't be usefull.
>>>>
>>>> - org.jymc.jpydebug + org.jymc.jpydebug.utils : contains connector
>>>> classes to the Python debugging environment and are fully usable
>>>> for
>>>> an Eclipse integration.(No Swing / No Jedit package references
>>>> inside)
>>>>
>>>> - Inside the org.jymc.jpydebug.swing.ui , the ClientDebuggerShell
>>>> class is a basic debugging GUI standalone tool which you can use
>>>> to
>>>> send and test the basic debugging commands to jpydebug.py. This
>>>> one is
>>>> also an example to start integrating the debugging API into
>>>> eclipse.
>>>>
>>>> - The PythonDebugContainer class inside org.jymc.jpydebug.swing.ui
>>>> contains the list of debugger's command as constant locating on
>>>> the
>>>> top of the class , and basic methods which implements them for a
>>>> swing
>>>> context. (No JEdit dependencies there )
>>>>
>>>> - All debuggers return responses or events are in XML , and
>>>> parsed by
>>>> the JpyDebugXmlParser java class
>>>>
>
>>
>> ___[ Pub
>> ]____________________________________________________________
>> Inscrivez-vous gratuitement sur Tandaime et gagnez un voyage à
>> Venise
>> www.Tandaime.com/index.php?origine=4 Tandaime, et la vie vous
>> sourit !






_____________________________________________________________________
Envie de discuter en "live" avec vos amis ? Tilicharger MSN Messenger
http://www.ifrance.com/_reloc/m la 1hre messagerie instantanie de France