new branch - CHDK : Elf Edition - Developers wanted - page 23 - General Discussion and Assistance - CHDK Forum

new branch - CHDK : Elf Edition - Developers wanted

  • 312 Replies
  • 60771 Views
*

Offline philmoz

  • *****
  • 3123
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #220 on: 11 / January / 2012, 16:52:33 »
Advertisements
Thanks, ...

Just compiled branch reyalp-flt 1542:     

Extra P O's= ok
Video parms = ok
Raw parms = ok
Edge overlay = no work
Histo = ok
Zebra = no work
OSD = no editor, no grids,
Visual = some work, some not
Scripting = some work, some not, no loading
Miscell. = File browse = no, Module inspector = no,Text file reader = no, Draw Palette = no, Make card boot = yes, Swap part = (no try), Debug look ok, Remote look ok (no try)

Dave1116


Did you copy the CHDK/MODULES directory contents from the build to the SD card?

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)

*

Offline msl

  • *****
  • 1262
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #221 on: 11 / January / 2012, 17:33:32 »
In my opinion the benefits of encapsulating as much as possible related to a module inside the module itself are significant.

I so agree.

But I think it is also useful to have an unified configuration system. Perhaps there is also another way.

msl
CHDK-DE:  CHDK-DE links

Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #222 on: 12 / January / 2012, 01:37:17 »
This caters for the scenario where the module is loaded with gui_menu_run_fltmodule to access it's sub-menus. In this case the function in 'modules.c' was not used to load the module so it's bind function was not called. If the module is not unloaded when the menus exit this ensures the bind function is called for the already loaded module.
I see. Then for correct processing this scenario module flags should be refreshed with bitwise OR in module_load.
Because generic_flt_run will run with no flags, and then in described case loaded module could be unloaded unsafely later.

Quote
The menu code only unloads modules that have the module index stored in the menu stack array (see the call to gui_activate_sub_menu). DNG does not have a menu so is not affected by this - there is no change to the DNG load/unload behaviour.
load/unload behaviour is changed because MODULE_FLAG_DISABLE_AUTOUNLOAD is cleaned in modules.c. So it will be unloaded on simple sequence "go to ALT mode - goto NONE mode".
Quote
Quote
I'm not sure why did you set flag MODULE_FLAG_DISABLE_AUTOUNLOAD for zebra, but would like to note just in case that this flag will not prevent unloading when leave its submenu.

Unloading the module when exiting the menu ensures the config changes get saved - the module will be re-loaded when next used. If the zebra was turned off then it won't get re-loaded and so this also serves to automatically release the module if it is no longer needed (same applies for edge overlay).

I thought setting the flag was to ensure the module did not get unloaded during normal operation?
I do agree with your unloading scenario for modules with submenus. Different one (on menu item value change like for DNG) could be unsafe if trigger is placed in modularized submenu.

I'm not sure what do you mean saying "normal operation", but meaning and purpose of this flag is preventing unload module on global special case "leave CHDK gui mode (switch to GUI_MODE_NONE)". This was only one case when CHDK knew nothing about unloaded module.

What is for: for example I run game then press ALT button and goto "none" mode. Gui mode is switched and automatically will not get back to module and so this game left unloaded. To prevent this I do unload all modules except flagged (which couldn't be safely unloaded in some processing).

*

Offline philmoz

  • *****
  • 3123
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #223 on: 12 / January / 2012, 01:59:49 »
load/unload behaviour is changed because MODULE_FLAG_DISABLE_AUTOUNLOAD is cleaned in modules.c. So it will be unloaded on simple sequence "go to ALT mode - goto NONE mode".

Thanks for that, I misunderstood what you posted earlier.
That was a mistake on my part - when I cleaned up the modules.c code I forget to include the MODULE_FLAG_DISABLE_AUTOUNLOAD in the DNG code.

Will update SVN with this fixed soon.

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)


Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #224 on: 12 / January / 2012, 17:36:02 »
I described a problem with CCHDK.CFG on virtual keyboard thread. But it looks that the problem is more general. After I changed a language the CCHDK.CFG is also corrupted (colors are changed). The same with loading any kind of script.
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick

*

Offline hwntw

  • ***
  • 158
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #225 on: 12 / January / 2012, 17:53:21 »
Quote
I described a problem with CCHDK.CFG on virtual keyboard thread. But it looks that the problem is more general
I get crashes during settings changes and crashes on restart, after I have added my usual CCHDK.CFG settings. Deleting the CFG file allows an initial start up, but as I do more CFG changes, I get more crashes and a repeat of the crash process thing. Build 1542
Colin
Ixus 300HS S100


Windows 10

*

Offline philmoz

  • *****
  • 3123
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #226 on: 12 / January / 2012, 18:14:40 »
I described a problem with CCHDK.CFG on virtual keyboard thread. But it looks that the problem is more general. After I changed a language the CCHDK.CFG is also corrupted (colors are changed). The same with loading any kind of script.

I inadvertently included some code from another change I'm working on.
Will fix it shortly.

Apologies for the inconvenience.

Phil.

Edit: should be fixed in changeset 1546.

« Last Edit: 12 / January / 2012, 18:57:27 by philmoz »
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)

Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #227 on: 12 / January / 2012, 18:25:43 »
You don't have to apologize. When I'm using such experimental branch I know that I can have no varanty of anything :) I'm rather write to let you know how the problem looks like in a hope it will help you.

Anyway - thank you for so fast response and so much work!
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick


*

Offline philmoz

  • *****
  • 3123
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #228 on: 15 / January / 2012, 04:57:59 »
Are there any objections to moving the current reyalp-flt branch code to the main trunk?

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)

Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #229 on: 15 / January / 2012, 06:37:20 »
If you are going to move current reyalp-flt to trunk could you replace tbox.c code with the patched one:
(direct link to attachment)
http://chdk.setepontos.com/index.php?action=dlattach;topic=7272.0;attach=5937

Description here:
http://chdk.setepontos.com/index.php?topic=7272.msg79760#msg79760


There is a smal fix for keyboard position on the screen. I thought that tsvstar will do changes in reyalp-flt but maybe he had no time.
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick

 

Related Topics