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 _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
