Menu
▾
▴
#74 hex loader doesn't work with namespace prefixes
When using a hex loader name like 0x3c0x7e.pd for [<~],
you can't use namespace prefixes since the / is only
interpreted as a hex value 0x2f.
For example, [zexy/<~] tries to load only
zexy0x2f0x3c0x7e.pd, and therefore fails.
An additional search path should be added after this
one where the / is used literally without being
translated into a hex code, then it would look for
zexy/0x3c0x7e.pd
Discussion
Anonymous
Logged In: YES
user_id=564396
Originator: NO
how exactly do you think this should happen?
e.g. how should [path//] be resolved? "path0x2f0x2f.pd", "path/0x2f.pd", "path0x2f/.pd" or "path//.pd"?
once there is a precise idea on how the problem should be solved, i can go and implement it.
btw, i changed the category to "externals" since the hexloader is no longer part of pd itself
Logged In: YES
user_id=564396
Originator: NO
i just updated the hexloader external (which replaces the hexloader-code in main pd) to do some special handling of "/".
(the revised hexloader-external is now also able to load abstractions!)
i have tested it under linux and os-x 10.4 (i think) with pd-0.41(os-x) and pd-0.40 (linux);
could you please confirm and eventually close this bug?
Logged In: YES
user_id=801174
Originator: NO
so, tell me, how do you make a pyext loader use the hex loader?
Logged In: YES
user_id=564396
Originator: NO
by calling the sys_load_lib recursively with the alternative names.
the only remaining problem is with abstractions (it turned out, that the hexloader was not really able to load abstractions that contained other abstractions - however, this should be in a different bug-ticket).
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).