[PD] string2any in arduino.pd is now broken

Bryan Jurish moocow at ling.uni-potsdam.de
Thu Feb 12 10:55:22 CET 2009

morning all,

On 2009-02-12 10:42:10, Frank Barknecht <fbar at footils.org> appears to
have written:
> Hallo,
> Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
>> So I have been happily using the string2any object in my arduino  
>> object and it works well.   But it seems that something has changed,  
>> and it now causes a freak out on load:
>> string2any_setup(): WARNING: names are in flux!
>> string2any_setup(): Prefer [bytes2any] over [string2any].
>> bytes2any: pdstring version 0.09 by Bryan Jurish
>> moocow/string2any: already loaded
>> ... snip (repeat 1000 times) ...
>> moocow/string2any: already loaded
>> error: maximum object loading depth 1000 reached
> Isn't this the issue with hexloader reported some time ago? Does it
> fail on vanilla or a pd-extended with no libs loaded as well?

Hmm... I'm not familiar with the hexloader bug you mention.  In trying
to maintain maximal backwards-compatibility, I set up [pdstring] in
single-object-external mode (which pd-extended uses) to install
"any2string.pd_whatever" as a symlink to "any2bytes.pd_whatever".
Additionally, any2bytes.c contains an "any2string_setup()" function as
well as a runtime check to prevent multiple setup() calls.

Is the problem due to the use of a symlink (e.g. does it persist if
moocow/string2any.pd_linux is a copy of moocow/bytes2any.pd_linux?)  Or
is every solution ultimately relying on class_addcreator() doomed to
failure?  I can make [string2any] just an abstraction wrapping
[bytes2any] as well; I just anticipated interference from old
installations with that trick...


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

More information about the Pd-list mailing list