You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
of course it has been a problem for years that script authors want to distribute copies of required engine classes with their script libs.
one option is simply to "name-mangle" the engine class when you copy it. not a terrible solution but a bit weird looking and really requires everyone follow a robust mangling scheme consistently.
but it also could be mitigated at a system level, and i really think its high time we did this:
i think it would have to be a separate process that runs before the sclang service. (or sure, i guess could be part of maiden and run at install time, but that's not the only way stuff gets put in dust/code. i'd rather have it check every time the device / software stack is started.)
this new thingy (program/module/shell script) would have to recursively scan under /dust/code for any duplicated class names.
(i think we can assume script-supplied engines won't end up in any of the other possible SC class locations.)
note that it's the class names which can't collide, not actually the file names. (the error messages etc sort of assume that class names and file names are equivalent, which is typically true but not always.)
anyways, the thingy would scan for duplicate class names (reading every .sc file and parsing just class names out of the topmost scope), and then, idk, move duplicates to a location where SC won't look at them, and report it. (i guess it could also do name-mangling itself, but that seems weird since it'd have to touch lua files too.)
and of course we also never did follow through on these fine suggestions and preliminary work for runtime-interpreted engine code: #863
The text was updated successfully, but these errors were encountered:
of course it has been a problem for years that script authors want to distribute copies of required engine classes with their script libs.
one option is simply to "name-mangle" the engine class when you copy it. not a terrible solution but a bit weird looking and really requires everyone follow a robust mangling scheme consistently.
but it also could be mitigated at a system level, and i really think its high time we did this:
i think it would have to be a separate process that runs before the sclang service. (or sure, i guess could be part of maiden and run at install time, but that's not the only way stuff gets put in
dust/code
. i'd rather have it check every time the device / software stack is started.)this new thingy (program/module/shell script) would have to recursively scan under
/dust/code
for any duplicated class names.(i think we can assume script-supplied engines won't end up in any of the other possible SC class locations.)
note that it's the class names which can't collide, not actually the file names. (the error messages etc sort of assume that class names and file names are equivalent, which is typically true but not always.)
anyways, the thingy would scan for duplicate class names (reading every .sc file and parsing just class names out of the topmost scope), and then, idk, move duplicates to a location where SC won't look at them, and report it. (i guess it could also do name-mangling itself, but that seems weird since it'd have to touch lua files too.)
and of course we also never did follow through on these fine suggestions and preliminary work for runtime-interpreted engine code:
#863
The text was updated successfully, but these errors were encountered: