[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...
marmosets,
Bryan
--
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