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?
OK I've extended my code scanning to lens.c and I think I see how the direction is handled :-)
David I forgot to ask: why use cm for focal_distance and mm for DoF? Why not be consistent with mm throughout?
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.
Once again, thanks for your inputs here.
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).
After fiddling around, I can no longer reproduce - with exactly the same code I used to reproduce earlier every time. No idea what's going on...
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
Still having the issue after the prop changes...
Alex: I've been silent as I'm not in a position to do any testing at the moment.