Module code V2 - test branch.

I've created a test branch (philmoz-modulesV2) for review/testing of some rework I've done on the module system.

The core changes are:

1. Auto-load of modules when the module functions are used. This replaces code like: if (libscriptapi) libscriptapi->set_as_ret(0);with just libscriptapi->set_as_ret(0);

2. Cleaned up unloading and management of module lifetime.Each loop of the keyboard task the code now asks each module if it can be unloaded. If it returns true then the module is removed. This leaves knowledge and management of the module to the module itself rather than in the core CHDK code. The dng, grid, zebra and edge overlay modules can now unload when not being used instead of remaining in memory.The code also alerts modules when CHDK is leaving <ALT> mode. Many of the modules are only valid in ALT mode (games etc) so they need to quit and unload if the user presses the ALT button.

3. Added logging of the load/unload of the modules to a text file. This can be enabled in the Miscellaneous stuff --> Modules menu. There is also a menu option to delete the log file. The log file is always appended to so it can grow out of control if logging is left on. The log also includes a timestamp when the system writes the first entry each time the camera is restarted.

4. Updated Lua to version 5.1.5 (Feb 2012 release) from 5.1.3 (Jan 2008 release).I also looked at 5.2; but the changes are much more substantial so will take a lot more effort to update.

I assume you'd like some testing on a few different cameras? Any thoughts on a test suite - sounds like multiple loading & unloading of anything that's done in modules is on order here? Is it worth running a few Lua programs for test purposes? Doesn't look like you have any VxWorks cams on your personal list but so I assume it would be good to find someone who can test a few of those as I don't either......

4. Updated Lua to version 5.1.5 (Feb 2012 release) from 5.1.3 (Jan 2008 release).I also looked at 5.2; but the changes are much more substantial so will take a lot more effort to update.

FWIW, 5.2 includes several features that would be quite useful for CHDK.- ability to yield across certain C calls (meaning dofile, require, pcall could behave more nicely with blocking CHDK API calls)- emergency garbage collector. Tries to collect garbage if allocation fails. By itself this probably wouldn't help too much since the OS would probably fall over when you got that low on memory, but with a custom allocator aware of the actual amount of memory available it could be quite useful.- native bitwise operation library. We already have bit* functions, the main benefit that would be that it would be more portable to other lua code and documented with the core language.

I am NOT saying you should to go out and do this, just that there are worthwhile things there if someone wants to do it.

Also note that Lua doesn't strictly maintain language and library compatibility between releases, so it's possible some existing scripts would be incompatible. They usually provide build time options for deprecated features for one release.

Quote

There is also a menu option to delete the log file. The log file is always appended to so it can grow out of control if logging is left on. The log also includes a timestamp when the system writes the first entry each time the camera is restarted.

I was going to suggest an option for clearing this at boot, but that would be bad for crash debugging. An option might be to rotate it at boot?

I assume you'd like some testing on a few different cameras? Any thoughts on a test suite - sounds like multiple loading & unloading of anything that's done in modules is on order here? Is it worth running a few Lua programs for test purposes? Doesn't look like you have any VxWorks cams on your personal list but so I assume it would be good to find someone who can test a few of those as I don't either......

I've done a reasonable amount of testing on my cameras - there's nothing that should be camera specific (fingers crossed).

But the changes are not trivial which is why I've created this branch - if anyone wants to try it out that would be very helpful.

I will continue using and testing it until I'm comfortable it's stable enough to merge into the trunk - or someone convinces me it's not worthwhile

There is also a menu option to delete the log file. The log file is always appended to so it can grow out of control if logging is left on. The log also includes a timestamp when the system writes the first entry each time the camera is restarted.

I was going to suggest an option for clearing this at boot, but that would be bad for crash debugging. An option might be to rotate it at boot?

I thought about rotating log files; but decided to keep it simple for now.The logging option should really only be turned on to help debugging a module problem.

Do I see it correctly that (the infomation about) recreview_hold is not available for modules? The edge overlay module could use it in case of a future improvement. Haven't checked other state variables, but those could be useful too.

Do I see it correctly that (the infomation about) recreview_hold is not available for modules? The edge overlay module could use it in case of a future improvement. Haven't checked other state variables, but those could be useful too.

It's not currently exported; but it only needs an entry in module_exportlist.c to make it available.

I'm all for updating Lua, especially with the hope of fixing the yield() problem I've been having. It looks like version 5.2 fixed some problems in yield(). I'm not sure if that would fix my yield problem, but it would be another reason to try to update to the latest version of Lua if possible.

@phil, Got [email protected] running on both the A590IS and the SX40HS, took some raw shots and no problems.I couldn't fine the menu item to the CHDK settings menu to allow shortcut keys to be enabled/disabled... I guess this is not there yet.