Making scripting support optional

reyalp

13882

Re: Making scripting support optional

« Reply #30 on: 05 / December / 2010, 22:14:40 »

Advertisements

Quote from: ultimA on 29 / November / 2010, 14:15:52

Here is the patch for the action stack. The action stack is a new architectural feature that decouples the stack commands from scripts. It allows it to be reused for any other code piece, and extends the original stack by the ability to have multiple ones running semi-parallel (=interleaved). It is a pre-requirement for scriptless badpixel.bin and a general framework for other asnychronous jobs/commands/queries/whatever. Note that action stacks always run in the kbd thread, no matter where they were started from.

Checked this in, changeset 1000. Basically unmodified form your patch.

Quote

This patch migrates the original scripting functionality to use the new action stacks. Please somebody test scripting from PTP before submitting to trunk.

I tested this a bit, seems OK. I was able to change modes, push buttons, and shoot over ptp. luar is a bit broken, but it appears to be the same in the previous code. PTP is still work in progress.

Logged

Don't forget what the H stands for.

ultimA

Re: Making scripting support optional

« Reply #31 on: 06 / December / 2010, 11:24:28 »

Here are three very small and trivial patches:

- chdk1000_as_misc.diff: Comment cleanups in action_stack.c. Some of the comments were still referring to the old names of the patch. Update comments to prevent confusion for whoever is reading the code.

- chdk1000_console_close.diff: This is a one-liner bugfix. console.c determines if the console is open by checking if the buffer is NULL or not. So we have to set the buffer NULL after closing the console.

- chdk1000_ptp_script_queries.diff: Adds two new queries to PTP: one to check if scripting is available at all, and one to see if a script is already executing. There has been some interest for both of these commands on the forums.

chdk1000_misc.zip (1.94 kB - downloaded 107 times.)

Logged

rudi

129
A590IS_101B, SX260HS_100B

Re: Making scripting support optional

« Reply #32 on: 13 / December / 2010, 12:51:54 »

Hi,

the function "action_stack_is_finished()" need task-id for lookup, but the return value from "action_stack_create()" is the stack-index. I changed line 76 in action_script.c to

Code: [Select]

return stack->comp_id; and it works fine.

rudi

Logged

ultimA

Re: Making scripting support optional

« Reply #33 on: 13 / December / 2010, 13:49:57 »

Quote from: rudi on 13 / December / 2010, 12:51:54

Hi,

the function "action_stack_is_finished()" need task-id for lookup, but the return value from "action_stack_create()" is the stack-index. I changed line 76 in action_script.c to
Code: [Select]
return stack->comp_id; and it works fine.

rudi

Indeed. Thx for spotting this.

Logged

ultimA

Re: Making scripting support optional

« Reply #34 on: 18 / December / 2010, 23:19:16 »

I'm sorry for the delay, I just need to find some free time for this. I'll try and post a patch in the Christmas break.

Logged

reyalp

13882

Re: Making scripting support optional

« Reply #35 on: 19 / December / 2010, 13:38:05 »

Quote from: ultimA on 18 / December / 2010, 23:19:16

I'm sorry for the delay, I just need to find some free time for this. I'll try and post a patch in the Christmas break.

I'm in the same boat, I only got through the first two of the last 3 patches. Will try to do the PTP one today.

Logged

Don't forget what the H stands for.

reyalp

13882

Re: Making scripting support optional

« Reply #36 on: 19 / December / 2010, 16:39:34 »

I've added this, with some modification, changeset 1005
- updated CHDK PTP protocol minor to 0.2
- ScriptStatus returns a bitmask of status values. Bit 0 of param 1 is set if script is running, otherwise cleared
- ScriptSupport returns a bitmask of supported scripting interfaces. Bit 0 of param 1 is set if Lua is supported, otherwise cleared

With this, if we add more scripting interfaces or additional status information, we can do it in backward compatible way without adding new commands.

I'll post a an updated ptpcam in the PTP thread.

Logged

Don't forget what the H stands for.

asm1989

527
SX720, SX260, SX210 & SX200

Re: Making scripting support optional

« Reply #37 on: 25 / December / 2010, 07:00:20 »

How is going the non-script badpixel integrated in the trunk?

Logged

ultimA

Re: Making scripting support optional

« Reply #38 on: 03 / January / 2011, 16:28:09 »

Here's the next patch. I already had this ready a week ago, but for reasons outside of my control I couldn't test it. This only contains shifting code so that less #ifdefs will need to be placed. The next patch will then be the #ifdefs themselves. There should be no change in behavior or in functionality, with one small exception: (ubasic_)camera_press and friends previously used to set ubasic_error if the function argument (a string) was not a valid button. I deleted setting this variable, as this same function was/is also used by lua scripts. Since it cannot be retrieved from lua and no other error for lua was set, behavior across scripting languages was already inconsistent. But worse, it was theoretically possible for a bad lua program to cause an error in another correct ubasic script. And removing it also reduces coupling of the two languages, which was my primary goal.

@asm1989: If all goes well, scriptless badpixel will be posted parallel to my next patch.

chdk1005_script_refactor.diff (26.46 kB - downloaded 95 times.)

Logged

reyalp

13882

Re: Making scripting support optional

« Reply #39 on: 03 / January / 2011, 21:58:59 »

Quote from: ultimA on 03 / January / 2011, 16:28:09

Here's the next patch. I already had this ready a week ago, but for reasons outside of my control I couldn't test it. This only contains shifting code so that less #ifdefs will need to be placed. The next patch will then be the #ifdefs themselves. There should be no change in behavior or in functionality, with one small exception: (ubasic_)camera_press and friends previously used to set ubasic_error if the function argument (a string) was not a valid button. I deleted setting this variable, as this same function was/is also used by lua scripts.

It seems desirable to produce an error or warning when this happens.

Quote

Since it cannot be retrieved from lua and no other error for lua was set, behavior across scripting languages was already inconsistent. But worse, it was theoretically possible for a bad lua program to cause an error in another correct ubasic script.

Lua and ubasic cannot run at the same time

Logged

Don't forget what the H stands for.