No purpose for CHDK.
If I may remind you, you are dealing with people who have thousands of hours of experience with CHDK.Be polite or risk getting banned.
Quote from: philmoz on 27 / June / 2017, 18:03:19For a dual partition card, this appears to change the 'size' value returned by luaCB_get_partitionInfo from the size of the large partition where photos will be saved, to the size of the small (bootable) partition.Phil.That's partially correct. That value has nothing to do with partition info (it doesn't even return the size of a partition). Anyway, this should "fix" that.
For a dual partition card, this appears to change the 'size' value returned by luaCB_get_partitionInfo from the size of the large partition where photos will be saved, to the size of the small (bootable) partition.Phil.
Although this could be done by simply extending the table returned from get_partitionInfo, I think it is also worth renaming the fields to make it clearer what they are (doing this in get_partitionInfo makes it incompatible).
Field name changes could be (suggestions welcome):- count --> partition_count- active --> bootable_partition- type --> bootable_partition_type- size --> photo_partition_sizeMB
Great idea overall, but may I politely offer my remarks?Quote from: philmoz on 29 / June / 2017, 18:01:32Although this could be done by simply extending the table returned from get_partitionInfo, I think it is also worth renaming the fields to make it clearer what they are (doing this in get_partitionInfo makes it incompatible).I'm not sure if field renaming alone warrants an entirely new interface, but I suppose that's a matter of personal taste.
QuoteField name changes could be (suggestions welcome):- count --> partition_count- active --> bootable_partition- type --> bootable_partition_type- size --> photo_partition_sizeMBI'd suggest boot_partition and boot_partition_type, since "bootable" could be interpreted as signifying the presence of the bootflag.
Either way may cause some level of confusion. If partitions have been swapped on a dual-partition card then this is no longer the 'boot' partition; but it is still potentially the auto-bootable partition (although may not be). This is why I chose 'bootable' rather than 'boot'. Perhaps something else entirely might be needed; but I can't think of an alternative.
I see three options:- keep existing field names and extend get_partitionInfo. Main issue is that the field names are confusing.- rename fields and extend get_partitionInfo. May break existing scripts.- leave get_partitionInfo alone and add new function with new interface. Doesn't break anything and allows us to create a more intuitive interface.
Quote from: philmoz on 29 / June / 2017, 19:22:11I see three options:- keep existing field names and extend get_partitionInfo. Main issue is that the field names are confusing.- rename fields and extend get_partitionInfo. May break existing scripts.- leave get_partitionInfo alone and add new function with new interface. Doesn't break anything and allows us to create a more intuitive interface.FWIW, we do have @chdk_version to handle #2. If it's only a matter of more/renamed fields, a <=1.4 compatibility wrapper would be trivial. I'm pretty agnostic whether this is better, though all else being equal I'd rather not proliferate functions that return similar info.
That's another option, I forgot about the version wrappers. If the changes are applied to both 1.4 & 1.5, then it probably only needs a wrapper in wrap13.lua.
Quote from: philmoz on 30 / June / 2017, 01:54:18That's another option, I forgot about the version wrappers. If the changes are applied to both 1.4 & 1.5, then it probably only needs a wrapper in wrap13.lua.I was thinking wrapper for <= 1.4, with the new function only existing in 1.5. Changing the interface for scripts using @chdk_version 1.4 would not be good, since the "stable" in stable release is mostly the interfaces.Making this change only for 1.5 doesn't help dmitrys problem though, which would argue for a separate function. Even that's pushing the definition of bug fixes only. We could still replace the old interface with a compatibility wrapper in 1.5
Will this work or am I still missing something?
Started by andre117 General Discussion and Assistance
Started by Bernd R General Discussion and Assistance
Started by quid « 1 2 » General Discussion and Assistance
Started by zell « 1 2 » General Discussion and Assistance
Started by srsa_4c « 1 2 » General Discussion and Assistance
