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

Making scripting support optional

  • 83 Replies
  • 31078 Views
*

Offline ultimA

  • ***
  • 137
Making scripting support optional
« on: 05 / November / 2010, 21:24:44 »
Advertisements
Logged
*

Offline reyalp

  • ******
  • 14080
Re: Making scripting support optional
« Reply #1 on: 05 / November / 2010, 23:27:42 »
I think the text reader thing is a copy paste bug.

Regarding turning off script: What do you see needing lots of memory without script support ? I guess some low memory cameras could have better zebra.

In any case, it seems like adding the ability to turn of lua would the biggest reward for the effort, and that should be relatively easy.

You are right that things are not cleanly modularized, but naming is only a minor part of the problem.

Logged
Don't forget what the H stands for.
*

Offline ultimA

  • ***
  • 137
Re: Making scripting support optional
« Reply #2 on: 06 / November / 2010, 14:10:21 »
Quote from: reyalp on 05 / November / 2010, 23:27:42
What do you see needing lots of memory without script support ? I guess some low memory cameras could have better zebra.

The goal is exactly what is already obvious: to have more memory. It can be used for a lot things. The corrent code is so huge that some cameras already start crashing if you add a bit more code. Even now, the SX20 port for example has some corner cases where it crashes due to memory. Not reproducible and fortunately it happens very rarely; two weeks before I was on a long trip and my camera only crashed two times even though I made over 3100 pictures.

Another use is to improve quality of stable cameras, zebra is one candidate that you already mentioned. And a 3rd reason for more memory is to have some space for future development. I guess relatively few users use scripting regularly, so the memory space saved by it can be used to add more features in the future, something that can hardly be done currently. (And a 4th nice side effect is that after these efforts code will have become a bit more modularized.)

So to sum it up, I have nothing particular in mind right now (except improving stability), but I do think the saved memory space can be handy in the near future considering the very limited memory of some camera models. Do not think of this modularization as a feature itself, but as laying the ground for features.
« Last Edit: 06 / November / 2010, 14:15:00 by ultimA »
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: Making scripting support optional
« Reply #3 on: 06 / November / 2010, 14:40:56 »
Quote from: ultimA on 05 / November / 2010, 21:24:44
the user can undefine OPT_LUA and OPT_UBASIC and then scripting in that language becomes unavailable.

Not strictly correct.

The user cannot define those options, only someone compiling their own version can.

For what it is worth, available memory is not an issue with SDM because Lua and various other features are not supported (for that reason).

I did make a 'minimal' build for someone that only ran motion-detection.

There were no other features.

It was 95K in size on the A620 :-

http://chdk.setepontos.com/index.php?topic=5116.msg50711#msg50711

Logged
*

Offline fe50

  • ******
  • 3147
  • IXUS50 & 860, SX10 Star WARs-Star RAWs
    • fe50
Re: Making scripting support optional
« Reply #4 on: 06 / November / 2010, 15:30:26 »
ultimA - your suggestion sounds really good to me !  :-*

For me (and i'm sure also for some others), Lua is the favored scripting language, i don't need uBasic support in my builds; removing uBasic stuff easily with a compile option would be great !

For compatibility, uBasic could be enabled on the Autobuild Server by default for some time;
later (or for ports with low memory issues) uBasic could be disabled by default...

The last years we had lots of code changes and additions, new features, individual fixes and workarounds in the CHDK code - a clean up would be good...

Having more free memory for own extensions or stuff would also be great.
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: Making scripting support optional
« Reply #5 on: 06 / November / 2010, 16:25:31 »
Quote from: fe50 on 06 / November / 2010, 15:30:26
later (or for ports with low memory issues) uBasic could be disabled by default...[/i]


That should please the software hackers and frighten-off the photographers  ... in my opinion.

Photographers are not interested in the fact that Lua is :-

a powerful, fast, light-weight, embeddable scripting language. Lua combines simple procedural syntax with powerful data description constructs based on associative arrays and extensible semantics. Lua is dynamically typed, runs by interpreting bytecode for a register-based virtual machine, and has automatic memory management with incremental garbage collection, making it ideal for configuration, scripting, and rapid prototyping.

Logged
*

Offline reyalp

  • ******
  • 14080
Re: Making scripting support optional
« Reply #6 on: 06 / November / 2010, 17:13:14 »
The correct long term solution to memory problem is loadable modules. To me, this would be the place to put effort in a major rewrite, but it depends on the skill set of the person doing the work. Making the scripting stuff more modular will help this some anyway, so it wouldn't be a complete waste.

For low memory cameras, I believe we should have a top platform makefile.inc flag that is something like CAM_LOWMEM which turns off most of the non-photography relevant stuff (games, calender etc.)

Another worthwhile approach would be using non-heap memory (Exmem/mempart alloc) for some things. According to ewavr, you can allocate quite a bit of this without breaking things.

There is some other lowish hanging fruit: The conf system uses a complete copy of the conf structure to detect changes and decide whether saving is needed. Getters and setters that set a dirty bit, or a checksum would eliminate this.

Re compile time options and end users:
Whims gui apparently does this pretty well. It wouldn't be terribly hard to make a web based configurator that builds to order.

As far as lua vs. ubasic
ubasic is insufficient for non-trivial scripting. Photographers benefit from a well documented language that allows them to write readable, maintainable, re-usable code even if they don't know which aspects of the language enable this.
Logged
Don't forget what the H stands for.
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: Making scripting support optional
« Reply #7 on: 06 / November / 2010, 17:32:42 »
Quote from: reyalp on 06 / November / 2010, 17:13:14
Photographers benefit from a well documented language that allows them to write readable, maintainable, re-usable code even if they don't know which aspects of the language enable this.


Then we will have to agree to disagree.

Speaking from experience, most people whose prime interest is photography are not interested in writing any scripts.

I guess it depends on you who you see as your target 'audience'.
Logged
*

Offline hwntw

  • ***
  • 159
Re: Making scripting support optional
« Reply #8 on: 06 / November / 2010, 21:10:21 »
Quote from: Microfunguy on 06 / November / 2010, 17:32:42
Quote from: reyalp on 06 / November / 2010, 17:13:14
Photographers benefit from a well documented language that allows them to write readable, maintainable, re-usable code even if they don't know which aspects of the language enable this.
...

Speaking from experience, most people whose prime interest is photography are not interested in writing any scripts.
...
Ahem, [cough cough].
The only CHDK script I ever use and need is the BadPixel one.
Logged
Ixus 300HS S100


Windows 10
*

Offline ultimA

  • ***
  • 137
Re: Making scripting support optional
« Reply #9 on: 08 / November / 2010, 13:37:00 »
Quote from: Microfunguy on 06 / November / 2010, 14:40:56
Quote from: ultimA on 05 / November / 2010, 21:24:44
the user can undefine OPT_LUA and OPT_UBASIC and then scripting in that language becomes unavailable.
Not strictly correct.
The user cannot define those options, only someone compiling their own version can.
That's what I meant. I'm sorry if I confused some readers.

About disabling UBasic, one of the criteria should be the conversion of most of the better scripts. There are some nice scripts for that language, and unless they are converted to Lua, UBasic should be built automatically on the autobuild server. After that I'm pretty sure it can be turned off. Since most users do not use scripting at all, and even less develop scripts, so as long as a script works no one cares what language it has been written in.

Of course there are other ways to squeez out more memory. Exmem or improving the efficiency of other systems are some examples. Loadable modules are a great thing from an architectural point of view, but since it has its own overhead (memory and maybe some trivial runtime linking), the true wins are not clear until fully implemented. Since we only have a couple of 10's of KBs at our hands, this could be a relatively risky undertake.

So currently, in my oppinion, the easiest and most regarding way to save memory is to turn off unneeded features. And CHDK has so many features, that it will have something unneeded for everybody. The only thing to be aware of is to keep the source as clean as possible.

edit: Status update: I have everything working perfectly, the only thing left to do is making badpixel.bin-creation run native without a script. But it's giving me a headache currently. What is the best way to trigger a shoot from C-code and wait for its completion? Or isn't anything like that available?
« Last Edit: 08 / November / 2010, 17:01:24 by ultimA »
Logged
Pages: [1] 2 3 4 5 6 ... 9   Go Up
« previous next »
 

Related Topics