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/cy...
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