changelog of trunk including comments / devtalk - page 20 - General Discussion and Assistance - CHDK Forum

changelog of trunk including comments / devtalk

  • 299 Replies
  • 242720 Views
Re: changelog of trunk including comments / devtalk
« Reply #190 on: 05 / September / 2014, 15:39:55 »
Advertisements
I think this needs a standardized regulation.
I suspect everyone might hate this suggestion but :

What about a Script Menu setting that lets you pick "legacy return values"  vs "consistent return values"?  Old scripts could be setup to use the former and newer ones would pick the later?

CHDK 1.4.0 could to eliminate support for the legacy mode on release.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 14125
Re: changelog of trunk including comments / devtalk
« Reply #191 on: 05 / September / 2014, 17:43:39 »
What about a Script Menu setting that lets you pick "legacy return values"  vs "consistent return values"?  Old scripts could be setup to use the former and newer ones would pick the later?
Definitely hate that, it should not be a user setting, and it would make a mess of the code and be horribly confusing.

A somewhat better (IMHO)  approach I've considered is adding an @ parameter for script compatibility, e.g.
@version 1.2
or something like that.  In many, if not all cases compatibility could be handled by a lua file that wraps the relevant functions, so backward compatibility wouldn't need to bloat or complicate the C code.

However, this doesn't really solve the issue for existing scripts in a clean way. I guess we could have the default be 1.2 compatible, but produce a warning or something for scripts that don't have the @version tag.

All in all, I think I'd be more in favor of just breaking compatibility between releases. That's a big part of why we created a development branch and a stable branch, and I do believe that having consistent interfaces is worth it in the long run. Then again, I don't have a whole bunch of popular scripts to maintain.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14125
Re: changelog of trunk including comments / devtalk
« Reply #192 on: 05 / September / 2014, 17:44:50 »
A script function name should be understandable. But this renaming was a bad attempt - sorry.
I'm fine with renaming this (again) but since my last attempt was bad, I'm waiting for a consensus of more than 1 before changing it again.
Don't forget what the H stands for.

Re: changelog of trunk including comments / devtalk
« Reply #193 on: 05 / September / 2014, 22:26:38 »
Definitely hate that, it should not be a user setting, and it would make a mess of the code and be horribly confusing.

A somewhat better (IMHO)  approach I've considered is adding an @ parameter for script compatibility, e.g.
@version 1.2
or something like that.  In many, if not all cases compatibility could be handled by a lua file that wraps the relevant functions, so backward compatibility wouldn't need to bloat or complicate the C code.

However, this doesn't really solve the issue for existing scripts in a clean way. I guess we could have the default be 1.2 compatible, but produce a warning or something for scripts that don't have the @version tag.

All in all, I think I'd be more in favor of just breaking compatibility between releases. That's a big part of why we created a development branch and a stable branch, and I do believe that having consistent interfaces is worth it in the long run. Then again, I don't have a whole bunch of popular scripts to maintain.
There are really not a lot of good options that will not create massive confusion and pain. Other than leaving things the way they are that is. Or defaulting things so that @version type stuff "just works" for existing scripts.

Sorry.

Much as I hate to say this, the desire to "purify" the coding conventions at the expense of breaking a rather large installed base is questionable.  If we do nothing, things will just carry on as they are.  The five or six people who actually write the better scripts that people seem to like will live with the "unpurity", code around it, and carefully wash their hands with soap after touching them. And the scripts will just work.

Quote
All in all, I think I'd be more in favor of just breaking compatibility between releases. That's a big part of why we created a development branch and a stable branch, and I do believe that having consistent interfaces is worth it in the long run. Then again, I don't have a whole bunch of popular scripts to maintain.
The distinction between 1.1.0,  1.2.0, 1.3.0 etc means a lot to those of us that live here.  And nothing to everyone else.

I tend to suspect that 9 out of 10 CHDK casual users ( statistics made up on the spot ) will simply walk away when the script they have downloaded fails with a Lua error message.

Although, to #include another thread's topic,  if 1.4.0 included most of the most popular scripts, suitably sorted & updated, that might help?

EDIT :I think I could live with a change (1.2.0 -> 1.3.0)  that also produced a meaningful error message (i.e. verbose) the did not simple say standard Lua error messages related to  something about boollean expected ... something that clearly said ("You need a newer version of this script to work with the version of CHDK you are using").    (Editorial Note : just to be clear,  the most difficult to understand Lua error message is still 10x better than the best uBASIC error message.)
« Last Edit: 05 / September / 2014, 22:35:50 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 14125
Re: changelog of trunk including comments / devtalk
« Reply #194 on: 05 / September / 2014, 23:01:52 »
There are really not a lot of good options that will not create massive confusion and pain.
Agreed
Quote
Other than leaving things the way they are that is.
Which causes ever increasing pain for the people who do try to work with.
Quote
Or defaulting things so that @version type stuff "just works" for existing scripts.
That doesn't really solve things unless you have a some kind of deprecation warning and a schedule to phase out the deprecated features. It would also be a royal pain in the rear to maintain.

Quote
Much as I hate to say this, the desire to "purify" the coding conventions at the expense of breaking a rather large installed base is questionable.  If we do nothing, things will just carry on as they are.
Sure, but the cost of things carrying on as they are is not zero.
Quote
The distinction between 1.1.0,  1.2.0, 1.3.0 etc means a lot to those of us that live here.  And nothing to everyone else.
Well then that's a massive failure on my part. On of the main reasons to have an unstable branch is to be able to break compatibility and have a relatively clean transition.

Unfortunately, we've been telling people "oh yeah the trunk is unstable but it's probably stable enough to use so use it" and shot ourselves in the foot.

I don't have a good solution, but I lean toward leaving things pretty much as they are in 1.3 and breaking compatibility early in 1.4.

We could introduce and @version type thing for 1.4, and show a warning "this script is designed for an earlier version of chdk" if it isn't present or is for the wrong version.
Don't forget what the H stands for.

Re: changelog of trunk including comments / devtalk
« Reply #195 on: 05 / September / 2014, 23:11:52 »
Well then that's a massive failure on my part. On of the main reasons to have an unstable branch is to be able to break compatibility and have a relatively clean transition.
Normally I'd agree if it was just about config files and UI changes that default to different values.   But we have an additional level of complexity because we support scripts.  And breaking those is much more costly.

Quote
Unfortunately, we've been telling people "oh yeah the trunk is unstable but it's probably stable enough to use so use it" and shot ourselves in the foot.
What about the other existing pre-1.3.0 Lua functions that do not consistently return boolean ?

Quote
I don't have a good solution, but I lean toward leaving things pretty much as they are in 1.3 and breaking compatibility early in 1.4. We could introduce and @version type thing for 1.4, and show a warning "this script is designed for an earlier version of chdk" if it isn't present or is for the wrong version.
Works for me.  I'm thinking a downloadable catalog of 1.4.0 compatible scripts might be nice.  Use the earlier scripts (many of which do not work now anyway when they use the wrong propcase values) at your peril.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: changelog of trunk including comments / devtalk
« Reply #196 on: 06 / September / 2014, 08:18:25 »
Some thoughts for a consensus:

First we should define some standards for (new) script commands. These standards should enforced starting with version 1.3. It means, that all commands newly developed in Version 1.3 be provided in accordance with these standards. Older commands should remain untouched. They are well documented and there are many examples.

I'm fine with renaming this (again) but since my last attempt was bad, I'm waiting for a consensus of more than 1 before changing it again.
Agreed. But hardly one is interested in such marginal things. It will be difficult to get other opinions.

msl
CHDK-DE:  CHDK-DE links

Re: changelog of trunk including comments / devtalk
« Reply #197 on: 06 / September / 2014, 10:57:02 »
First we should define some standards for (new) script commands. These standards should enforced starting with version 1.3. It means, that all commands newly developed in Version 1.3 be provided in accordance with these standards. Older commands should remain untouched. They are well documented and there are many examples.
I'll disagree here and suggest we clean up all function return values at one time in 1.4.0.    Otherwise the bigger scripts will all start with complicated IF statements trying to define which version of each function to use based on calling get_buildinfo().  A clean break with a required change in the @param section to enable using the new return values will make life so much easier.

Quote
I'm fine with renaming this (again) but since my last attempt was bad, I'm waiting for a consensus of more than 1 before changing it again.
Agreed. But hardly one is interested in such marginal things. It will be difficult to get other opinions.

msl
To throw some  more wood on this fire :
 
We orginally released a function called enable_highspeed_usb()

After much debate on IRC, this was changed to enable_remote_hp_timer() to avoid confusion with USB 1.0 vs 2.0 vs 3.0 port speeds.

msl has suggested fast_usb_power_detection().

One consideration missing from the discussion is that while the function enables high precision timing for USB remote,  it also requires you to provide the timer period needed via a passed parameter.

So perhaps something like :  set_usb_timing()   (or set_usb_timer_period()) would be a better choice and better describe the functionality?  The end user or  average script writer does not care that making that call changes how timing is done internally - to them it simply changes the timing precision (and coincidentally the accuracy).
« Last Edit: 06 / September / 2014, 12:06:44 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline srsa_4c

  • ******
  • 4451
Re: changelog of trunk including comments / devtalk
« Reply #198 on: 06 / September / 2014, 16:20:58 »
In case there's a chance that the A/D converter input will ever provide the same functionality as the USB input, perhaps the function name should not include "usb"?

Re: changelog of trunk including comments / devtalk
« Reply #199 on: 06 / September / 2014, 17:17:04 »
In case there's a chance that the A/D converter input will ever provide the same functionality as the USB input, perhaps the function name should not include "usb"?
AFAIK, it already does provide the same functionality.  However the data is provides is mostly accessed via the get_usb_power() function and it's configured in the USB Remote menu.  But your point is well taken.

How about set_remote_timing() then?  Or maybe set_remote_control_input_device_timing() ?
« Last Edit: 06 / September / 2014, 17:19:26 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

 

Related Topics


SimplePortal © 2008-2014, SimplePortal