Menu

#290 libdir loader can't handle classname same as library name

open
5
2008-07-23
2008-05-17
eerne
No

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

Discussion

  • Hans-Christoph Steiner

    • assigned_to: eighthave --> nobody
     
  • Hans-Christoph Steiner

    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?

     
  • Nobody/Anonymous

    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)

     
  • hardoff

    hardoff - 2008-06-30

    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.

     
  • Hans-Christoph Steiner

    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].

     
  • Hans-Christoph Steiner

    • assigned_to: nobody --> eighthave
    • summary: sssad-help.pd error --> libdir loader can't handle classname same as library name
     

Anonymous
Anonymous

Add attachments
Cancel