Thanks. I disabled it in trunk r5699.
I verified that is broken in the the general case. The following code should return 10000, 20000, ... 50000, but on the camera (running from chdkptp on elph130) returns nothing.
co=coroutine.wrap(
function()
local xx = {1,2,3,4,5}
while #xx > 0 do
local x = table.remove(xx,1)
local j
for i=1,10000 do
j = x*i
end
coroutine.yield(j)
end
end
)
t={}
repeat
x = co()
table.insert(t,x)
until not x
return t
This is (edit: probably, I thought
![Embarrassed :-[](https://chdk.setepontos.com/Smileys/smile/unsure.gif)
) because the lua_script yield code (called from the debug hook in the case above, but also used for explicit sleep, wait_click etc) doesn't keep track of which coroutine has it has yielded. I think this can be fixed pretty simply, and will look into.
On the one hand, if no one has wanted coroutines for the last 12 years, maybe saving the memory is better. OTOH maybe people have tried to use them, been frustrated and given up.
Long term (lol) I'd like to make Lua C modules work (Lua loading a .flt that implements a Lua library) which would allow some of the lesser used stuff to only be loaded by scripts that need it. That requires the loaded modules be able to import a bunch of C functions from the Lua core at runtime. I may actually try to do this for 1.6
I also debated whether the coroutine lib should be under #if 0 or #ifdef HOST_LUA. hostlua is nominally supposed to reflect the camera configuration, which would argue for #if 0, but in practice we can just exclude it form emu.lua. Coroutines would actually be a natural pattern to use for emulating camera functions.
edit for completeness:
In the previous code, short coroutines that don't use yielding functions would *appear* to work most of the time, but could break unpredictably. set_yield could be used to avoid automatic yielding in coroutines.