hi, dear list !
when i try to send a symbol containing spaces AND numbers prepended by zeros with [pdsend], the zeros get truncated in unpredictable ways.
to see what i mean, please do the following:
1.) open the [netreceive] help patch 2.) open a console and try the following command:
========================== LINUX/OSX: ===============================
~$ echo "01 02 0003 004 05.txt" | /usr/bin/pdsend 3001 localhost udp
=========================== WINDOWS: ================================
echo "01 02 0003 004 05.txt" | "C:\Program Files\Pd\bin\pdsend.exe"
3001 localhost udp
=====================================================================
the resulting output from [netreceive -u 3001] will be:
udp: "01 2 3 4 05.txt"
the same is true if a symbol like this is sent from a .tcl script to a corresponding [receive] object in a PD patch (using the "::pd_connect::pdsend" function).
is there any way to sent such a symbol untruncated using the methods above, other than transforming them first to ascii code numbers and send them as a list of numbers, using [list tosymbol] later in the "PD-world" to symbolize it?
thanks for all clarifications
oliver
pdsend/pdreceive uses the FUDI protocol (= Pd messages), where strings that look like floats are converted to a float atom. When serializing between FUDI strings and Pd atoms, the textual result is not guaranteed to be the same for number atoms.
the resulting output from [netreceive -u 3001] will be:
udp: "01 2 3 4 05.txt"
Are you sure? Because I get
1 2 3 4 05.txt
which is what I would expect. The float atoms are properly serialized to their string representation (Pd doesn't remember the original text!) and "05.txt" is actually a symbol.
is there any way to sent such a symbol untruncated using the methods above,
If you want to send it as a single symbol, that's possible, you just have to escape the whitespace:
"01\ 02\ 0003\ 004\ 05.txt"
Now, if you want to send the tokens as individual symbols, you can escape them with a backslash:
"01 \02 \0003 \004 \05.txt"
Note the different position of the backslash! I'm not sure if this particular escaping behavior is actually intended or just works by chance... Generally, it would be great to document Pd's string escaping, because it is not entirely obvious.
Christof
On 17.03.2021 11:40, oliver wrote:
hi, dear list !
when i try to send a symbol containing spaces AND numbers prepended by zeros with [pdsend], the zeros get truncated in unpredictable ways.
to see what i mean, please do the following:
1.) open the [netreceive] help patch 2.) open a console and try the following command:
========================== LINUX/OSX: ===============================
~$ echo "01 02 0003 004 05.txt" | /usr/bin/pdsend 3001 localhost udp
=========================== WINDOWS: ================================
echo "01 02 0003 004 05.txt" | "C:\Program Files\Pd\bin\pdsend.exe" 3001 localhost udp
=====================================================================
the resulting output from [netreceive -u 3001] will be:
udp: "01 2 3 4 05.txt"
the same is true if a symbol like this is sent from a .tcl script to a corresponding [receive] object in a PD patch (using the "::pd_connect::pdsend" function).
is there any way to sent such a symbol untruncated using the methods above, other than transforming them first to ascii code numbers and send them as a list of numbers, using [list tosymbol] later in the "PD-world" to symbolize it?
thanks for all clarifications
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2021-03-17 14:25, Christof Ressi wrote:
pdsend/pdreceive uses the FUDI protocol (= Pd messages), where strings that look like floats are converted to a float atom. When serializing between FUDI strings and Pd atoms, the textual result is not guaranteed to be the same for number atoms.
i see
the resulting output from [netreceive -u 3001] will be:
udp: "01 2 3 4 05.txt"
Are you sure? Because I get
1 2 3 4 05.txt
yes, i am sure, at least for my system (Win7 / PD 0.51.4). see attached .jpg. (i'm getting the same truncations without the quotes btw.)
which is what I would expect. The float atoms are properly serialized to their string representation (Pd doesn't remember the original text!) and "05.txt" is actually a symbol.
is there any way to sent such a symbol untruncated using the methods above,
If you want to send it as a single symbol, that's possible, you just have to escape the whitespace:
"01\ 02\ 0003\ 004\ 05.txt"
thank you very much, that was a pointer in the right direction ! i figured, since the white spaces by themselves where transmitted correctly, i wouldn't have to worry about them, but literally escaping white spaces within my .tcl script (by forcing a backslash before every white space) seems to do the trick !
best
oliver
he gets 01 because the full symbol is "01
and the last symbol is actually 05.txt"
strange, why echo is sending " ... (!?)
Em Qua, 17 de mar de 2021 12:33, oliver oliver@klingt.org escreveu:
On 2021-03-17 14:25, Christof Ressi wrote:
pdsend/pdreceive uses the FUDI protocol (= Pd messages), where strings that look like floats are converted to a float atom. When serializing between FUDI strings and Pd atoms, the textual result is not guaranteed to be the same for number atoms.
i see
the resulting output from [netreceive -u 3001] will be:
udp: "01 2 3 4 05.txt"
Are you sure? Because I get
1 2 3 4 05.txt
yes, i am sure, at least for my system (Win7 / PD 0.51.4). see attached .jpg. (i'm getting the same truncations without the quotes btw.)
which is what I would expect. The float atoms are properly serialized to their string representation (Pd doesn't remember the original text!) and "05.txt" is actually a symbol.
is there any way to sent such a symbol untruncated using the methods above,
If you want to send it as a single symbol, that's possible, you just have to escape the whitespace:
"01\ 02\ 0003\ 004\ 05.txt"
thank you very much, that was a pointer in the right direction ! i figured, since the white spaces by themselves where transmitted correctly, i wouldn't have to worry about them, but literally escaping white spaces within my .tcl script (by forcing a backslash before every white space) seems to do the trick !
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Oh, you're right! I just realized that he was using cmd.exe, while I was using a Msys2 shell. That explains the difference: cmd.exe keeps the quotations for echo, but the Msys2 shell strips it away.
Christof
On 17.03.2021 22:10, José de Abreu wrote:
he gets 01 because the full symbol is "01
and the last symbol is actually 05.txt"
strange, why echo is sending " ... (!?)
Em Qua, 17 de mar de 2021 12:33, oliver <oliver@klingt.org mailto:oliver@klingt.org> escreveu:
On 2021-03-17 14:25, Christof Ressi wrote: > pdsend/pdreceive uses the FUDI protocol (= Pd messages), where strings > that look like floats are converted to a float atom. When serializing > between FUDI strings and Pd atoms, the textual result is not > guaranteed to be the same for number atoms. i see > >> the resulting output from [netreceive -u 3001] will be: >> >> udp: "01 2 3 4 05.txt" > Are you sure? Because I get > > 1 2 3 4 05.txt yes, i am sure, at least for my system (Win7 / PD 0.51.4). see attached .jpg. (i'm getting the same truncations without the quotes btw.) > > which is what I would expect. The float atoms are properly serialized > to their string representation (Pd doesn't remember the original > text!) and "05.txt" is actually a symbol. > >> is there any way to sent such a symbol untruncated using the methods >> above, > If you want to send it as a single symbol, that's possible, you just > have to escape the whitespace: > > "01\ 02\ 0003\ 004\ 05.txt" thank you very much, that was a pointer in the right direction ! i figured, since the white spaces by themselves where transmitted correctly, i wouldn't have to worry about them, but literally escaping white spaces within my .tcl script (by forcing a backslash before every white space) seems to do the trick ! best oliver _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list <https://lists.puredata.info/listinfo/pd-list>
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 3/17/21 2:25 PM, Christof Ressi wrote:
Note the different position of the backslash! I'm not sure if this particular escaping behavior is actually intended or just works by chance... Generally, it would be great to document Pd's string escaping, because it is not entirely obvious.
something like that was reported as https://github.com/pure-data/pure-data/issues/1277
i'm pretty convinced that the backslash escaping of numbers to force them to symbols is accidental and should not be relied on. whenever i find the time, i would like to fix this bug.
gfmdasr IOhannes
-
Christof Ressi -
IOhannes m zmoelnig -
José de Abreu -
oliver