I'm also a bit hesitant, as with my patch you can already just do [declare -lib foo] - which might do nothing - and then just create [foo/bar], no matter how the library is compiled.
We can still apply Jonathan's idea to [foo/bar]: as a last resort (before looking for abstractions) it could try to load "foo". (we just need to return true from sys_load_lib and new_anything well be called again, hopefully now finding "foo/bar"). the interesting thing is that you won't need the -lib flag when creating objects with a "namespace": [zexy/atoi] will automatically load zexy (if needed).
Gesendet: Sonntag, 12. Mai 2019 um 17:56 Uhr
Von: "Alexandre Torres Porres" <por...@gmail.com>
An: "Christof Ressi" <christof.re...@gmx.at>
Cc: Pd-List <pd-list@lists.iem.at>
Betreff: Re: [PD] Full stop '.' in class namespace
Von: "Alexandre Torres Porres" <por...@gmail.com>
An: "Christof Ressi" <christof.re...@gmx.at>
Cc: Pd-List <pd-list@lists.iem.at>
Betreff: Re: [PD] Full stop '.' in class namespace
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
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.re...@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 thensearch 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.re...@gmx.at>
An: "Jonathan Wilkes" <jancs...@yahoo.com>, Pd-List <pd-list@lists.iem.at>
Betreff: Re: [PD] Full stop '.' in class namespace_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-listok, 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" <jancs...@yahoo.com>
An: "Christof Ressi" <christof.re...@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.re...@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/" isnamed 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 isjust "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 thensearch for a "bar_setup" routine. But that's getting pretty damned complicated. And without a spec forwhat 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
