Lua functions and other language details - page 2 - LUA Scripting - CHDK Forum

Lua functions and other language details

  • 18 Replies
  • 12424 Views
*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: Lua functions and other language details
« Reply #10 on: 09 / April / 2013, 13:28:41 »
Advertisements
Something tells me Lua is not going to end up in SDM any time soon.

It will NEVER be supported by SDM, why should it ?
We are just taking photos, not testing elegant programming techniques for the benefit of developers.
If a user really needs Lua (which is difficult to believe) just use CHDK.

In fact, I have suggested to someone that the new SDM installer should download SDM and CHDK, the CHDK DISKBOOT file having its extension temporarily changed.

 This is not the topic of this thread!!! ::) >:(



Thanks goes to reyalp for your very interesting informations.

msl
CHDK-DE:  CHDK-DE links

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Lua functions and other language details
« Reply #11 on: 09 / April / 2013, 19:11:44 »
Question - why does 'lua_script_start' create a new Lua thread/state (Lt), and run the script on that thread instead of just using the main thread/state created by lua_open (L)?

Sample code I found with Google only seems to use the main thread.

I tried removing 'Lt' and just using 'L' and it all still seems to work - I'm sure there is a reason for it, just curious as to what it is.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline lapser

  • *****
  • 1093
Re: Lua functions and other language details
« Reply #12 on: 09 / April / 2013, 20:01:32 »
I tried removing 'Lt' and just using 'L' and it all still seems to work - I'm sure there is a reason for it, just curious as to what it is.
That's interesting. I tried changing it like this:

//    Lt = lua_newthread( L );
    Lt = L ; //testing

My script works with the change, so I think I'll do another lua yield bug test with this version. It seems like it would add a lot of unnecessary complexity to have 2 lua threads running in one task.

Digging into lua_newthread(), it seems to reserve another lua stack, so it would be more memory efficient with one thread. I also discovered where they set the lua stack size in lua.h so I'll try doubling it for my bug test.

/* minimum Lua stack available to a C function */
//#define LUA_MINSTACK   20
#define LUA_MINSTACK   40

[EDIT] I noticed that Lt is used for pushing values returned to Lua from C functions, and L is used for other things. I think the reason for the extra thread is to get more stack space for C functions called by Lua. But it looks like changing LUA_MINSTACK does the same thing more efficiently. Considering this, I think I'll up the stack size to 80 for the test.

[EDIT2]ptpcamGUI connects but fails to INIT with this version. Maybe the extra lua thread is for PTP?
« Last Edit: 09 / April / 2013, 20:28:40 by lapser »
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline reyalp

  • ******
  • 14126
Re: Lua functions and other language details
« Reply #13 on: 09 / April / 2013, 21:55:37 »
It seems like it would add a lot of unnecessary complexity to have 2 lua threads running in one task.
There aren't actually two threads running.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14126
Re: Lua functions and other language details
« Reply #14 on: 09 / April / 2013, 22:16:20 »
Question - why does 'lua_script_start' create a new Lua thread/state (Lt), and run the script on that thread instead of just using the main thread/state created by lua_open (L)?
I don't know for sure, but I would guess it's because the lua_resume documentation suggests that you need to create a thread first: http://www.lua.org/manual/5.1/manual.html#lua_newthread

To expand on my previous reply, everything happens in Lt, so the "other thread" really isn't doing anything, or adding significant complexity or resource usage.

These posts
http://lua-users.org/lists/lua-l/2012-02/msg00078.html
http://lua-users.org/lists/lua-l/2004-03/msg00007.html (note this is quite old!)
suggests that it would be OK to just use the main thread. I didn't find any detailed discussion with a quick search.

Also be careful with your "L". The global L refers to the original global lua state, but the L parameter in the functions must generally refer to Lt.
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Lua functions and other language details
« Reply #15 on: 09 / April / 2013, 22:26:48 »
Question - why does 'lua_script_start' create a new Lua thread/state (Lt), and run the script on that thread instead of just using the main thread/state created by lua_open (L)?
I don't know for sure, but I would guess it's because the lua_resume documentation suggests that you need to create a thread first: http://www.lua.org/manual/5.1/manual.html#lua_newthread

To expand on my previous reply, everything happens in Lt, so the "other thread" really isn't doing anything, or adding significant complexity or resource usage.

These posts
http://lua-users.org/lists/lua-l/2012-02/msg00078.html
http://lua-users.org/lists/lua-l/2004-03/msg00007.html (note this is quite old!)
suggests that it would be OK to just use the main thread. I didn't find any detailed discussion with a quick search.

Also be careful with your "L". The global L refers to the original global lua state, but the L parameter in the functions must generally refer to Lt.

I'd read through some of that documentation and this statment
    Threads are subject to garbage collection, like any Lua object.
got me to wondering if the garbage collector was somehow 'collecting' Lt and returning it's memory to the heap.
This might explain the wierd behaviour and values being seen.

All of which led me to wonder why we need Lt in the first place - seems like it may not be needed.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline reyalp

  • ******
  • 14126
Re: Lua functions and other language details
« Reply #16 on: 09 / April / 2013, 22:40:21 »
All of which led me to wonder why we need Lt in the first place - seems like it may not be needed.
It would have to be very broken indeed to collect an active (running / suspended) thread.
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Lua functions and other language details
« Reply #17 on: 09 / April / 2013, 23:01:09 »
All of which led me to wonder why we need Lt in the first place - seems like it may not be needed.
It would have to be very broken indeed to collect an active (running / suspended) thread.

I don't fully understand this discussion:
http://lua.2524044.n2.nabble.com/How-to-stop-yielded-threads-from-being-garbage-collected-td7026468.html
but it seems to be saying that a yielded thread can be garbage collected if there is no reference to it.

Is it possible the lua_script_start code is not properly saving a reference to Lt?

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline reyalp

  • ******
  • 14126
Re: Lua functions and other language details
« Reply #18 on: 09 / April / 2013, 23:13:37 »
Is it possible the lua_script_start code is not properly saving a reference to Lt?
It's is stored in the "registry" which should keep a reference. Also, per that post if you were having this problem, it should give the mentioned error, not just die with a corrupt lua state.

I *really* don't think this is the issue, since you can force a full garbage collection and not have it die. Either the thread would be correctly referenced or not, it's not going to randomly stop being referenced after a thousand gc cycles.
Don't forget what the H stands for.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal