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

new branch - CHDK : Elf Edition - Developers wanted

  • 316 Replies
  • 123258 Views
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #80 on: 19 / December / 2011, 05:16:51 »
Advertisements
What do you mean by 'branch check'?
Stable 1.0 and development trunk are different branches. Just add new one branchid "CHDK_2" and make it as requirement.

Quote
I can understand the need to check if something is specific to CHDK / CHDK-DE / SDM; but within CHDK why would you want to check the branch?
Main purpose of this check - separate different branches, because they have different internals and different versioning.

Quote
Wouldn't this make it difficult for someone to create a test branch for experimentation?

This check is optional. And also ID for private build is already exists.

Quote
Looking at the module_load.c code I don't see how you would cater for multiple 'branches' - e.g. a module is compatible with CHDK and CHDK-DE; but not SDM?
It is not possible now. And I think that allow this will be too complex and danger.
This posibilty require strong dependency between branches. We need to be absolutely sure that both CHDK and CHDK-DE:
a) process things in same way;
b) have exactly same export list (symbols are stored as idx not names, and so we need to be sure that same idx mean same symbol)
And I think that branches are very independent one from other, so this requirements will be not work.
For simple cases (like games) initial symbol set is enough so they could be used without any requirement limitations.

Quote
Also in module_load.c you have an optional check for PLATFORMID.
The PLATFORMID is the camera identifier for a specific model - why would you have a module that is specific to only a single camera model? If you did want this what if the module is compatible with more than one camera model - would you need to compile a seperate module for each camera?
To make RAW operations module platform-independed I used several advanced tricks.
This requirement provide much more simple way to do same thing. I need just add PLATFORMID value (which come from platform.h) into module_info requirement and should worry about nothing. Module will be compiled for each platform exactly as it was compiled before without any changes. Requirement prevent of wrong usage. Very simple.
« Last Edit: 19 / December / 2011, 05:20:00 by tsvstar »

*

Offline whim

  • ******
  • 2046
  • A495/590/620/630 ixus70/115/220/230/300/870 S95
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #81 on: 19 / December / 2011, 06:07:07 »
Quote
This is added to BUILD_NUMBER in version.inc by CHDK-Shell when it downloads the trunk .zip file - it is not included in either CHDK or CHDK-DE by default.

FWIW: It does this by scraping the page source of /browser (and /browser/branches if branch checking
is enabled).

wim

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #82 on: 19 / December / 2011, 06:13:34 »
What do you mean by 'branch check'?
Stable 1.0 and development trunk are different branches. Just add new one branchid "CHDK_2" and make it as requirement.

Quote
I can understand the need to check if something is specific to CHDK / CHDK-DE / SDM; but within CHDK why would you want to check the branch?
Main purpose of this check - separate different branches, because they have different internals and different versioning.

Quote
Wouldn't this make it difficult for someone to create a test branch for experimentation?

This check is optional. And also ID for private build is already exists.

Quote
Looking at the module_load.c code I don't see how you would cater for multiple 'branches' - e.g. a module is compatible with CHDK and CHDK-DE; but not SDM?
It is not possible now. And I think that allow this will be too complex and danger.
This posibilty require strong dependency between branches. We need to be absolutely sure that both CHDK and CHDK-DE:
a) process things in same way;
b) have exactly same export list (symbols are stored as idx not names, and so we need to be sure that same idx mean same symbol)
And I think that branches are very independent one from other, so this requirements will be not work.
For simple cases (like games) initial symbol set is enough so they could be used without any requirement limitations.

Quote
Also in module_load.c you have an optional check for PLATFORMID.
The PLATFORMID is the camera identifier for a specific model - why would you have a module that is specific to only a single camera model? If you did want this what if the module is compatible with more than one camera model - would you need to compile a seperate module for each camera?
To make RAW operations module platform-independed I used several advanced tricks.
This requirement provide much more simple way to do same thing. I need just add PLATFORMID value (which come from platform.h) into module_info requirement and should worry about nothing. Module will be compiled for each platform exactly as it was compiled before without any changes. Requirement prevent of wrong usage. Very simple.

Ok, I think I understand what you are trying to do - it's basically to stop someone copying a compiled .flt module file from another branch/version/camera etc and trying to run it on an incompatible build.

Makes sense now - I'm not sure it needs to be this complex though?

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)
  g7x2 (1.01a, 1.01b, 1.10b)

Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #83 on: 19 / December / 2011, 06:20:32 »
Ok, I think I understand what you are trying to do - it's basically to stop someone copying a compiled .flt module file from another branch/version/camera etc and trying to run it on an incompatible build.
Yes. I would like to prevent questions in future similar to "Why CHDK is crashed often?"(Also often end-user forget to add "I did download .flt file from somewhere/copy from friend flashcard" :) ).


*

Offline whim

  • ******
  • 2046
  • A495/590/620/630 ixus70/115/220/230/300/870 S95
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #84 on: 19 / December / 2011, 06:50:37 »
Ok, I think I understand what you are trying to do - it's basically to stop someone copying a compiled .flt module file from another branch/version/camera etc and trying to run it on an incompatible build.
Yes. I would like to prevent questions in future similar to "Why CHDK is crashed often?"(Also often end-user forget to add "I did download .flt file from somewhere/copy from friend flashcard" :) ).

Why not add some other unique identifier (compilation date/time ?) to both modules and module loader and compare before loading ?

wim
« Last Edit: 19 / December / 2011, 07:00:17 by whim »

Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #85 on: 19 / December / 2011, 07:41:37 »
Why not add some other unique identifier (compilation date/time ?) to both modules and module loader and compare before loading ?

I try to make simple enough to developer version system: checks are optional, separated, only three parameter are defined at module (branch-version-platform) and no changes required in the CHDK core.
And at same time not too restrictive version system:  Now it is possible to share compiled modules. It will start if system is compatible. If I have not enough skill to make platform in-dependend, then this will be only limit. If I add to core some required to module functionality, then I can limit revision (and it will start an all higher versions).
This limits are checked before module load. Also couple of automatic checks made by module system while loading, which require no attention of developer and provide additional layer of safety.

In case of just unique id, modules will save memory but could not be shared. And moreover if I change revision and unique id was changed (just because this is different revision, or even something was changed but only at specific part), I will need to recompile all my modules.

More complex system is that we have now with possible small difference (for example, with  changed "minimal revision" to "minimal version")
« Last Edit: 19 / December / 2011, 07:45:43 by tsvstar »

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #86 on: 19 / December / 2011, 14:14:57 »
Now it is possible to share compiled modules. It will start if system is compatible. If I have not enough skill to make platform in-dependend, then this will be only limit. If I add to core some required to module functionality, then I can limit revision (and it will start an all higher versions).


That's a good goal; but possibly very difficult to achieve at this time for anything but the very simplest code.
There are too many variables set at compile time for the compiled module code to be portable beyond the camera (and possibly firmware version) it was compiled for.

For example the game code gets compiled with the color palette definitions from gui_draw.h - this may work on other cameras using the same palette; but not cameras using different palettes.

Another example is the current generation of both _rawop10.flt and _rawop12.flt during build - only one of these can be used for a given camera and they are very specific to the camera sensor size (CAM_RAW_ROWS and CAM_RAW_ROWPIX are defined in platform_camera.h).
Building both of these modules for all cameras is also a possible source of confusion for new users - both will show in the menu, and users may be uncertain which one to use.
For the _rawopXX.flt code to be portable it would have to determine bits per pixel, CAM_RAW_ROWS and CAM_RAW_ROWPIX at runtime not compile time.

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)
  g7x2 (1.01a, 1.01b, 1.10b)

Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #87 on: 19 / December / 2011, 15:09:25 »
For example the game code gets compiled with the color palette definitions from gui_draw.h - this may work on other cameras using the same palette; but not cameras using different palettes.
I miss that fact. I thought that simple colors are same for all cameras.
This could be significant difficult on the way to platform-independency because affect almost all modules.

Quote
Another example is the current generation of both _rawop10.flt and _rawop12.flt during build - only one of these can be used for a given camera and they are very specific to the camera sensor size (CAM_RAW_ROWS and CAM_RAW_ROWPIX are defined in platform_camera.h).
Building both of these modules for all cameras is also a possible source of confusion for new users - both will show in the menu, and users may be uncertain which one to use.
For the _rawopXX.flt code to be portable it would have to determine bits per pixel, CAM_RAW_ROWS and CAM_RAW_ROWPIX at runtime not compile time.
This is what I'm talking about when I said about advanced tricks. Everything except conditional defines are declared as exported values. It is possible to make declare even sensor depth but this will require changes in module and possible affect to perfomance.
Also this is library. It couldn't be just runed by user.  Core select which one use and noone is displayed to enduser.

Some modules (which require implicit parameters to run or which is library) shouldn't be displayed to end user.  And they are not displayed in module menu.
This modules are marked with flag SYSTEM in module_info. Currently system are: curves, edgeoverlay, textreader (it easy to make non-system, but configurations are still in the core so no reason to do this),  raw_operations, mpopup and modulemenu.


Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #88 on: 19 / December / 2011, 16:33:41 »
The technical aspects of this are beyond me, so can I just say one thing ?

Whatever you do should be to make it easier for the user.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #89 on: 19 / December / 2011, 16:47:44 »
Quote
Another example is the current generation of both _rawop10.flt and _rawop12.flt during build - only one of these can be used for a given camera and they are very specific to the camera sensor size (CAM_RAW_ROWS and CAM_RAW_ROWPIX are defined in platform_camera.h).
Building both of these modules for all cameras is also a possible source of confusion for new users - both will show in the menu, and users may be uncertain which one to use.
For the _rawopXX.flt code to be portable it would have to determine bits per pixel, CAM_RAW_ROWS and CAM_RAW_ROWPIX at runtime not compile time.
This is what I'm talking about when I said about advanced tricks. Everything except conditional defines are declared as exported values. It is possible to make declare even sensor depth but this will require changes in module and possible affect to perfomance.
Also this is library. It couldn't be just runed by user.  Core select which one use and noone is displayed to enduser.

Some modules (which require implicit parameters to run or which is library) shouldn't be displayed to end user.  And they are not displayed in module menu.
This modules are marked with flag SYSTEM in module_info. Currently system are: curves, edgeoverlay, textreader (it easy to make non-system, but configurations are still in the core so no reason to do this),  raw_operations, mpopup and modulemenu.

I missed the SYSTEM stuff, so yes the modules won't show to the users.

But I still think compiling both 10 and 12 bit rawop modules for every camera is a waste - only 1/2 of these compiled modules can ever be used. Why is bit depth treated differently to sensor size, what makes this special?
Why not just compile a single _rawop.flt module that has the bit depth compiled in the same as the sensor size for each camera?

Making the modules portable is a great goal; but I'm not convinced building multiple versions based on an arbitray characteristic like this is the right solution.

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)
  g7x2 (1.01a, 1.01b, 1.10b)

 

Related Topics


SimplePortal 2.3.6 © 2008-2014, SimplePortal