[PD] pdstring feature requests...

[Bryan Jurish]

moin,

On 2007-07-25 15:29:28, IOhannes m zmoelnig <zmoelnig at 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

-- 
Bryan Jurish                           "There is *always* one more bug."
jurish at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic Entomology