moved this to pd-dev... Hans-Christoph Steiner wrote: > On Apr 18, 2007, at 11:19 AM, IOhannes m zmoelnig wrote: > >> how should i proceed? > > Hmm, I like the idea of encapsulating the hexloader code, but I think > if the hexloader is a separate loader, then the other loaders won't > benefit from its translation of non-alphanumeric ASCII. I think the > way the loader stuff is implemented, it is just a failover, if the > first loader fails, then the next one tries. I think that the > classname should be the filename not only for objects written in C > and Pd, but also any other language.
i agree, but i don't see a way to achieve this. even if the hexloader is in the pd-core there is still no way to use the hex-expansion from within other loaders. > If you are rearchitecting this stuff, I would like to make a > suggestion. What I would also like to see is that the hexloader is > split into two naming schemes: file system, which would translate > only / \ : * ? " < > | and the setup function, which would do the > whole translation. That would make the files a lot more readable. this is basically a good idea. the reason why i did not go the entire way is that i am not sure whether '/ \ : * ? " < > |' is the entire set of forbidden characters on all filesystems. the way i am currently (in the new hexloader loader) doing it, is just trying to expand the classname in several ways and then trying _all_ expansions (including the original classname) as both filenames and setupnames. adding another expansion is just trivial. i don't see any real reason for differentiation between filenames and setup-routines as long as the entire set is tested. (e.g. with class "v*" i am now doing a test for "v*_setup()" in v*.l_i386 and v0x2a.pd_linux even though "v*_setup()" is not a valid functionname in C. i don't think that there is any harm in this. > > If the loader is the route you end up taking, the CVS directory > hierarchy sounds good to me, feel free to move the libdir loader to > it's own folder, or leave it. i think i'll move it and hope to not break things. mfga.sdr IOhanens _______________________________________________ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev