Re: distel and emacs unicode-2 (again)

Hi Pierre,

Pierre <[email protected]> writes:

>> If the problem only occurs with the unicode-2 branch of CVS emacs,
>> have you investigated the possibility that the node communication
>> might be undergoing a unicode transformation and thus not being
>> interpreted correctly in distel? You should be able to verify this
>> if you:
>> 
>> 1. Start up emacs 23-unicode-2.
>> 2. Do (setq fsm-use-debug-buffer t) so that you can trace the node
>> communication.
>> 3. Do the sequence of distel operations that were failing for you
>> before (presumably, this was just connecting to the node "C-c C-d n"
>> and trying to run some command like list processes "C-c C-d l").
>> 4. Save the contents of the *fsm-debug* buffer (you might want to also
>> switch to hexl mode and save the contents in that format too).

Actually, my hexl suggestion doesn't appear to be necessary as the
ordinary fsm-debug output is fine.

>> 
> Here is the content of *fsm-debug* with emacs 23:
> EVENT: init - "pemacs"
> SEND : "^@^Fpemacs"
> STATE: epmd-process -> epmd-recv-port-resp
> EVENT: data - "\204\273"
> TERM : -31557
> FAIL : "Error on event data in stat..." (buffer: #<buffer *reg group-leader*>)
>
> ^@^F is in red (and cannot even be copy-paste anywhere). I do know if the p in
> front of emacs is supposed to be there at all.
>
> I guess this is the problem but I have not clue what it actually means. 
>
> Any idea ?

Ok, first of all, don't take whatever I say here as definitive as I've
never debugged this type of issue in distel before and my thought
process is based solely on bench-checking the code and your fsm debug
buffer output. Therefore, I'll be a bit more verbose in my
explanations so that you can see my thought process.

Luke pointed to 2 protocol documents in this post:
http://article.gmane.org/gmane.comp.lang.erlang.distel.devel/107

The erl_ext_dist.txt document is the one to look at here.

So, let's step through the debug output:

> EVENT: init - "pemacs"
> SEND : "^@^Fpemacs"

Looking at the erl_ext_dist.txt document that Luke mentioned, we can
interpret the "pemacs" that was sent by distel:

   3.1.3 PORT_PLEASE_REQ   (112)

      1       n
   +-----+----------+
   | 112 | NodeName |
   +-----+----------+

An ASCII "p" is "112" and "emacs" is the node that you're attempting
to connect to; therefore, when distel is sending out a message of
"pemacs", distel is trying to find out what port to communicate with
the erlang node "emacs" on.

> STATE: epmd-process -> epmd-recv-port-resp
> EVENT: data - "\204\273"

Looking at the document again, I see that the response is defined as:

   3.2.3 PORT_OK_RESP      ()

       2
   +--------+
   | PortNo |
   +--------+

So, the "\204\273" is supposed to be 2 bytes corresponding to the port
number. The STATE portion of the debug log conveniently told us what
distel functions were called. In this case, it was epmd-process
calling epmd-recv-port-resp. Looking at the code for
epmd-recv-port-resp, I see that the code to convert the 2 bytes
returned in the response to an actual port number is:

(+ (ash    (elt arg 0) 8)
   (logand (elt arg 1) 255))

So, if I convert the response to a port number, I get:

(+ (ash 204 8) (logand 273 255)) -> 52241

Actually, the full s-expression in epmd-recv-port-resp is:

(fsm-terminate (+ (ash (elt arg 0) 8)
		       (logand (elt arg 1) 255))))

So, fsm-terminate is called with the result from this calculation. The
fsm-terminate function outputs the result to the fsm debug buffer:

> TERM : -31557

It would appear that 52241 is not equal to -31557, so this is an
error. Somehow, the original response that was sent to distel was
converted into something different (see below). The original calling
function is fsm-event and that calls fsm-fail with the error:

> FAIL : "Error on event data in stat..." (buffer: #<buffer *reg group-leader*>)

So, this explains what all of the output in the fsm debug buffer is
and would appear to explain why things aren't working properly. But,
why do the port numbers not match?

Since distel uses emacs buffers as the mechanism for storing data that
is being passed between processes, I believe that the probable reason
for the error is that the default buffer format is different in the
CVS unicode-2 version of emacs from the default in the "standard"
emacs. Luke alluded to this as a potential problem in one of his
earlier messages to Matthew:
http://article.gmane.org/gmane.comp.lang.erlang.distel.devel/103

Therefore, the 2 bytes that are passed back in the response are
possibly being "converted" into a different (unicode?) format when
they are stored in the buffer. Subsequently, when they are retrieved
and sent to the epmd-recv-port-resp function, they are different
bytes. If you can confirm that this is indeed the problem, then you
might want to look at providing a patch that either explicitly sets
the buffer character format for the distel communications buffers to a
consistent value (probably the better fix) or converts the data from
those buffers to ascii for the relevant distel functions.

The above is all just speculation on my part since I don't use the
unicode-2 branch of CVS emacs myself. It would be better to debug the
actual fsm calls; however, this should give you something to start
with.

Hope that helps. 

--
Bill Clementson




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/