Hi all,
Is there a reason to not make use of a full stop in a namespace? E.G. [julianslib.dac~]?
Cheers,
J.
On 5/10/19 11:49 AM, Julian Brooks wrote:
Hi all,
Is there a reason to not make use of a full stop in a namespace? E.G. [julianslib.dac~]?
a) there's no such a thing as a "namespace" in Pd. b) the closest we have to namespaces is just filesystem-layout, meaning you get a directory "julianslib/" and therein a file "dac~". this magically gives you an automatic namespace separator "/" (as in [julianslib/dac~]) c) directories are a nice way to keep contents of a folder managable. it's usually easier to navigate an extra/ folder that contains (among other things) a "julianslib" and a "zexy" directory (each containing
100 library objects), instead of 100 julianslib.* files and another 120
zexy.* files. you can of course put the "julianslib.*" files into the "julianslib/" directory, thus forcing the user to use both [declare -path julianslib] *and* a namespaced objectname. d) when using single-object-per-binary externals (e.g. julianslib.dac~.pd_linux), you need to take special care to construct a proper entry-point symbol ("setup_julianslib0x2edac_tilde")
apart from that, i don't think there are any obstacles. it certainly looks nice.
gsmdar IOhannes
Thanks IOhannes, awesome response. Agree that it looks good on the eye with that format.
Ta,
J.
On Fri, 10 May 2019 at 11:45, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 5/10/19 11:49 AM, Julian Brooks wrote:
Hi all,
Is there a reason to not make use of a full stop in a namespace? E.G. [julianslib.dac~]?
a) there's no such a thing as a "namespace" in Pd. b) the closest we have to namespaces is just filesystem-layout, meaning you get a directory "julianslib/" and therein a file "dac~". this magically gives you an automatic namespace separator "/" (as in [julianslib/dac~]) c) directories are a nice way to keep contents of a folder managable. it's usually easier to navigate an extra/ folder that contains (among other things) a "julianslib" and a "zexy" directory (each containing
100 library objects), instead of 100 julianslib.* files and another 120
zexy.* files. you can of course put the "julianslib.*" files into the "julianslib/" directory, thus forcing the user to use both [declare -path julianslib] *and* a namespaced objectname. d) when using single-object-per-binary externals (e.g. julianslib.dac~.pd_linux), you need to take special care to construct a proper entry-point symbol ("setup_julianslib0x2edac_tilde")
apart from that, i don't think there are any obstacles. it certainly looks nice.
gsmdar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Friday, May 10, 2019, 5:51:20 AM EDT, Julian Brooks jbeezez@gmail.com wrote:
Hi all, Is there a reason to not make use of a full stop in a namespace? E.G. [julianslib.dac~]?
Hi Julian, One problem is that it causes something like the double extra name collision avoidance problem.
- A cautious user will always leverage Pd's general collision avoidance by prefixing your library's directory
name in the object box.2. You, the developer, don't trust Pd's general collision avoidance to serve all possible
user needs, so you prefix a library name in the creator string.
3. Now the cautious user must type [ditters/ditters.karl] to create your object.
-Jonathan
Cheers, J.
On 5/11/19, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote: [...]
- A cautious user will always leverage Pd's general collision avoidance by
prefixing your library's directory name in the object box.
Does prefixing with libdir name avoid collision? Is it the case that Pd can have classes like [cyclone/svf~] and [bsaylor/svf~] loaded simultaneously?
Katja
-Jonathan
Cheers, J.
Em sáb, 11 de mai de 2019 às 17:26, katja katjavetter@gmail.com escreveu:
On 5/11/19, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote: [...]
- A cautious user will always leverage Pd's general collision avoidance
by
prefixing your library's directory name in the object box.
Does prefixing with libdir name avoid collision? Is it the case that Pd can have classes like [cyclone/svf~] and [bsaylor/svf~] loaded simultaneously?
sure!
I guess the issue comes when we have s single library file, where usually you can't use a namespace.
But we've dealt with this in cyclone. You can, for instance, call [cyclone/>~] and avoid clashing with zexy's - the way this is done is a bit hacky, of course... but simple, just add a new class creator
https://github.com/porres/pd-cyclone/blob/master/cyclone_objects/binaries/cy...
Em sáb, 11 de mai de 2019 às 18:17, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sáb, 11 de mai de 2019 às 17:26, katja katjavetter@gmail.com escreveu:
On 5/11/19, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote: [...]
- A cautious user will always leverage Pd's general collision
avoidance by
prefixing your library's directory name in the object box.
Does prefixing with libdir name avoid collision? Is it the case that Pd can have classes like [cyclone/svf~] and [bsaylor/svf~] loaded simultaneously?
sure!
I guess the issue comes when we have s single library file, where usually you can't use a namespace.
that's actually my biggest issue with such libraries. (luckily there are not too many of them.) it's cool that cyclone acknowledged the issue and added those additional creators.
name collisions are real: I've once had to debug a Pd patch by a friend of mine and it turned out the problem was that he used cyclone's [gate] object. unfortunately, [gate] is also part of iemlib and it works the other way round! he later added iemlib and now the "wrong" [gate] object was being used, messing up the whole patch in weird ways :-)
he could have written [cyclone/gate] to force the cyclone version, but it's not possible to force the iemlib version because it's not a single-object-binary. note that calling the namespace version will also register itself by the classname and therefore override existing classes (without namespace):
- load iemlib and create [gate] -> iem version
- create [cyclone/gate] -> cyclone version (obviously)
- create another [gate] -> cyclone version
this wouldn't be a problem if iemlib would be a single-object-per-binary library or offer namespaced creators like [iemlib/gate].
but I'm wondering if loading a lib could automatically "append" the library name to the individual objects. currently, class_new automatically registers 'class_loadsym' (a symbol containing the name under which the object has been invoked) as an additional creator, but only if the last part matches the classname (e.g. "cyclone/gate" <-> "gate"). now if 'class_loadsym' *doesn't* match the classname we can assume that it's the name of a multi-object-per-binary library, prepend it to the classname and register that as an alternative creator. this means that when 'gate_setup' is called as a consequence of 'iemlib_setup', it will register as "gate" and "iemlib/gate", assuming that iemlib was loaded with [declare -lib iemlib]. note that I'm talking about the new version of iemlib, it gets quite awkward for the old one which is split between iemlib1 and iemlib2...
one question is how [declare -lib some/folder/iemlib] should be handled: register as "some/folder/iemlib/gate" or "iemlib/gate" or both (besides "gate" of course)?
I might try this out and make a PR if it seems to work as I'm imagining it.
Christof
Gesendet: Samstag, 11. Mai 2019 um 23:19 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: katja katjavetter@gmail.com Cc: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] Full stop '.' in class namespace
I guess the issue comes when we have s single library file, where usually you can't use a namespace. But we've dealt with this in cyclone. You can, for instance, call [cyclone/>~] and avoid clashing with zexy's - the way this is done is a bit hacky, of course... but simple, just add a new class creator https://github.com/porres/pd-cyclone/blob/master/cyclone_objects/binaries/cy...
Em sáb, 11 de mai de 2019 às 18:17, Alexandre Torres Porres <porres@gmail.com[mailto:porres@gmail.com]> escreveu:
Em sáb, 11 de mai de 2019 às 17:26, katja <katjavetter@gmail.com[mailto:katjavetter@gmail.com]> escreveu:On 5/11/19, Jonathan Wilkes via Pd-list <pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]> wrote: [...]
- A cautious user will always leverage Pd's general collision avoidance by
prefixing your library's directory name in the object box.
Does prefixing with libdir name avoid collision? Is it the case that Pd can have classes like [cyclone/svf~] and [bsaylor/svf~] loaded simultaneously? sure!_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
On Saturday, May 11, 2019, 4:08:45 PM PDT, Christof Ressi christof.ressi@gmx.at wrote:
"cyclone/gate" <-> "gate"). now if 'class_loadsym' *doesn't* match the classname we can assume that it's the name of a multi-object-per-binary library, prepend it to the classname and register that as an alternative creator. If a [declare -lib foo] is nested somewhere in [myAbstraction], wouldn't this algorithm erroneously add a "myAbstraction/foo" creator? -Jonathan
On Saturday, May 11, 2019, 1:16:16 PM PDT, katja katjavetter@gmail.com wrote:
On 5/11/19, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:
[...]
- A cautious user will always leverage Pd's general collision avoidance by
prefixing your library's directory name in the object box.
Does prefixing with libdir name avoid collision?> Is it the case that Pd can have classes like [cyclone/svf~] and [bsaylor/svf~] loaded > simultaneously?
Does every supported PD platform allow you to a) dynamically load an object that defines a previously defined symbol and b) search for a symbol starting from the last loaded object and going up the dependency chain to the containing object?
If the answer to both is yes, then the answer to your question is yes. If not, then we're forever stuck with "pddp/pddplink" and friends. (Unless there's a way to use something like the gcc constructor attribute on all platforms.) -Jonathan
Katja
-Jonathan
Cheers, J.
Does every supported PD platform allow you to a) dynamically load an object that defines a previously defined symbol and b) search for a symbol starting from the last loaded object and going up the dependency chain to the containing object?
I'm not sure if I understand your question. are you talking about C symbols or Pd symbols here?
Gesendet: Sonntag, 12. Mai 2019 um 01:14 Uhr Von: "Jonathan Wilkes via Pd-list" pd-list@lists.iem.at An: katja katjavetter@gmail.com Cc: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] Full stop '.' in class namespace
On Saturday, May 11, 2019, 1:16:16 PM PDT, katja katjavetter@gmail.com wrote:
On 5/11/19, Jonathan Wilkes via Pd-list <pd-list@lists.iem.at[mailto:pd-list@lists.iem.at]> wrote:
[...]
- A cautious user will always leverage Pd's general collision avoidance by
prefixing your library's directory name in the object box.
Does prefixing with libdir name avoid collision? Is it the case that Pd can have classes like [cyclone/svf~] and [bsaylor/svf~] loaded simultaneously?
Does every supported PD platform allow you to a) dynamically load an object that defines a previously defined symbol and b) search for a symbol starting from the last loaded object and going up the dependency chain to the containing object? If the answer to both is yes, then the answer to your question is yes. If not, then we're forever stuck with "pddp/pddplink" and friends. (Unless there's a way to use something like the gcc constructor attribute on all platforms.) -Jonathan
Katja
-Jonathan
Cheers, J.
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
On Saturday, May 11, 2019, 5:25:25 PM PDT, Christof Ressi christof.ressi@gmx.at wrote:
Does every supported PD platform allow you to a) dynamically load an object that defines a previously defined symbol and b) search for a symbol starting from the last loaded object and going up the dependency chain to the containing object?
I'm not sure if I understand your question. are you talking about C symbols or Pd symbols here?
I'm talking about the system library on each OS responsible for dynamically loading and searching objects into the running process. Like dlopen/dlsym
-Jonathan
On Saturday, May 11, 2019, 5:47:17 PM PDT, Christof Ressi christof.ressi@gmx.at wrote:
ok, I don't see a problem here. the only symbol a Pd external exports (or should export) is the setup function - which is retrieved "manually" with GetProcAddress / dlsym. In theory all Pd externs could have the same setup function, at least on the platforms I know... Note that for example VST plugins all export the same entry point and it seems to work fine :-)
Not just in theory, but in practice at line 253 of s_loader.c So why aren't all (or at least nearly all) external developers simply using "setup" as the entry point?
-Jonathan
So why aren't all (or at least nearly all) external developers simply using "setup" as the entry point?
yes, I've asked that myself and I think they just could. Have a look at the Max part of pd~: the setup function is simply called 'main'.
Gesendet: Sonntag, 12. Mai 2019 um 03:28 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: [PD] Full stop '.' in class namespace
On Saturday, May 11, 2019, 5:47:17 PM PDT, Christof Ressi christof.ressi@gmx.at wrote:
ok, I don't see a problem here. the only symbol a Pd external exports (or should export) is the setup function - which is retrieved "manually" with GetProcAddress / dlsym. In theory all Pd externs could have the same setup function, at least on the platforms I know... Note that for example VST plugins all export the same entry point and it seems to work fine :-)
Not just in theory, but in practice at line 253 of s_loader.c So why aren't all (or at least nearly all) external developers simply using "setup" as the entry point? -Jonathan
On Sunday, May 12, 2019, 12:27:33 AM PDT, Christof Ressi christof.ressi@gmx.at wrote:
So why aren't all (or at least nearly all) external developers simply using "setup" as the entry point?
yes, I've asked that myself and I think they just could. Have a look at the Max part of pd~: the setup function is simply called 'main'.
Here's the probable reason-- current practice is aimed at the maximally complicated library which has a makefile that allows it to be built both as a single binary *or* with one class per binary. In that case you must have uniquely-named setup functions per class that can be called from a central library setup. Which I suppose would make more sense *if* the developer's choice of single- or multi-binary style was merely an implementation detail. But even with your patches it isn't-- with multi-binary style I can do [declare -lib foo/bar] whereas with the single-binary style that won't work. -Jonathan
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.
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
Em dom, 12 de mai de 2019 às 13:04, Christof Ressi christof.ressi@gmx.at escreveu:
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)
mindblown...
seems like using [declare] becomes unnecessary then...
of course I think library name prefix looks ugly, so I guess I like [declare] just to make things 'cleaner'.
but for my personal use, I have only one library i'm currently using, so I don't deal with any of this :) - no collisions, no 'collusion'...
On Sunday, May 12, 2019, 9:16:58 AM PDT, Christof Ressi christof.ressi@gmx.at wrote:
seems like using [declare] becomes unnecessary then...>> of course I think library name prefix looks ugly, > there you have it :-) [declare -lib] is here to stay.
You absolutely have to have [declare] and strongly encourage its usage. The [declare] object hoists a message up to the top of the patch file to ensure that the declared libraries and paths get loaded *before* the rest of the patch file is evaluated. If users don't get comfortable using it to load externals then they quickly run into problems.
It also has an explicit and readable left-to-right ordering. If the user depends on implicit loading per external object box, the loading order is hidden and difficult to debug. For example, imagine an external library which adds its own external loading mechanism, like pdlua. The user better load *that* before trying to load their own pdlua-based external, otherwise it won't create. Without using [declare] for that case, a user recently concocted a dynamic-patching solution to ensure ordering.
-Jonathan
On Sunday, May 12, 2019, 8:51:05 AM PDT, Christof Ressi christof.ressi@gmx.at wrote: 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.
I think what I'll do is to create a small external library in Purr Data to pentest the current myriad functions for external loading. Then I'll make some coverage tests. Once you get a solid patch set I'll plug it in and see if it breaks anything. -Jonathan
On Sunday, May 12, 2019, 8:45:34 AM PDT, Christof Ressi christof.ressi@gmx.at wrote: 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).
How would a user without a full mental model of s_loader.c and m_class.c know to use the workaround? However, that's a separate issue from your patch.
-Jonathan
Another question from the rabbit hole which I may have asked before-- what is up with the code after line 191 in s_loader.c: /* next try (objectname)/(classname).(sys_dllextent) ... */
For [foo/bar], this would try to load "foo/bar/bar.pd_linux". I don't understand why the loader would try to do that.
-Jonathan
isn't it that :
/* next try (objectname)/(classname).(sys_dllextent) ... */
will load "foo/bar.pd_linux".
This is correct right?
watch the "/" and "." :
(something) / (something) . (extension)
Mensaje telepatico asistido por maquinas.
On 5/11/2019 10:37 PM, Jonathan Wilkes via Pd-list wrote: Another question from the rabbit hole which I may have asked before-- what is up with the code after line 191 in s_loader.c: /* next try (objectname)/(classname).(sys_dllextent) ... */
For [foo/bar], this would try to load "foo/bar/bar.pd_linux". I don't understand why the loader would try to do that.
-Jonathan
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Saturday, May 11, 2019, 10:09:00 PM EDT, Lucas Cordiviola lucarda27@hotmail.com wrote:
isn't it that :
/* next try (objectname)/(classname).(sys_dllextent) ... */
will load "foo/bar.pd_linux". This is correct right?
No, "objectname" refers to full string that was typed into the object box. So "foo/bar" "classname" refers to the part after the rightmost slash-- "bar" This combines for "foo/bar/bar.pd_linux" (for example). You can test it with the "-verbose" flag. Try entering "foo/bar" in an object box and try to create it. You'll see "foo/bar/bar" with various extensions in the Pd window. -Jonathan
watch the "/" and "." :
(something) / (something) . (extension)
so it looks that this line is intended for a library that has the [object] in a folder.
say:
*/externals/foo/bar/bar.dll
That's, at least, what i guess this line is for.
Not sure which lib has this folder structure but may be there's at least one?
Mensaje telepatico asistido por maquinas.
On 5/11/2019 11:23 PM, Jonathan Wilkes wrote:
On Saturday, May 11, 2019, 10:09:00 PM EDT, Lucas Cordiviola lucarda27@hotmail.commailto:lucarda27@hotmail.com wrote:
isn't it that :
/* next try (objectname)/(classname).(sys_dllextent) ... */
will load "foo/bar.pd_linux".
This is correct right?
No, "objectname" refers to full string that was typed into the object box. So "foo/bar"
"classname" refers to the part after the rightmost slash-- "bar"
This combines for "foo/bar/bar.pd_linux" (for example).
You can test it with the "-verbose" flag. Try entering "foo/bar" in an object box and try to create it. You'll see "foo/bar/bar" with various extensions in the Pd window.
-Jonathan
watch the "/" and "." :
(something) / (something) . (extension)
Em dom, 12 de mai de 2019 às 02:32, Lucas Cordiviola lucarda27@hotmail.com escreveu:
so it looks that this line is intended for a library that has the [object] in a folder.
say:
*/externals/foo/bar/bar.dll
That's, at least, what i guess this line is for.
Not sure which lib has this folder structure but may be there's at least one?
I think this is intended to load a single library containing many objects like [cyclone]. So you call "cyclone" and it looks for the binary named cyclone inside the "cyclone" folder. So using [declare -lib cyclone] works and you don't need to do [declare -lib cyclone/cyclone] or [declare -path cyclone -lib cyclone]
same applies to zexy...
Mensaje telepatico asistido por maquinas.
On 5/11/2019 11:23 PM, Jonathan Wilkes wrote:
On Saturday, May 11, 2019, 10:09:00 PM EDT, Lucas Cordiviola
lucarda27@hotmail.com lucarda27@hotmail.com wrote:
isn't it that :
/* next try (objectname)/(classname).(sys_dllextent) ... */
will load "foo/bar.pd_linux". This is correct right?
No, "objectname" refers to full string that was typed into the object box. So "foo/bar"
"classname" refers to the part after the rightmost slash-- "bar"
This combines for "foo/bar/bar.pd_linux" (for example).
You can test it with the "-verbose" flag. Try entering "foo/bar" in an object box and try to create it. You'll see "foo/bar/bar" with various extensions in the Pd window.
-Jonathan
watch the "/" and "." :
(something) / (something) . (extension)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Christof Ressi -
IOhannes m zmölnig -
Jonathan Wilkes -
Julian Brooks -
katja -
Lucas Cordiviola