starseeker (Oct 22 2020 at 12:00): starseeker (Oct 22 2020 at 12:00):FWIW: the libged init loads all commands so we can do things like list the valid defined commands and do the "near-miss" command lookup, without requiring any hard coding of a 'fixed' command list. It's also a convenient way to detect any problems with the plugins at startup, so we can catch any errors in regression testing. I'd want to make sure we preserve all those capabilities if we shift to on-the-fly lookup...
(The only hard coded list is the exec_mapping.cpp file, and the purpose of that is to define the C functions for the libged programming API needed at compile time.)
I had initially envisioned the dynamic nature of the plugin mechanism as a way to extend the ged command set at run time - it's not implemented right now, but the libged_init would load the "standard" command set and then users could supply their own commands via plugin loading if they wanted to extend the command set...
Sean (Oct 22 2020 at 12:14):Yeah, I totally got all that. It's just that it shouldn't load unless it needs to. That near-miss logic is specific to an mged/archer app and doesn't necessarily apply to an app that just runs a command or three. Right?
starseeker (Oct 22 2020 at 12:15):Right - it's for interactive apps that want to assist the user
Sean (Oct 22 2020 at 12:15):Even for mged/archer, if a "top" command misses, it could still maybe just load all the "t*" commands. If it's always needing a list of all commands, there's really no reason for this all to be dynamic. It's just complexity and overhead.
Sean (Oct 22 2020 at 12:16):It's also slightly different if the app requests loading everything at a particular time. That's cool too.
Sean (Oct 22 2020 at 12:17):which is kind of how I see mged behaving, it can pull up the list periodically, e.g., during startup but then still check dynamically as needed (in case something was installed).
starseeker (Oct 22 2020 at 12:18):So ged_cmd_lookup would move somewhere else then.
Sean (Oct 22 2020 at 12:19):probably. not a big deal, but it does stick out at the moment since it basically loads everything on any access
Sean (Oct 22 2020 at 12:19):which is really weird for apps like that bigdb app that just needed to call tops and title.
starseeker (Oct 22 2020 at 12:20):In fairness, the current form of that init logic was driven mostly by the initial testing requirements, which were attempting to shake out any problems with any of the commands. I didn't optimize it for minimal loading.
Sean (Oct 22 2020 at 12:20):in theory, only calling ged_exec(tops) should only load the tops plugin I'd think
starseeker (Oct 22 2020 at 12:20):Agreed.
Sean (Oct 22 2020 at 12:21):I think I might have a solution for the "where's the libexec" dir, testing it out
starseeker (Oct 22 2020 at 12:21):Make sure you check OpenBSD - that breaks directory logic where nothing else does...
starseeker (Oct 22 2020 at 12:23):ged_cmd_list would have to move too, that also assumes full knowledge of all available commands.
Sean (Oct 22 2020 at 21:12):yeah, I will do. I just tried an OpenBSD yesterday and it failed on trunk.
Last updated: Oct 09 2024 at 00:44 UTC