The debugger and remote nodes

[Vance Shipley]

After much hair pulling I have discovered why the debugger was 
seemingly behaving non-deterministically for me.  I was trying
to use my fancy graphical workstation (*) to debug an embedded
system.  It had seemed to work at times but not always and at
some point I stopped being able to get it to recognize remote
processes at all.  In the end I concluded it's all about paths.

Using debugger's graphical user interface I selected the source
file to interpret with the "Interpreter Dialog" window.  I 
double clicked on the directory bringing up the files and clicked
on the one I wanted.  In the "Selection" field it showed the 
absolute path to the source file when I was done.  This was my 
mistake.  What I needed to do was to type in the _relative_ path
in that selection box and to make sure that relative path was 
also valid on the embedded system.

The way this all seems to work (from reading the source) is that 
if the node is alive it will use rpc:multicall/3 to run 
code:load_abs/1 on all the nodes.  If you give it an absolute 
pathname it will have to be the same on the remote node.  In my
case the embedded systems run out of /export/home/otpuser while
my workstation runs out of /usr/local.  When I used the dialog 
box to select the working source code it found the corresponding
beam file there and told the remote node to load /Users/vances/...

I guess it would help if it inspected the return from multicall
and advised the user of the problem.  On the other hand it could
send the beam file over to the target node and load that using
code:load_binary/3  which would actually be quite handy as you
could be making changes, and probably are, on the workstation
and would other wise need to transfer the new beam file over 
seperately.  A note in the documentation would be the easiest 
fix however.  And now we have a mailing list entry for future
searches.  :)

	-Vance

(*) OS X using the native TkAqua (no X11)