Yeah - having never used a 'loader' at all, they appear like magic to me. Anyway, careful thought is needed here...
I forgot yet one more problem I want to resolve: readsf~ and writesf~ use the path in a non-thread-safe way.
The problem I mentioned that you couldn't identify from my description earlier was that, if anyone ever loads an extern named "foo" (for instance) then all the search path business will be short-circuited when anyone says "foo" in an object box, as if "foo" were a built-in object. This can happen even in the middle of loading a patch so that some "foo" objects get one thing and others another. I don't know ifthis extends to other "loaders" or not.
cheers M
On Thu, Sep 24, 2015 at 05:29:49PM +0200, IOhannes m zmölnig wrote:
On 09/24/2015 05:16 PM, Miller Puckette wrote:
I don't think there's a ghost of a chance of making this all be sane and staying back compatible - the only thing I can think to do is make a whole new parallel structure and have a "compatibility" flag that throws you back to the old regime.
nah, please don't!
i'm pretty sure that for most cases one can achieve backward compatibility by clever re-arrangement of cmdline "-path"s.
up until now, playing with paths (and loaders) was near-magic - if not plain black magic. i don't think that many things will break by changing it (in a way that people won't say: "ah, i finally understand how this is supposed to work")
supporting *both* behaviours will only lead to unmaintainable code; and either create a lot of code duplication, or lead to a re-implementation of the original code (adding new bugs; do we want to have a compat flag for that as well?)
gfmads IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev