Proposed changes to script parameters - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: [1] 2 3 4 5 6   Go Down

Proposed changes to script parameters

  • 52 Replies
  • 7743 Views
*

Online philmoz

  • *****
  • 3071
    • Photos
Proposed changes to script parameters
« on: 10 / December / 2014, 17:57:54 »
Advertisements
Moving this discussion to a new thread to save derailing waterwingz' script compression thread further (http://chdk.setepontos.com/index.php?topic=12117) :)

Attached is a patch against 1.3 revision 3788 with some changes to script parameter handling.
This is a work in progress, so may have issues.

Changes:
- Script parameter values no longer stored in 'conf' structure, or saved to CHDK config file.
- Replaced static arrays to store parameter info with dynamically allocated structures. Saves memory as most scripts have only a few parameters.
- Script file only parsed once for parameter details. Parameter values can be reset without parsing script again.
- No hard wired limit on number of parameters.
- Variable names for Lua can be up to 64 characters long (but must start with a letter).
- 'A' - 'Z' allowed for uBasic variables (not fully tested).
- Shorthand syntax for parameter definition in script files (see below). The vidtest.lua script has been updated to demo this.
- Boolean data type for parameter variable - Lua only (see below).
- New name and format for saved script parameter files (see below).

Shorthand parameter syntax:
In addition to the existing syntax for defining script parameters, this patch adds a new shorter syntax.
Parameters can be defined as
Code: [Select]
       #name=value "title"                       - for simple numeric parameters
or     #name=value "title" [min max]             - specify range for parameter (@range)
or     #name=value "title" {opt1 opt2 ... optN}  - specify list of options for user to select from (@values)
The '=' between 'name' and 'value' is optional (if not present use a space), spaces can be inserted before and after if desired.
Single or double quotes can be used for 'title' but should match (quoting is mandatory).

Boolean Lua variable:
Currently defining the [min max] range as [0 1] creates a checkbox for the user; but creates the variable in Lua as a number (with a value of 0 or 1).
In this patch defining the range as [1 0] also give the user a checkbox; but now creates the variable as a boolean in Lua.
This syntax will probably change as it is not very intuitive - proof-of-concept for now.

Saved parameter values:
In the current system the parameter values are saved to files named scriptname_N, where 'scriptname' is the file name of the script and N is an integer from 0 to 9. The data is saved with the old @param and @default definition syntax.
This version saves to scriptname.N using '#name=value' for the syntax. The filename change allows testing without overwriting existing saved parameters. The old files will still be read if there are no new files.

Known Issues:
- There is no error checking when parsing the script parameters (the current system does not have any either). This should probably be fixed.
- 1 character uBasic variable names is not enforced. "@param v1 var1" and "@param v2 var2" will both be accepted; but map to the same variable.

Phil.
Logged
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)
*

Offline waterwingz

  • ******
  • 11786
    • Waterwingz
Re: Proposed changes to script parameters
« Reply #1 on: 10 / December / 2014, 18:20:06 »
Quote from: philmoz on 10 / December / 2014, 17:57:54
Moving this discussion to a new thread to save derailing waterwingz' script compression thread further (http://chdk.setepontos.com/index.php?topic=12117) :)
Attached is a patch against 1.3 revision 3788 with some changes to script parameter handling.
Did you get to look at integrating this with your idea about script tokenizing at load ?  i.e. :
Code: [Select]
    char loader[100];
    sprintf(loader,"local sub = loadfile(%s); collectgarbage(); sub()");
    libscriptapi->script_start(loader,0);
It feels like one of the big reasons for cracking open the script header stuff is to allow script to be tokenized at load and IIRC the current script hearer mechanism is one of the obstacle in the way of doing that?

Quote
This is a work in progress, so may have issues.
Very nice work.  I can take a look if you'd like the code exercised & tested.  But it's kind of dull testing as the resulting script just does the same thing as the old script if everything works correctly.   :-X
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Online philmoz

  • *****
  • 3071
    • Photos
Re: Proposed changes to script parameters
« Reply #2 on: 10 / December / 2014, 18:47:25 »
Quote from: waterwingz on 10 / December / 2014, 18:20:06
Quote from: philmoz on 10 / December / 2014, 17:57:54
Moving this discussion to a new thread to save derailing waterwingz' script compression thread further (http://chdk.setepontos.com/index.php?topic=12117) :)
Attached is a patch against 1.3 revision 3788 with some changes to script parameter handling.
Did you get to look at integrating this with your idea about script tokenizing at load ?  i.e. :
Code: [Select]
    char loader[100];
    sprintf(loader,"local sub = loadfile(%s); collectgarbage(); sub()");
    libscriptapi->script_start(loader,0);
It feels like one of the big reasons for cracking open the script header stuff is to allow script to be tokenized at load and IIRC the current script hearer mechanism is one of the obstacle in the way of doing that?

Part II :)

It needs some additional work to still support uBasic (which requires the file to be pre-loaded).

Quote
Quote
This is a work in progress, so may have issues.
Very nice work.  I can take a look if you'd like the code exercised & tested.  But it's kind of dull testing as the resulting script just does the same thing as the old script if everything works correctly.   :-X

Whatever testing you can do would be appreciated.

Phil.
Logged
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)
*

Online philmoz

  • *****
  • 3071
    • Photos
Re: Proposed changes to script parameters
« Reply #3 on: 11 / December / 2014, 05:46:50 »
Updated patch with some new ideas.

1. Instead of using [1 0] to specify a Lua boolean value, you can use the 'bool' keyword.
E.G.
Code: [Select]
#mode_test=1 "modes test" bool
2. The 'long' keyword will create an input value using the SD override hack. Input value can be in the range 0 - 9,999,999.
E.G.
Code: [Select]
#long_var=1000000 "A big value" long
This technique could be extended to allow other input methods and data types as parameters.
Examples:
- the custom shutter speed input formats (H:MM:SS or the decimal input for short durations)
- textbox that triggers the text or hex input modules (would require supporting changes to the menu system)
- string type that passes the option label instead of the index

An example of the last idea:
Code: [Select]
#menu_test_mode=0 "video start" {auto shoot vid_btn skip}
Existing format - creates a number variable in Lua that will have a value from 0 to 3.

Code: [Select]
#menu_test_mode=0 "video start" {auto shoot vid_btn skip} string
This would create a string variable in Lua that will have the label selected - 'auto', 'shoot', 'vid_btn' or 'skip'.

Phil.
Logged
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)
*

Offline msl

  • *****
  • 1255
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: Proposed changes to script parameters
« Reply #4 on: 11 / December / 2014, 17:45:27 »
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
Logged
CHDK-DE:  CHDK-DE links
*

Online philmoz

  • *****
  • 3071
    • Photos
Re: Proposed changes to script parameters
« Reply #5 on: 11 / December / 2014, 17:57:53 »
Quote from: msl on 11 / December / 2014, 17:45:27
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.
Logged
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)
*

Offline msl

  • *****
  • 1255
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: Proposed changes to script parameters
« Reply #6 on: 12 / December / 2014, 09:16:31 »
The patch has a negative side effect. Affected is get_config_value().

The old ids are shifted. I think that is the causer in conf.c in conf.c:
Code: [Select]
@@ -616,7 +615,6 @@
     1020, // 2 conf.save_raw
     1050, // 3 conf.script_shoot_delay
     1060, // 4 conf.show_histo
-    1051, // 5 conf.script_vars
     1052, // 6 conf.script_param_set
     2150, // 7 conf.show_dof
     2100, // 8 conf.batt_volts_max
The ptpCamGui (more than 5,000 downloads) uses get_config_value(8 ) and get_config_value(9) for the battery check.

get_config_value(2100) and get_config_value(2101) are ok.

msl
Logged
CHDK-DE:  CHDK-DE links
*

Online philmoz

  • *****
  • 3071
    • Photos
Re: Proposed changes to script parameters
« Reply #7 on: 12 / December / 2014, 16:02:01 »
Quote from: msl on 12 / December / 2014, 09:16:31
The patch has a negative side effect. Affected is get_config_value().

The old ids are shifted. I think that is the causer in conf.c in conf.c:
Code: [Select]
@@ -616,7 +615,6 @@
     1020, // 2 conf.save_raw
     1050, // 3 conf.script_shoot_delay
     1060, // 4 conf.show_histo
-    1051, // 5 conf.script_vars
     1052, // 6 conf.script_param_set
     2150, // 7 conf.show_dof
     2100, // 8 conf.batt_volts_max
The ptpCamGui (more than 5,000 downloads) uses get_config_value(8 ) and get_config_value(9) for the battery check.

get_config_value(2100) and get_config_value(2101) are ok.

msl

Thanks for that, updated patch attached.

Phil.
Logged
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)
*

Offline srsa_4c

  • ******
  • 3816
Re: Proposed changes to script parameters
« Reply #8 on: 12 / December / 2014, 18:56:45 »
Quote from: philmoz on 11 / December / 2014, 05:46:50
This technique could be extended to allow other input methods and data types as parameters.
Examples:
- the custom shutter speed input formats (H:MM:SS or the decimal input for short durations)
- textbox that triggers the text or hex input modules (would require supporting changes to the menu system)
- string type that passes the option label instead of the index
Sounds good. Of course all this could be done by scripting, but that would be more or less painful and waste space.
Quote from: philmoz on 11 / December / 2014, 17:57:53
This could be fixed by storing both as 32 bit values; but this will cost a chunk of memory
An alternative method would be better since those 'wide' limits would be quite rarely used (Increasing the whole menu's memory footprint would be too much price to pay).
Logged
*

Offline waterwingz

  • ******
  • 11786
    • Waterwingz
Re: Proposed changes to script parameters
« Reply #9 on: 12 / December / 2014, 19:21:42 »
Quote from: philmoz on 11 / December / 2014, 05:46:50
This technique could be extended to allow other input methods and data types as parameters.
Examples:
- the custom shutter speed input formats (H:MM:SS or the decimal input for short durations)
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).

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
Pages: [1] 2 3 4 5 6   Go Up
« previous next »
 

Related Topics