#85 bug in iemlib's for++

[Anonymous]

There is a bug with the iemlib for++ object in PD-
extended:

I discovered a workaround to load for++ for now:

1. try to make an object [for++] -> PD will say that
there is no object like for++
2. try to make an object [forpp] -> PD will say that
there is no object like forpp
3. try again to make an object [for++] -> et viola ,
there is thefor++ I was looking for

cheers,

Nils

[Hans-Christoph Steiner]

Logged In: YES
user_id=27104

This is most likely because the class name is "for++", but
the source filename is "forpp.c". I think + is a valid
character for the filesystem, otherwise it could be renamed
using the hex loader.

[Nobody/Anonymous]

Logged In: NO

Not a fix, but another workaround: I've checked in a
for++.pd abstraction, which is compatible with the
IEMLIB-external. It's in the CVS at
http://pure-data.cvs.sourceforge.net/pure-data/abstractions/purepd/

ciao
-- fbar

[Hans-Christoph Steiner]

Logged In: YES
user_id=27104

I never use this object, and its not my lib, so please stop
assigning this bug to me. Its not something I am going to fix.

The problem is that the source file name doesn't match the
class name, therefore the resulting binary doesn't load the
right class.

[IOhannes m zmölnig]

Logged In: YES
user_id=564396

i have assigned this bugto you, since i thought that this
bug is related to pd-extended only (and you are the one who
takes care of this).

the bug does not appear when using iemlib as it is thought
to be used (as a library).
it only happens when it is compiled as single externals
(which is not supported upstream)

probably i'll find time to talk the author into fixing it
(or at least accept a fix)

[Jonathan Wilkes]

This works fine in modern versions of pd-extended Debian Wheezy. [import iemlib] and [for++] or [iemlib/for++] both instantiate the object. I can also load the lib in the prefs and [for++] works. If someone else can confirm then we can close the issue.