Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

duplicate engines mitigation #1746

Open
catfact opened this issue Dec 7, 2023 · 1 comment
Open

duplicate engines mitigation #1746

catfact opened this issue Dec 7, 2023 · 1 comment

Comments

@catfact
Copy link
Collaborator

catfact commented Dec 7, 2023

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

@tehn
Copy link
Member

tehn commented Dec 7, 2023

i think this is a a good idea.

given an engine install from maiden requires a matron/crone restart, having this script run at matron start seems like it'd be robust.

i think this could be done pretty easily with a very short shell script?

  • scan dust/code for all .sc files (and probably norns/sc/engines also?)
  • grep list for CroneEngine which returns lines that look like Engine_PolyPerc : CroneEngine {
  • grab the first token, if it's in the list already, the file needs to be moved. if not, add it to list

where should the "holding area" be? or it could be renamed in-place, like *.sc.disabled

and soft-error listing disabled engines should be issued


i like #863 as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants