Re: [Distel-hackers] recent commit breaks multi-module debugging
Status: Beta
Brought to you by:
lukeg
From: Bill C. <bil...@gm...> - 2007-06-20 21:41:10
|
Matthias Radestock <mat...@so...> writes: > Bill Clementson <bil...@gm...> writes: > >>> I still don't understand the need for the change. Do you have a >>> reproducible test case? >> >> Yes, see below. > > That doesn't work for me at all. I gave up on the embedded erlang shell > very early on when i started using distel. I guess that's why ;) But, as I said in my reply, the same behaviour also occurs if you don't use the embedded erlang shell (at least, it does for me). > When i get to the point in the script where the edb buffer should pop up > it just says "no more errors" in the mode-line, and the edb buffer shows > no processes. I can happily list processes, toggle interpretation etc, > so emacs is definitely talking to the node; debugging just isn't working > though. > > By contrast, when I run your example in a separate node, started from a > shell, everything works fine. I can debug, stop and start the node, > continue debugging etc. That's odd. When I run the example in a separate node, I get the same behaviour as I do when I run it in the Emacs Erlang node (e.g. - I can not resume debugging in distel once a connection is broken). > Perhaps the behaviour is different for me because I am running xemacs. I'm using emacs and not xemacs, so that might make a difference. >> The main problem occurs when you have done something to change the >> "state" of the erlang node that is being debugged. Once this happens, >> there is currently no way in distel to reset things. > > For me, when the debugged node goes down, emacs kills the edb buffer and > resets the interpreted status of the modules I was debugging. > > Does that not happen for you? Yes, it kills the buffer; however, the module is left in a state of interpreted being "on" (if you followed the steps EXACTLY as they were in my test case, this is what should have happened after step #10.). Therefore, after I start up the node again, I have to toggle interpreted to "off" using "C-c C-d i". When I toggle it to "off", the edb-monitor-node-change-p function detects that the monitor buffer doesn't exist so it restarts it. Then, when I press "C-c C-d i" a second time to toggle interpreted "on", the edb buffer already exists. In this scenario, you can press "C-c C-d i" multiple times and it will not add the module to the edb-interpreted-modules variable. (This was the reason why I originally put the code to kill the edb buffer in the edb-toggle-interpret function when interpreting was being turned "off") >> I think there needs to be some way to "reset" debugging in distel. It >> would be nice if this could occur automatically (for example, when >> attaching to a node or when a connection to a debugged node is lost). > > Well, it does do that for me. > >> However, if this might cause problems, maybe it would be better to >> just have a separate function to reset debugging. What do you think? > > What's wrong with just killing the edb buffer? That should work; it has > a hook that clears edb-interpreted-modules, resets breakpoints etc. When you screw up the connection with a node while debugging, you are normally in a mode where interpreted is "on" in the module that you're debugging. Therefore, you would need to turn interpreted "off" and then delete the edb buffer in order to avoid the problem I described above. I would prefer to have this done automatically for me rather than have to remember to do it (and in the correct sequence) each time. What specific problems do you feel there are with the revised patch that I suggested? It still allows you to do multi-module debugging across multiple nodes. You just have to toggle debugging on with "C-c C-d i" when you change the node that distel is connected to. You don't lose your breakpoints in any of the nodes that you're debugging. -- Bill Clementson |