[PD] pdstring feature requests...
IOhannes m zmoelnig
zmoelnig at iem.at
Thu Jul 26 10:06:11 CEST 2007
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
More information about the Pd-list
mailing list