Sun Jun 19 23:34:56 CEST 2005
I'm having another problem with erlang external format : an integer
list in erlang is sometimes encoded as a string (when the integers
all are in the 0..255 range).
That is :
When 107 is used to identify strings in the erlang external format
(108 is for lists) :
/** The tag used for strings and lists of small integers */
public static final int stringTag = 107;
The problem is that the JInterface library tries to make an
OtpErlangString out of the byte sequence and comes out with "
" (with special characters in the string). I've found no way to
convert it to an OtpErlangList. All I can do in this particular case
is get the last n bytes of the stream and cast them as integers
(where n is the size of the original list).
For instance :
[131,107,0,1,1] -> last byte is 1
[131,107,0,4,1,2,3,255] -> last 4 bytes are 1,2,3, 255
When one integer is out of the 0..255 range, the list is not treated
as a string and everything is fine.
Is there a cleaner way either on the server (erlang) or client (java)
side ? I think I'll just add a dummy -1 integer to all the integer
lists I want to transmit...
Thanks a lot,
PS : I guess this is an old one, but are we gonna see a separate
string type in erlang someday ? No troll intended please, just a
Le 15 juin 05 à 22:05, Vlad Dumitrescu a écrit :
> If your application permits, you could also send the binary as-is
> (without any base64 encoding) and do the encoding where and when it
> is needed. Or handle the encoded binary as a regular binary, send
> it and decode it on the Erlang side.
> If you send "normal" Erlang objects, you don't need to use
> OtpOutputStream at all, it is handled behind the scenes by for
> example OtpMBox.send/receive.
>> From the OtpOutputStream class documentation :
>> Provides a stream for encoding Erlang terms to external format,
>> for transmission or storage.
> Yes, for storage, you don't need any magic header, for transmission
> you do.
More information about the erlang-questions