Making scripting support optional - page 6 - General Discussion and Assistance - CHDK Forum  
« previous next »
Pages: 1 2 3 4 5 [6] 7 8 9   Go Down

Making scripting support optional

  • 83 Replies
  • 33622 Views
*

Offline ultimA

  • ***
  • 137
Re: Making scripting support optional
« Reply #50 on: 07 / January / 2011, 17:31:51 »
Advertisements
The tests I have done with my patches were done on two cameras: an ixus55 (100b) and my own sx20 (102d). Though I only did some basic tests, things seemed to work fine on both cameras. I notice that both the g12 and the ixus95 are in active development and have only recently entered beta status. Can someone maybe test on "stable" cameras?

But for the g12, it does worry me, that you mentioned things worked fine previously. So can you confirm that *my* pathes broke correct behavior?

@c10ud: I missed your original post and all I see now are the edits. Can you please describe once more in detail what the problem is?
Logged
*

Offline c10ud

  • ***
  • 245
Re: Making scripting support optional
« Reply #51 on: 07 / January / 2011, 17:48:48 »
i don't know if it's related to this patch, but i guess it's the major thing that got into chdk.. i didn't test g12 with previous trunk, but a friend of mine did with another camera..
the problem, in short, is that the shoot script (or, action) doesn't change state_shooting_progress so it never reaches _DONE ( = 3) when doing a non-normal shoot (e.g. Tv, HDR or CHDK Tv override mode) as it does normally. if you print the value to the osd, you'll see after a simple shoot() it will become 3..but (my test) if you ask a 10" exp while in Tv mode (or just override with chdk), calling a blocking shoot() will never return because state_shooting_progress won't change from 0 to 3 but it will remain 0. Which means if you make a non-blocking call, it will work flawlessly..BUT, also in this case, the raw_need_postprocess thing won't get executed
Logged
*

Offline reyalp

  • ******
  • 14111
Re: Making scripting support optional
« Reply #52 on: 08 / January / 2011, 02:02:45 »
Quote from: c10ud on 07 / January / 2011, 17:48:48
i don't know if it's related to this patch, but i guess it's the major thing that got into chdk..
Try a build without the patch then... This hasn't been applied to the trunk, so you could just download an autobuild. I don't really understand what you are trying to describe.

raw_need_postprocess doesn't actually do anything btw.


On the subject of the patches. I'm not very happy with them. The proliferation of #ifdefs is insane. There has to be a better way. There *are* better ways.

I'm torn whether to apply it and try to clean it up or just punt.
I guess I'll add it.

Also
Code: [Select]
+#ifdef OPT_SCRIPTING
+    static const char* modes[]={ "Never", "Alt", "Script", "Always" };
+#else
+    static const char* modes[]={ "Never", "Alt", "Always" };
+#endif
This is wrong.
« Last Edit: 08 / January / 2011, 02:39:56 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Making scripting support optional
« Reply #53 on: 08 / January / 2011, 04:49:21 »
And you once mentioned luar -- are you doing all this via CHDK PTP? At least previously you couldn't (or shouldn't have) run scripts that took more than a few seconds via PTP.
Logged
*

Offline c10ud

  • ***
  • 245
Re: Making scripting support optional
« Reply #54 on: 08 / January / 2011, 05:32:53 »
i am referring to the previous patchset (the whole action stack, etc.)that is now part of chdk-trunk.. i didn't apply the latest four ultima posted myself

however i'll now try to compile this camera with the older core code and see what happens.

what makes my head spin is btw that state_shooting_progress: it sounds...wrong :) grepping the code shows only a few references to it, and assignments are really strange (it's set _only_ in raw.c (?) and _NONE when starting a shoot()....and _DONE when shoot ended but requires a state != _NONE...but what if i don't do raw? it still changes)

@fudgey: yep, it's much faster to test stuff. well, why shouln't i feed it with long-running script (as soon as the timeouts are ok, of course)..but this is probably offtopic:)
Logged
*

Offline c10ud

  • ***
  • 245
Re: Making scripting support optional
« Reply #55 on: 08 / January / 2011, 06:12:56 »
ok, after some testing (recompiled the old stack for g12) seems like the issue persists. i guess this must be camera dependant (!) However that doesn't explain why for the other camera the problem showed up only with the newer code.. i apologize for any "wtf" i may have caused.

(btw, i still don't understand the state_shooting_progress thingie)

edit: a quick workaround for the issue seems to be, in action_stack.c
Code: [Select]
    case AS_WAIT_SAVE:
        // added
        if ((state_shooting_progress != SHOOTING_PROGRESS_PROCESSING) &&
            (state_shooting_progress != SHOOTING_PROGRESS_DONE))
            state_shooting_progress = SHOOTING_PROGRESS_PROCESSING;
        ///added
        if (state_shooting_progress == SHOOTING_PROGRESS_DONE)
            action_pop();
        break;
« Last Edit: 08 / January / 2011, 06:28:22 by c10ud »
Logged
*

Offline reyalp

  • ******
  • 14111
Re: Making scripting support optional
« Reply #56 on: 08 / January / 2011, 15:46:05 »
Quote from: c10ud on 08 / January / 2011, 05:32:53
i am referring to the previous patchset (the whole action stack, etc.)that is now part of chdk-trunk.. i didn't apply the latest four ultima posted myself
It would have been helpful to make that clear from the start.

Quote
@fudgey: yep, it's much faster to test stuff. well, why shouln't i feed it with long-running script (as soon as the timeouts are ok, of course)..but this is probably offtopic:)
If it were me, I'd take PTP out of the equation entirely, at least to verify that the camera behaves the same way. PTP, and shooting from PTP are doing several things the original firmware would not expect.
Logged
Don't forget what the H stands for.
*

Offline ultimA

  • ***
  • 137
Re: Making scripting support optional
« Reply #57 on: 08 / January / 2011, 20:59:23 »
Quote from: reyalp on 08 / January / 2011, 02:02:45
On the subject of the patches. I'm not very happy with them. The proliferation of #ifdefs is insane.

And there would have been even much more ifdefs without the code shuffling I've done before it.

Quote from: reyalp on 08 / January / 2011, 02:02:45
There has to be a better way. There *are* better ways.
What are those better wayS with our current tools? (e.g. please don't mention dynamic module loading)
Logged
*

Offline reyalp

  • ******
  • 14111
Re: Making scripting support optional
« Reply #58 on: 08 / January / 2011, 21:14:16 »
Notes from merging this. I'm not asking for a patch that fixes these (yet) just keeping track of issues and things tested

with ptp, without lua
Code: [Select]
ptp.c: In function `handle_ptp':
ptp.c:191: error: `size_t' undeclared (first use in this function)
Adding stddef.h fixes.

Attempting to execute lua via ptp without lua support, camera shuts down. Same happens if no PTP support at all, maybe camera doesn't like unknown command with data phase ? Version command is OK (doesn't shut down cam)

.lua scripts are executed as ubasic. Would be better to still recognize lua and give an error.

ubasic scripts seem OK. tried MDFB and defualt script.

with ptp, without ubasic or lua
Code: [Select]
ptp.o: In function `handle_ptp':
ptp.c:(.text+0x198): undefined reference to `script_is_running'
ifdef added to script_status

So we can assume none of this is tested with PTP ;)

Function seems OK without script.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14111
Re: Making scripting support optional
« Reply #59 on: 08 / January / 2011, 21:19:37 »
Quote from: ultimA on 08 / January / 2011, 20:59:23
What are those better wayS with our current tools? (e.g. please don't mention dynamic module loading)
read the section on ifdefs here http://www.kernel.org/doc/Documentation/SubmittingPatches

It's not ifdefs that are the problems, it's ifdefs in the flow of already complicated code.

It's ok, after the patch was applied it's not quite a bad as I thought. I'll try to go on an #ifdef killing rampage later...

edit:
And please don't take my frustration and criticism the wrong way. This is a useful addition and wouldn't have been done without your hard work. Thank you.

edit:
Checked in optional though patch #2 (optional scripting code) changeset 1034

Scriptless badpixel is next changeset 1035

edit:
motion detection was broken for lua in this build. fixed in changeset 1036, among other things.
« Last Edit: 09 / January / 2011, 01:53:36 by reyalp »
Logged
Don't forget what the H stands for.
Pages: 1 2 3 4 5 [6] 7 8 9   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal