David, it is great to follow experts like you as you try and fix things. As I look at your proposed lens_focus changes and track back into the ML source, it is not clear to me how the Lua calls will be able to drive the lens in either direction. Or am I missing something?
Alex thanks for pushing this along. I believe Lua scripting is one of ML's latest innovations. I'm keen to get my auto landscape bracketing script published, but it needs the lens focus control fixed first, i.e. to be able to move the lens in both directions.
I hoped to merge it today, but ran into a very strange issue (besides not being able to run all the example scripts in a single session).
After reformatting the card and starting with a fresh copy of ML, it loaded only a few scripts, and stopped at copy2m. Basically, it refuses to load anything after that script. To reproduce, create a temporary directory, move all the scripts there, then move copy2m.lua on the card in ML/SCRIPTS, then copy the rest of the scripts. This way, copy2m will load first. The loader task (lua_load_task) gets killed and the console ends up with incomplete messages.
The problem exists with 892db3e as well (5D3 113, vanilla compilation, no changes on top of that, fresh formatted card), so it wasn't introduced by my changes.
edit: after merging dm-spy-experiments into lua_fix to get a debug log of what is happening, all the scripts load fine (copy2m being first). What the...
edit2: compiled again just lua_fix and the lockup is back.
edit3: merged patchmgr into lua_fix, all fine. Vanilla lua_fix, problem is back. Behavior is consistent (I can reproduce it every time).
I've noticed that copy2m being loaded sometimes causes err70 or err80 in movie mode (usually after stopping recording) on 60D, it's definitely the most problematic script (though it works correctly, it causes general instability), probably the prop handler stuff