[PD-dev] [PD] zexy: >~, <~, ==~ not working on osx: hexloader problem?

[Hans-Christoph Steiner]

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 at 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