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 moocow/string2any 32 -1 ... couldn't create [arduino]: version_0.4
This is with pd-extended 0.41.4 20090209. This works fine in Pd- extended 0.40.3.
.hc
'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink-
collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
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?
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
morning all,
On 2009-02-12 10:42:10, Frank Barknecht fbar@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
On Feb 12, 2009, at 4:55 AM, Bryan Jurish wrote:
morning all,
On 2009-02-12 10:42:10, Frank Barknecht fbar@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...
Windows doesn't have symlinks, so that's why this doesn't work on
Windows. I think MinGW's "ln -s" is supposed to make a copy, cygwin's
"ln -s" will make a Windows "Shortcut" but they only act like symlinks
when in Cygwin. But it sounds likely that there is something amiss
with this symlinking stuff.
.hc
Programs should be written for people to read, and only incidentally
for machines to execute.
- from Structure and Interpretation of Computer Programs
Hans-Christoph Steiner wrote:
Windows doesn't have symlinks, so that's why this doesn't work on
Windows. I think MinGW's "ln -s" is supposed to make a copy, cygwin's
"ln -s" will make a Windows "Shortcut" but they only act like symlinks
when in Cygwin. But it sounds likely that there is something amiss
with this symlinking stuff.
and you forgot: svn creates a copy from symlinks as well (that is: if a symlink was checked into the repository, and you check it out on w32, you will get 2 copies of the same file, changing (and committing) one, will have an effect on both; all in all: symlinks ought to be transparent)
fgmad IOhannes
-
Bryan Jurish -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig