1.4 development planning thread

reyalp

14118

Re: 1.4 development planning thread

« Reply #180 on: 11 / October / 2015, 17:28:22 »

Advertisements

Minor status note: I'm currently swamped with real life stuff, should be out from under it by the end of next week. Haven't heard from hacki regarding the tool chain update.

Logged

Don't forget what the H stands for.

reyalp

14118

Re: 1.4 development planning thread

« Reply #181 on: 19 / October / 2015, 16:43:53 »

The trunk autobuild is now using the EABI build (gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 from https://launchpad.net/gcc-arm-embedded/+download)

I've verified that the current build loads and boots on d10.

For anyone else who wants to use this on linux, note that it is a 32 bit binary. 64 distros should be able to run it without problems, but if you've never installed any other 32 bit applications, you may need to add support.
The specific commands to do this will depend on the distro.

On Debian this goes something like

Code: [Select]

dpkg --add-architecture i386
apt-get update
apt-get install libc6:i386

To see if the first step has already been done, check if

Code: [Select]

dpkg --print-foreign-architectures

prints "i386"

Note that other debian-based distros (like Ubuntu) may use different commands.

Native 64 bit toolchains are available from linaro (e.g. https://releases.linaro.org/15.02/components/toolchain/binaries/arm-none-eabi/) but require glibc 2.14 which may be too new for some older distros.

After 1.4 is released, we should update the wiki to suggest these pre-built toolchains for linux, since using them is generally a lot easier than configuring your own.

Logged

Don't forget what the H stands for.

waterwingz

12140

Re: 1.4 development planning thread

« Reply #182 on: 11 / November / 2015, 23:36:22 »

Quote from: reyalp on 19 / December / 2014, 01:27:00

I'd like to try for a faster release than 1.3. So once we've got some complete working features in place, we should start thinking about a release.

Ahem.

Edit : I really should have asked here "Is there anything we can do to help get this out this year?"

« Last Edit: 12 / November / 2015, 08:36:22 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14118

Re: 1.4 development planning thread

« Reply #183 on: 12 / November / 2015, 16:13:21 »

Quote from: waterwingz on 11 / November / 2015, 23:36:22

Edit : I really should have asked here "Is there anything we can do to help get this out this year?"

http://chdk.setepontos.com/index.php?topic=10833.80

I hope to declare release candidate status Real Soon Now.

Logged

Don't forget what the H stands for.

reyalp

14118

Re: 1.4 development planning thread

« Reply #184 on: 15 / November / 2015, 16:37:38 »

I have officially declared 1.4 in release candidate status on the wiki news page and created a thread encouraging users to try it.

Core changes from now until release should be limited to bug fixes. Port specific development can continue as normal.

I hope to have the release official by the end of November. I'll try to post a target date at least 1 week in advance.

Logged

Don't forget what the H stands for.

reyalp

14118

Re: 1.4 development planning thread

« Reply #185 on: 15 / November / 2015, 17:50:12 »

I'm considering a version numbering change: Calling the 1.4 "release" version 1.4.1 instead of 1.4.0

In the current scheme there's little distinction between builds of a given version before and after the release. We've ran into a few cases where people said they were using 1.3 and it took a bit of back and forth to realize they were using an old 1.3 dev build that didn't include all "1.3" features. You can check the build number, but it's less obvious and non-autobuild builds might not have it.

Using the 3rd digit would also also scripts intended for the release version of 1.4 to easily specify it as 1.4.1, so pre-release dev builds would generate a warning.

I don't think using the 3rd digit would break anything, but if anyone has concerns that this would impact scripts, autobuilds etc or thinks this is a bad idea for other reasons, please post.

Logged

Don't forget what the H stands for.

waterwingz

12140

Re: 1.4 development planning thread

« Reply #186 on: 15 / November / 2015, 20:34:26 »

Quote from: reyalp on 15 / November / 2015, 17:50:12

I don't think using the 3rd digit would break anything, but if anyone has concerns that this would impact scripts, autobuilds etc or thinks this is a bad idea for other reasons, please post.

I like it.

Logged

Ported : A1200 SD940 G10 Powershot N G16

msl

1280
A720 IS, SX220 HS 1.01a

Re: 1.4 development planning thread

« Reply #187 on: 16 / November / 2015, 17:33:10 »

I see no problems with a versioning 1.4.1.

msl

Logged

CHDK-DE: CHDK-DE links

srsa_4c

4451

Re: 1.4 development planning thread

« Reply #188 on: 21 / November / 2015, 20:15:36 »

One neglected part of the code is the compatibility check (it was my idea so it would be my responsibility I guess). I still haven't got around finishing it, so it will very likely stay as is (= ineffective, except for the sx280) for the release.

Actually, I had an additional idea that is related: we should implement some basic integrity check
- for the CHDK core
- for the modules
... so that broken files have less chance to make trouble.
The check could be something as simple as a checksum of all words - this could be done with almost no performance hit in the loader's relocation routine (we could replace individual routines with a common routine). Module checksum check would however slow module loading somewhat.

I apologize for mentioning the latter in this thread, but did not want to make a separate post/thread for something that's just an idea.

Thoughts, implementation ideas on both subjects are welcome.

Logged

reyalp

14118

Re: 1.4 development planning thread

« Reply #189 on: 21 / November / 2015, 21:04:11 »

Quote from: srsa_4c on 21 / November / 2015, 20:15:36

One neglected part of the code is the compatibility check (it was my idea so it would be my responsibility I guess). I still haven't got around finishing it, so it will very likely stay as is (= ineffective, except for the sx280) for the release.

Thanks for the reminder. I agree that it doesn't seem realistic to finish for 1.4, and probably not worth delaying for.

I wonder if it would be worth enabling for ixus110?

Quote

Actually, I had an additional idea that is related: we should implement some basic integrity check
- for the CHDK core
- for the modules
... so that broken files have less chance to make trouble.
The check could be something as simple as a checksum of all words - this could be done with almost no performance hit in the loader's relocation routine (we could replace individual routines with a common routine). Module checksum check would however slow module loading somewhat.

I'm not against this, but I wonder how often it would help. I suspect most things that are fixed by a re-install aren't actually due to corrupt files on the card. I guess there are some errors that could cause corruption in memory.

Quote

I apologize for mentioning the latter in this thread, but did not want to make a separate post/thread for something that's just an idea.

It can always be moved if needed.

Logged

Don't forget what the H stands for.