Making scripting support optional - page 4 - General Discussion and Assistance - CHDK Forum supplierdeeply

Making scripting support optional

  • 83 Replies
  • 30869 Views
*

Offline reyalp

  • ******
  • 14079
Re: Making scripting support optional
« Reply #30 on: 05 / December / 2010, 22:14:40 »
Advertisements
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.
Don't forget what the H stands for.

*

Offline ultimA

  • ***
  • 137
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.

*

Offline 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

*

Offline ultimA

  • ***
  • 137
Re: Making scripting support optional
« Reply #33 on: 13 / December / 2010, 13:49:57 »
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.


*

Offline ultimA

  • ***
  • 137
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.

*

Offline reyalp

  • ******
  • 14079
Re: Making scripting support optional
« Reply #35 on: 19 / December / 2010, 13:38:05 »
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.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14079
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.
Don't forget what the H stands for.

*

Offline 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?


*

Offline ultimA

  • ***
  • 137
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.

*

Offline reyalp

  • ******
  • 14079
Re: Making scripting support optional
« Reply #39 on: 03 / January / 2011, 21:58:59 »
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 ???
Don't forget what the H stands for.

 

Related Topics