during my recent work with pdstrings, 2 issues came upon me.
[any2string]: this object usually terminates the output string with a 0 (after all it is a somewhat arkward representation of a c-string). it would be cool if one could change this, and make it configurable.
currently i have to [list split] the string list before the last element (using [list length]) and then [list append] CRLF. this seems a bit of an overhead to me.
[string2any]: analogous to the above described behaviour, [string2any] will stop processing whenever it encounters a "0" string element. for instance "97 32 98 0 99" will result in a 2-element list "a b". this prevents the user from simply concatenating to strings generated with [any2string] (since the result of the latter will include a terminating 0 which will make the former stop when processing the concatenated list).
what i would like to have is: [any2string]: make the string end configurable; e.g. [any2string 0] will create \0 terminated strings; [any2string 13 10] will terminate the string with CRLF; for compatibility reasons i would let [anystring] (without args) output the 0-terminated list (even though if i had the chance i would prefer to it to not use any terminating elemets at all per default); one could imagine a 2nd inlet to set the terminator (sending an empty list would mean "no termination")
[string2any]: what i would really like, is having [string2any] output multiple messages if it encounters a "delimiter" (instead of a "terminator"), e.g. "0"; this would make "97 32 98 0 99" output "a b" and "c".
[string2any]: analogous to the [any2string] request i would love to be able to change the delimiter (again: via arguments and/or 2nd inlet); for instance i am dealing with strings delimited by CRLF (get them from [tcpserver]), and parsing that into several messages (line-by-line) is a task i would like to be done within [string2any].
109 097 114 109 111 115 101 116 115
mfga.sdr IOhannes
moin,
On 2007-07-25 15:29:28, IOhannes m zmoelnig zmoelnig@iem.at appears to have written:
during my recent work with pdstrings, 2 issues came upon me.
[any2string]: this object usually terminates the output string with a 0 (after all it is a somewhat arkward representation of a c-string). it would be cool if one could change this, and make it configurable.
currently i have to [list split] the string list before the last element (using [list length]) and then [list append] CRLF. this seems a bit of an overhead to me.
i agree it would be nice. nonetheless, i'm hesitant to try and turn pdstring into an all-singing, all-dancing string handling mechanism for pd; it is (and always was) just an ugly hack. its only justification (to me) is that it *is* possible to use [list whatever] to manipulate the output atom-lists (at the time of pdstring's writing, i was using [drip], [glue], [length], and [niagara] ;-)
[string2any]: analogous to the above described behaviour, [string2any] will stop processing whenever it encounters a "0" string element. for instance "97 32 98 0 99" will result in a 2-element list "a b". this prevents the user from simply concatenating to strings generated with [any2string] (since the result of the latter will include a terminating 0 which will make the former stop when processing the concatenated list).
concatenation ought to work more comfortably, it's true. the lack of nul-handling in [string2any] is easily fixed in principle (strlen() can be replaced by argc), but the guts are just a call to binbuf_text(), which performs the same truncation you describe (probably by calling SETSYMBOL()), and I don't really feel up to writing a whole pd parser from scratch at the moment.
what i would like to have is: [any2string]: make the string end configurable; e.g. [any2string 0] will create \0 terminated strings; [any2string 13 10] will terminate the string with CRLF; for compatibility reasons i would let [anystring] (without args) output the 0-terminated list (even though if i had the chance i would prefer to it to not use any terminating elemets at all per default); one could imagine a 2nd inlet to set the terminator (sending an empty list would mean "no termination")
makes sense. I put together a first stab a static-buffered [any2string] today, which would mean another optional argument, say:
[any2string BUFSIZE TERMINATORS...]
... but the static buffers are still buggy, and it's getting late...
[string2any]: what i would really like, is having [string2any] output multiple messages if it encounters a "delimiter" (instead of a "terminator"), e.g. "0"; this would make "97 32 98 0 99" output "a b" and "c". [string2any]: analogous to the [any2string] request i would love to be able to change the delimiter (again: via arguments and/or 2nd inlet);
not likely to happen without re-inventing binbuf_text(), which is bit of a monster.
... all of this might be easier to implement if we could ensure that nothing "creative" was going to be passed through any2string/string2any (dollars, escapes, etc.), but that's not really "any" anymore...
109 097 114 109 111 115 101 116 115
... with prehensile tails, Bryan
moin moin, again
Bryan Jurish wrote:
moin,
[any2string]: this object usually terminates the output string with a 0 (after all it is a somewhat arkward representation of a c-string). it would be cool if one could change this, and make it configurable.
currently i have to [list split] the string list before the last element (using [list length]) and then [list append] CRLF. this seems a bit of an overhead to me.
i agree it would be nice. nonetheless, i'm hesitant to try and turn pdstring into an all-singing, all-dancing string handling mechanism for pd; it is (and always was) just an ugly hack. its only justification (to me) is that it *is* possible to use [list whatever] to manipulate the output atom-lists (at the time of pdstring's writing, i was using [drip], [glue], [length], and [niagara] ;-)
yes obviously it is possible to do it (nowadays even with standard pd objects). i also agree, that it is a bad idea to turn one of these objects into an eierlegende wollmilchsau, and i admit that my feature request has been something along these lines.
nevertheless, i was talking about [any2string] deliberately adding a terminating 0 which has to be removed manually in certain applications; and removing the trailing element is far more complicated than adding a new one (even if [list split] would support the negative indices known from [niagara] or [list-splat])
so i would be quite content if [any2string] would add nothing by itself and leave the user to manually append a terminating sequence.
(oh, reading on i see that you seem to be accepting this anyhow...)
concatenation ought to work more comfortably, it's true. the lack of nul-handling in [string2any] is easily fixed in principle (strlen() can be replaced by argc), but the guts are just a call to binbuf_text(), which performs the same truncation you describe (probably by calling SETSYMBOL()), and I don't really feel up to writing a whole pd parser from scratch at the moment.
well, there is no need to do so.
however, i will just write an object that searches lists for given sublists and splits them accordingly. i see now that it was a bad idea to request this feature into [string2any].
i only need a name....
makes sense. I put together a first stab a static-buffered [any2string] today, which would mean another optional argument, say:
[any2string BUFSIZE TERMINATORS...]
so BUSIZE would be the initialy buffersize (which would be adjusted as longer messages come along)? else i quite don't get it.
... but the static buffers are still buggy, and it's getting late...
i guess this means "static within a function context" and not "static as a global variable".
however, this might be a dangerous thing to do....
... all of this might be easier to implement if we could ensure that nothing "creative" was going to be passed through any2string/string2any (dollars, escapes, etc.), but that's not really "any" anymore...
that would be bad, as i am pretty sure that i have plenty of "creative" input.
109 097 114 109 111 115 101 116 115
... with prehensile tails,
i thought it was goeldi's?
mfga.sdr IOhannes
moin,
On 2007-07-26 10:06:11, IOhannes m zmoelnig zmoelnig@iem.at appears to have written:
Bryan Jurish wrote:
at some point, IOhannes m zmoelnig zmoelnig@iem.at appears to have written:
so i would be quite content if [any2string] would add nothing by itself and leave the user to manually append a terminating sequence.
now implemented and checked into cvs as pdstring-v0.05. the magic incantation is:
[any2string BUFSIZE -1],
where "BUFSIZE" is the initial (object-local) buffer size, it can be 0 or less to use the default (which I've increased from 32 to 256).
and I don't really feel up to writing a whole pd parser from scratch at the moment.
well, there is no need to do so.
sorry, it was way too late last night -- there is now rudimentary message-separation in [string2any]: it will separate messages on a single end-of-string (EOS) character, specified just like for [any2string]:
[string2any BUFSIZE 0]
will separate messages on NUL-bytes. Inlets and outlets have been added to protect the innocent, and the defaults are backwards-compatibile.
however, i will just write an object that searches lists for given sublists and splits them accordingly.
that's probably best -- I don't really want to add multiple-character EOS parsing to the [pdstring] stuff, but the single-character version struck me as a pretty sensible way to deal with NUL bytes at least.
i only need a name....
how about [list_tokenize] ?
so BUSIZE would be the initialy buffersize (which would be adjusted as longer messages come along)?
that's how it is now -- the static version (not built by default, in pdstring/src/any2string_static.c) allocates a single object-local buffer of user-specified size on object instantiation and never dynamically allocates memory in its message-handling routines (it will spit out an error if the buffer overflows).
109 097 114 109 111 115 101 116 115
... with prehensile tails,
i thought it was goeldi's?
... also. and big hair.
Callithrix jacchus, Bryan
-
Bryan Jurish -
IOhannes m zmoelnig