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
On Apr 19, 2007, at 4:32 AM, IOhannes m zmoelnig wrote:
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.
Lucky for us, there is wikipedia (\0 == NULL):
NTFS \0 / FAT \ : * ? " < > | / Win32 subsystem \ : * ? " < > | ext2 \0 / ext3 \0 / reiserfs \0 / HFS : HFS+ \0 Mac OS X : /
So putting that together gives us:
\0 \ : * ? " < > | /
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.
Sounds good. My only concern would be whether it would slow things down with all those look ups, and maybe cause more clicks when loading new objects.
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.
It will break the build, but that's easy to fix. ;)
.hc
mfga.sdr IOhanens
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
-
Hans-Christoph Steiner -
IOhannes m zmoelnig