Proposed changes to script parameters - page 2 - General Discussion and Assistance - CHDK Forum

Proposed changes to script parameters

  • 52 Replies
  • 22700 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Proposed changes to script parameters
« Reply #10 on: 19 / December / 2014, 07:26:24 »
Advertisements
Great. The alternative script header is a very nice improvement.

Strings instead of index values would be nice. Even better would be a variable as table (index + string). Is it also possible to define a range for the big numbers? Or is this too complicated?

My test code:
Code: [Select]
--[[
@title parameter test
#test_number=250 "numbers" [-500 500]
#test_long=1000000 "big numbers" long [0 5000000]
#test_value_id=0 "value id" {val_1 val_2 val_3}
#test_bool=1 "bool" bool
]]

print("number:", test_number)
print("big number:", test_long)
print("value id:", test_value_id)
print("bool:", test_bool)

msl

Thanks for testing.

Having a range on the 'long' value is currently not available - this is mainly because of the 16bit limit on the min & max values for range.
This limit is from the menu system - to save space the min & max are packed into a single int.
This could be fixed by storing both as 32 bit values; but this will cost a chunk of memory (there are a lot of menu items).

The table option is a good idea, now I just have to figure out how to implement it :)

Phil.

I've added the 'table' option to 1.4 revision 3822.

Usage:
Code: [Select]
--[[
#test_table=0 "table" {label1 label2 label3} table
]]

print("test:", test_table.value, test_table.label)

I've also added a test script based on the one you posted (thx).

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 msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: Proposed changes to script parameters
« Reply #11 on: 19 / December / 2014, 08:19:47 »
Thx.

Works fine . Something different than I thought, but a very good solution.

msl
CHDK-DE:  CHDK-DE links

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Proposed changes to script parameters
« Reply #12 on: 19 / December / 2014, 15:36:48 »
Thx.

Works fine . Something different than I thought, but a very good solution.

msl

Thinking about it some more, I'm not sure this is the most useful solution.

Another method that seems to work is to populate the variable with the entire set of option labels, as well as the selected value. This way you could change the variable value in the script; but still have all the labels available. This might be useful for the ISO/Tv/Av values.

Example usage:
Code: [Select]
--[[
#test_table=0 "table" {label1 label2 label3} table
]]

print("test:", test_table.value, test_table[test_table.value])    -- prints selected value and label
print(test_table[0])    -- prints 'label1'


Is this a better solution?

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 msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: Proposed changes to script parameters
« Reply #13 on: 19 / December / 2014, 16:35:42 »
Is this a better solution?
Yes, that was my first thought for a table solution. With the old variant (@values) you always have to create a table.
Code: [Select]
--[[
@param a test
@default a 0
@values a string1 string2 string3
]]
test_table = {string1, string2, string3}
print(test_table[a+1])
With the new proposal is it much easier.

msl
CHDK-DE:  CHDK-DE links

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Proposed changes to script parameters
« Reply #14 on: 19 / December / 2014, 16:54:29 »
Is this a better solution?
Yes, that was my first thought for a table solution. With the old variant (@values) you always have to create a table.
Code: [Select]
--[[
@param a test
@default a 0
@values a string1 string2 string3
]]
test_table = {string1, string2, string3}
print(test_table[a+1])
With the new proposal is it much easier.

msl

New version is in SVN - revision 3824.

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)

Re: Proposed changes to script parameters
« Reply #15 on: 21 / December / 2014, 10:58:59 »
With everything going on this week,  I'm thinking this may have been overlooked :

I've always thought that it would be nice if CHDK actually used the values in each camera's shooting.c file for  aperature_size_table[ ] , shutter_speeds_table[ ], and iso_table[ ]  for something more useful. 

One obvious thought would be to use the data there as the values available for custom Tv, Sv, and Av input fields in script parameters.

In theory,  these tables are tuned to the actual values each camera can use so that's even more powerful.  (Ignoring the possibility that many of them might have been C&P'd from other cameras).
While updating one of my scripts today,  I once again realized that user specified @param values (for Av in particular) allowed choices that the camera does not actually support.  And we have all the necessary information in each camera's shooting.c file to fix that.

There is probably a limit on how many specialized @param / #name things you might want to add but exposure values for a camera scripting system seem like they might be inside of that limit.

I guess I'll prototype something myself and see how it goes.
« Last Edit: 21 / December / 2014, 12:00:47 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

Re: Proposed changes to script parameters
« Reply #16 on: 21 / December / 2014, 12:03:05 »
I started writing up the new syntax for the wiki cross-reference page by looking at philmoz's patches.

I think I have most of what it sorted out but :

Code: [Select]
#name=1 "title" boolkind of jumps out relative to the 0/1 vs false/true Lua discussion.   

I realize it's a limitation of the current get_default() code in gui_script.c and will be non-trivial to fix so I'm "just sayin'" at this point.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Proposed changes to script parameters
« Reply #17 on: 21 / December / 2014, 13:47:01 »
I started writing up the new syntax for the wiki cross-reference page by looking at philmoz's patches.

I think I have most of what it sorted out but :

Code: [Select]
#name=1 "title" boolkind of jumps out relative to the 0/1 vs false/true Lua discussion.   

I realize it's a limitation of the current get_default() code in gui_script.c and will be non-trivial to fix so I'm "just sayin'" at this point.

Do you mean you want to be able to use 'true' and 'false' as the initialiser value?
E.G.
Code: [Select]
#name=true "title" bool

That would be fairly easy to add.
It would also make the 'bool' keyword redundant; but you could keep it to make the intent clear.

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)

Re: Proposed changes to script parameters
« Reply #18 on: 21 / December / 2014, 14:52:40 »
Do you mean you want to be able to use 'true' and 'false' as the initialiser value?
Correct.  Seems consistent with how a Lua script should work?
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Proposed changes to script parameters
« Reply #19 on: 21 / December / 2014, 23:27:57 »
Do you mean you want to be able to use 'true' and 'false' as the initialiser value?
Correct.  Seems consistent with how a Lua script should work?

Added in revision 3839.

I think this works well. It reduces the initial section of the llibtst.lua script from (scroll to see entire code section):
Code: [Select]
--[[
@title lua lib test
@param a skip io
@default a 0
@param b skip all os
@default b 0
@param c skip os time
@default c 0
@param d skip os time fmt
@default d 0
@param e skip os filesystem
@default e 0
@param f skip string
@default f 0
]]

do_io=a==0
do_os=b==0
do_time=c==0
do_fmtdump=d==0
do_dir=e==0
do_string=f==0
to
Code: [Select]
--[[
@title lua lib test
#do_io=true      "test io"
#do_os=true      "test all os"
#do_time=true    "test os time"
#do_fmtdump=true "test os time fmt"
#do_dir=true     "test os filesystem"
#do_string=true  "test string"
]]

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)

 

Related Topics


SimplePortal © 2008-2014, SimplePortal