[PD-dev] [ pure-data-Bugs-1965894 ] libdir loader can't handle classname same as library name

SourceForge.net noreply at sourceforge.net
Wed Jul 23 16:15:30 CEST 2008


Bugs item #1965894, was opened at 2008-05-17 05:55
Message generated for change (Comment added) made by eighthave
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1965894&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pd-extended
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: eerne (eerne)
>Assigned to: Hans-Christoph Steiner (eighthave)
>Summary: libdir loader can't handle classname same as library name

Initial Comment:
with Pd-0.40.3-extended-20080516-macosx104-i386.dmg the sssad-help.pd file does not work out of the box.

libdir_loader: added sssad to the canvas-local path
 sssad key
... couldn't create
libdir_loader: added sssad to the canvas-local path
 sssad key
... couldn't create
libdir_loader: added sssad to the canvas-local path
 sssad key
... couldn't create
libdir_loader: added sssad to the canvas-local path
 sssad key
... couldn't create
 sssad-example
... couldn't create

----------------------------------------------------------------------

>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-07-23 10:15

Message:
Logged In: YES 
user_id=27104
Originator: NO

The problem is somewhere in the relationship of the libdir loader and Pd's
logic for checking if it has already loaded a binary library.  If you load
a libdir called "blah", you won't be able to load [blah/blah] or [blah].


----------------------------------------------------------------------

Comment By: hardoff (hardoff)
Date: 2008-06-30 18:43

Message:
Logged In: YES 
user_id=1816568
Originator: NO

creating a [sssad] object in pd-extended causes the following error in the
console:


libdir_loader: added 'sssad' to the canvas-local objectclass path
libdir_loader: added 'sssad' to the canvas-local objectclass path
libdir_loader: added 'sssad' to the canvas-local objectclass path

...about 1000 times, and then finally says:

error: maximum object loading depth 1000 reached
 sssad
... couldn't create



several people have suggested that there is a glitch in the libdir loader
that won't allow for an abstraction to have the same name as its enclosing
folder.



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-05-28 19:03

Message:
Logged In: NO 

I named the private subdirectory "_sssad" just randomly, loosly inspired
by Pyton's convention of using underscores for private stuff. I wasn't
thinking of some libdir conflict at that time at all. As the sssad
"library" consists of only one object I didn't consider namespacing for it
at all.

I haven't used libdirs so far, but I think, objects which have the same
name as the libdir should be possible as well.

--Frank (not logged in, but believe me it's me)

----------------------------------------------------------------------

Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-28 11:58

Message:
Logged In: YES 
user_id=27104
Originator: NO

so the problem is that the libdir for sssad is currently called 'sssad'. 
Since the main object is also called 'sssad', there is a nameconflict. 
Frank must have found this himself, since he named the included folder
'_sssad'.  I am not really sure how to solve this, except include sssad in
a different library.

Any suggestions?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1965894&group_id=55736




More information about the Pd-dev mailing list