Just wanna say that this feature is great and helps a lot with cyclone, as I wanted to provide a single binary. Actually, you can already compile it as a single library. But then we have this issue of not being able to call an object with a libname prefix.

Of course one thing I'd have to do is add a class creator for every object in cyclone, but that's something that makes me cry if I think of it...

So if this is worked out, I'd be free from this torture and could more easily provide a single binary for cyclone.

Cyclone still has a couple of abstractions that are not part of its binary... but.... I'm dealing with that by making the cyclone binary load cyclone's path in Pd's path with the "add to path" message => https://github.com/porres/pd-cyclone/blob/master/cyclone_objects/binaries/cyclone_lib.c#L674

This is 

Then I can do [declare -lib foo/bar] to load that library.

But that's not the idea, the idea is to use [declare -lib foo] and be able to load the object as [foo/bar]...

[declare -lib foo/bar]  would look for a bar binary inside a 'foo' folder inside Pd's paths.

I guess we're unnecessarily complicating things that are not pertinent and in line with the actual concept of using [declare] and all.

cheers

Em dom, 12 de mai de 2019 às 12:53, Christof Ressi <christof.ressi@gmx.at> escreveu:
anyway, I agree that ideally the structure of a library should be totally transparent to the user.
 
> Theoretically you could have a loader branch that would look for the "foo" binary in that case, load it, and then 
search for a "bar_setup" routine.
 
that's not a bad idea. doesn't seem too complicated to me. I might give it a shot.
 
Gesendet: Sonntag, 12. Mai 2019 um 17:45 Uhr
Von: "Christof Ressi" <christof.ressi@gmx.at>
An: "Jonathan Wilkes" <jancsika@yahoo.com>, Pd-List <pd-list@lists.iem.at>
Betreff: Re: [PD] Full stop '.' in class namespace
ok, I see. you usually don't load individual classes with [declare -lib] but only (multi-objects-per-binary) libraries.
 
the workaround usually is to do [declare -path zexy -lib zexy]. -path is for abstractions and single-object-binaries and -lib is for the multi-object-per-binary library (if it exists).
 
the problem was that with single-object-binaries you can do [zexy/atoi] but with multi-object-binaries you can't (unless they added such creators). this is what my patch mainly tries to solve.
 
Gesendet: Sonntag, 12. Mai 2019 um 17:33 Uhr
Von: "Jonathan Wilkes" <jancsika@yahoo.com>
An: "Christof Ressi" <christof.ressi@gmx.at>
Cc: Pd-List <pd-list@lists.iem.at>
Betreff: Re: Aw: Re: Re: Re: Re: [PD] Full stop '.' in class namespace
 
> On Sunday, May 12, 2019, 10:58:52 AM EDT, Christof Ressi <christof.ressi@gmx.at> wrote:
 
>> that allows it to be built both as a single binary *or* with one class per binary.
 
> ah, of course that makes sense.
 
>> with multi-binary style I can do [declare -lib foo/bar] whereas with the single-binary style that won't work.
 
> I'm not sure I understand. Can give an example?
 
That's the libdir prefix logic. Say I have a "foo" library where one of many binaries inside "extra/foo/" is 
named bar.pd_linux. Then I can do [declare -lib foo/bar] to load that library.
 
On the other hand, if "foo" was compiled as a single binary with many classes inside it, then there is 
just "extra/foo/foo.pd_linux." In that case [declare -lib foo/bar] won't work.
 
Theoretically you could have a loader branch that would look for the "foo" binary in that case, load it, and then 
search for a "bar_setup" routine. But that's getting pretty damned complicated. And without a spec for 
what the loader is supposed to be doing in the first place I'd be hesitant to add that.
 
 
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list