Hi,
As far as I know, some representation of the space character does exist in PD which can be contained in symbols. The "proof" is that if I bang an [openpanel] and I browse to a file whose path contains spaces, I can send the output to a symbol atom, print it, use [label $1( to send it to a canvas etc and it doesn't get truncated. I can store it in a [symbol] and use later without issue. So that kind of symbol definitely exists, no matter how it is internally represented.
But if I send such a symbol (containing blank spaces, e.g. the output of an openpanel) to the following chain:
... | [list prepend set] | [list trim] | [ (
then the symbol IS truncated at the first space.
That is, the [set( message to a messagebox doesn't seem to handle correctly symbols containing a blank space.
Before I report it to the bugtracker, am I missing something?
P.S. the same results are obtained with
[set $1( | [ (
but since it involves two message boxes i thought it could be more confusing.
moin Matteo, moin list,
afaik, the issue you're observing is due to the message box, which uses t_binbuf internally to (re-)parse messages into pd atoms. you are correct that symbols can easily contain spaces (and pretty much anything else except for ASCII NUL): the problem is getting the funny bytes in & back out again... anyone else should feel free to correct me on this if I've got it wrong, of course...
marmosets, Bryan
On 2009-12-08 20:43:37, Matteo Sisti Sette matteosistisette@gmail.com appears to have written:
Hi,
As far as I know, some representation of the space character does exist in PD which can be contained in symbols. The "proof" is that if I bang an [openpanel] and I browse to a file whose path contains spaces, I can send the output to a symbol atom, print it, use [label $1( to send it to a canvas etc and it doesn't get truncated. I can store it in a [symbol] and use later without issue. So that kind of symbol definitely exists, no matter how it is internally represented.
But if I send such a symbol (containing blank spaces, e.g. the output of an openpanel) to the following chain:
... | [list prepend set] | [list trim] | [ (
then the symbol IS truncated at the first space.
That is, the [set( message to a messagebox doesn't seem to handle correctly symbols containing a blank space.
Before I report it to the bugtracker, am I missing something?
P.S. the same results are obtained with
[set $1( | [ (
but since it involves two message boxes i thought it could be more confusing.
Hallo,
(I forgot to send this mail last week, now it may be outdated already...)
Bryan Jurish hat gesagt: // Bryan Jurish wrote:
afaik, the issue you're observing is due to the message box, which uses t_binbuf internally to (re-)parse messages into pd atoms.
I think, it only happens on saving or reloading of a patch, though. For example in the attachement a numeric symbol is generated with [makefilename %d] and written to a message box. While this symbol looks like a number, it is in fact a symbol (as intended) and cannot be used for calculations (but it can be used as text in Gem). However after saving and reloading the patch, the message box converts it to a float, so now you can use it with math but not as a symbol anymore.
you are correct that symbols can easily contain spaces (and pretty much anything else except for ASCII NUL): the problem is getting the funny bytes in & back out again... anyone else should feel free to correct me on this if I've got it wrong, of course...
I think, you're right. It extends to many places in the Pd editor. While for example the symbol box can display symbols with backslached escaped spaces, you still cannot enter them into a symbol atom "manually" i.e. by typing.
Ciao
Frank
Frank Barknecht wrote:
Hallo,
(I forgot to send this mail last week, now it may be outdated already...)
Bryan Jurish hat gesagt: // Bryan Jurish wrote:
afaik, the issue you're observing is due to the message box, which uses t_binbuf internally to (re-)parse messages into pd atoms.
I think, it only happens on saving or reloading of a patch, though. For example
'well, it happens whenever there is a need to reparse the contents of the box. obviously, this is at load time. it also happens when you just create a new object (including msgbox). it does _not_ happen, when you just duplicate an already existing object, because Pd is clever and has already parsed the contents of the original objectbox and there since it has not changed (because you cannot change the arguments of an object with duplication) and it does happen, when you modify the object's contents (because Pd has to figure out whether you added/deleted arguments).
anyhow, i forgot to send this email earlier, so matteo has already said that...
fgmadr IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
it does _not_ happen, when you just duplicate an already existing object, because Pd is clever and has already parsed the contents of the original objectbox and there since it has not changed (because you cannot change the arguments of an object with duplication) and it does happen, when you modify the object's contents (because Pd has to figure out whether you added/deleted arguments).
anyhow, i forgot to send this email earlier, so matteo has already said that...
Thank you for sending it anyhow: I didn't know about the behaviour on duplication, which is interesting.
Ciao
Frank
Hallo, Matteo Sisti Sette hat gesagt: // Matteo Sisti Sette wrote:
But if I send such a symbol (containing blank spaces, e.g. the output of
an openpanel) to the following chain:... | [list prepend set] | [list trim] | [ (
then the symbol IS truncated at the first space.
This only happens after saving and reloading for me. I attached a patch that constructs symbols with one and two spaces. As long as you don't save and reload, the symbols stay intact even in message boxes. After saving and reloading, they don't - they simply become message boxes containing ordinary list rsp. meta messages with their elements separated by spaces like everywhere else in Pd. Pd has no way to let these symbols survive saving, so if you need them, you have to construct new ones each time. I guess, one could do a feature request regarding this, but in the end the problem lies deeper and relates to putting a proper string quoting and escaping mechanism in place.
Ciao
Frank
Hello
Very interesting observation. i guess it has to do with the openpanel and savepanel objects. It's probably a special kind of symbol that represents the possible spaces (which in reality are no spaces anyway..) for compatibility with the OS. Obviously you can't create such a message within pd. Unfortunately ..
alabala
moin moin,
On 2009-12-09 10:37:10, ypatios ypatios@gmail.com appears to have written:
Hello
Very interesting observation. i guess it has to do with the openpanel and savepanel objects. It's probably a special kind of symbol that represents the possible spaces (which in reality are no spaces anyway..) for compatibility with the OS.
Not really -- there's nothing "special" about the *symbols* at all. Frank is right: the difficulty is in (re-)parsing them, which needs to happen when loading a patch, which means "funny" characters like spaces would need to be escaped when saving a patch, but pd lacks an escaping mechanism (e.g. in binbuf_text(), binbuf_add(), etc.).
Obviously you can't create such a message within pd. Unfortunately ..
It's certainly not comfortable to create such symbols, but it is possible: you can use [list2symbol] from zexy to create symbols with spaces quite easily. Even in vanilla pd, you can do:
[32( | [makefilename foo%cbar] | [symbol] | [print]
... which will create & print a single symbol "foo bar" (pipe it to [list length] if you don't believe me ;-)
marmosets, Bryan
Shit I'm so confused... Now I'm trying it again and it seem it does work....... I need to find what I was doing that I am not...
Ok I have it.
This does work as expected:
[32( | [makefilename foo%cbar] | [set $1( | [ (
Then you can bang the last message box and feed its output to a [list length] to verify it is one symbol (well, not a symbol, one whatever).
But then, if I manually edit the message box and modify it (for example add some characters), then the space is reconverted to a "true space" and the symbol is broken.
However, I've realised my particular case has a workaround, since I know that the box must contain one symbol, so I can glue it again with the "32->%c" trick.
I think a general escaping mechanism would really be needed in PD!!! (see for example the "self reproducing slashes" bug...)
Matteo Sisti Sette escribió:
Shit I'm so confused... Now I'm trying it again and it seem it does work....... I need to find what I was doing that I am not...
Matteo Sisti Sette wrote:
Ok I have it.
This does work as expected:
[32( | [makefilename foo%cbar] | [set $1( | [ (
Then you can bang the last message box and feed its output to a [list length] to verify it is one symbol (well, not a symbol, one whatever).
But then, if I manually edit the message box and modify it (for example add some characters), then the space is reconverted to a "true space" and the symbol is broken.
that's because the contents of the msgbox get's reparsed when you edit it.
However, I've realised my particular case has a workaround, since I know that the box must contain one symbol, so I can glue it again with the "32->%c" trick.
if you want a real symbol, you could as well use
[set symbol $1(
or just believe the output of [makefilename] to be what you expect it to be.
(and there's zexy's [list2symbol] which will concatenate all the arguments of a list into a single symbol, the default delimiter being space.
I think a general escaping mechanism would really be needed in PD!!!
yes.
mfgasdf IOhannes
IOhannes m zmoelnig escribió:
(and there's zexy's [list2symbol] which will concatenate all the arguments of a list into a single symbol, the default delimiter being space.
Yeah that's exactly what I meant (with an abstraction instead of zexy) though I probably didn't explain it well.
Matteo Sisti Sette wrote:
IOhannes m zmoelnig escribió:
(and there's zexy's [list2symbol] which will concatenate all the arguments of a list into a single symbol, the default delimiter being space.
Yeah that's exactly what I meant (with an abstraction instead of zexy) though I probably didn't explain it well.
i see. i haven't read the entire thread carefully. so the communication problem was most likely on my side.
anyhow (still not having read the thread), attached is an abstraction that might do what you want (whatever that is :-))
fgmasdr IOhannes
#N canvas 148 518 450 397 10; #X obj 227 26 inlet; #X obj 210 366 outlet; #X obj 248 173 list split 1; #X obj 248 130 until; #X obj 248 151 list append; #X obj 248 107 t b l; #X obj 378 173 bang; #X obj 248 288 makefilename; #X msg 280 262 set $1%c$2; #X obj 248 237 t b l; #X msg 248 259 32; #X obj 347 200 list split 1; #X obj 248 83 list split 1; #X obj 226 53 t b l l; #X obj 248 310 t s s; #X obj 214 340 symbol; #X obj 248 216 list prepend; #X connect 0 0 13 0; #X connect 2 0 16 0; #X connect 2 1 4 1; #X connect 2 2 6 0; #X connect 3 0 4 0; #X connect 4 0 2 0; #X connect 5 0 3 0; #X connect 5 1 4 1; #X connect 6 0 3 1; #X connect 7 0 14 0; #X connect 8 0 7 0; #X connect 9 0 10 0; #X connect 9 1 8 0; #X connect 10 0 7 0; #X connect 11 0 16 1; #X connect 12 1 5 0; #X connect 13 0 15 0; #X connect 13 1 12 0; #X connect 13 2 11 0; #X connect 14 0 15 1; #X connect 14 1 16 1; #X connect 15 0 1 0; #X connect 16 0 9 0;
-
Bryan Jurish -
Frank Barknecht -
IOhannes m zmoelnig -
Matteo Sisti Sette -
ypatios