[L2Ork-dev] json?

[Jonathan Wilkes]

On Sun, Jan 24, 2021 at 11:30 AM Marc Lavallée <marc at hacklava.net> wrote:
>
> Hi Jonathan,
>
> Thanks for the precisions.
>
> I feel like a Pd n00b again; so basically nothing really changed, and
> there's good reasons.

It's a bit complicated because Pd-extended autoloaded a ton of
libraries. And there are *still* a lot of users who not only rely on
old patches built with Pd-extended but even *still* download and
install Pd-extended to make new patches!

For that reason, we autoload the old Pd-extended patches at startup so
that all those patches will continue to work by default. There's a
special "libdir" loader we use that will just add the path for a given
library rather than running all the setup routines. That reduces
startup time and means we don't need to set a path for every
Pd-extended lib.

The cost is that this encourages users to rely on unprefixed external
names. An object named "foo~" may appear in many different libraries,
so the user is depending on Pd-extended load order to load the correct
one. Worse, they probably don't even know that there are multiple,
incompatible versions. They may even assume it is a core object and be
surprised when their patch that worked in Pd-extended doesn't work in
Vanilla (and have no idea which library to download to install it).
You can see the Vanilla mailing list has been littered with questions
over the years about which library holds which names, or confusion
about core objects, etc. This is the reason for that.

In short, we're trying to support old patches from an old, flawed
system. And we inescapably inherit the same namespace clash problems
for those autoloaded Pd-extended libraries by doing that.

(Also notice, that we don't autoload *every* library we ship. Only the
ones that autoloaded with Pd-extended.)

So if you're not trying to maintain compatibility with an old, flawed
system, I would recommend avoiding that autoloading pattern. You'll
generate the same problems I mentioned above with no benefits.

>
> So I'll create a carefully crafted $HOME/.pdsettings

Here's a tip-- when you right-click on an object and choose "Help",
the title bar for the help patch should show the full path to the
external.

If you run into any problems, first check if you can instantiate the
object. Then right click "Help" and check the path to make sure you're
loading the correct one. The most recurring problem I've seen is that
someone is loading a different version of an external than they think
they are loading.

For sanity, you can navigate to the directory that holds an external
binary and start with "-noprefs" and "-nostdpath" flags. Now if you
try to instantiate the binary it will *only* load from that directory.

-Jonathan

>
> Marc
>
> Le 21-01-24 à 11 h 22, Jonathan Wilkes a écrit :
> >> There's 96 items in /usr/lib/pd/extra (most of them are folders, some
> > are symlinks), so to get access to all installed libraries I would have
> > to add as many entries into Pd paths dialog?
> >
> > 1. If you want to be able to load those libraries using [declare],
> > just make sure you have /usr/lib/pd/extra in the startup path.
> >
> > 2. If you want to be able to load those libraries as
> > [libname/objname]-- which I would recommend as good practice-- do the
> > same as step 1.
> >
> > 3. If you really want to load every single library in
> > /usr/lib/pd/extra automatically at startup, then you absolutely must
> > add every one of those paths and libs in the way you've stated. That's
> > a really bad practice-- it increases startup time for no gain, and
> > probably creates all kinds of namespace clashes depending on the
> > startup order you specified. (You're also betting that none of those
> > externals have a crasher or memory error in the setup routine-- as
> > someone who has tried to automate testing for Pd externals over the
> > years I certainly wouldn't take that bet.)
> >
> > -Jonathan
> > _______________________________________________
> > L2Ork-dev mailing list
> > L2Ork-dev at disis.music.vt.edu
> > https://disis.music.vt.edu/listinfo/l2ork-dev
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev