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 > [email protected] > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
