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 _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
