[PD] Full stop '.' in class namespace

[Alexandre Torres Porres]

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 at 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 at gmx.at>
> *An:* "Jonathan Wilkes" <jancsika at yahoo.com>, Pd-List <
> pd-list at 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 at yahoo.com>
> *An:* "Christof Ressi" <christof.ressi at gmx.at>
> *Cc:* Pd-List <pd-list at 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 at 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 at lists.iem.at
> mailing list UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20190512/d1a2edce/attachment-0001.html>