Re: Calc function names saved to file and backward compatibility
Hi Winfried, darn, another mail in the queue.. On Thursday, 2015-02-19 10:19:57 +0100, Winfried Donkers wrote: OK, then I suggest the following. Current situation: Calc UI ODF Excel FDIST LEGACY.FDISTFDIST F.DIST COM.MICROSOFT.F.DISTF.DIST F.DIST.RT COM.MICROSOFT.F.DIST.RT F.DIST.RT New situation: Calc UIODF-old names, kept ODF Excel FDISTLEGACY.FDIST FDIST (no change) F.DIST COM.MICROSOFT.F.DIST FDISTF.DIST F.DIST.RTCOM.MICROSOFT.F.DIST.RT F.DIST.RT (no change) To be done in two steps. Looks good to me. Shall I prepare step 1 for branch 4-4 and step 2 for master? Yes, as you already did ;) I'll review. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key ID 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/ Care about Free Software, support the FSFE https://fsfe.org/support/?erack pgpzI4MInPLiL.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
RE: Calc function names saved to file and backward compatibility
Hi Eike, Looks good to me. However, we should keep the F.DIST.RT also in the UI for the case of loading it from OOXML, to prevent user worries or for users being used to it and resave it to OOXML as it was, and only map it to LEGACY.FDIST when writing to ODF, so that it will be UI FDIST when loaded from ODF. [...] I don't think we should change UI names in this case. FDIST is what users are used to since ages, suddenly naming something else FDIST is just confusing. Maybe add a hint in scfuncs.src, ala this is OpenFormula FDIST and this is OpenFormula LEGACY.FDIST. OK, then I suggest the following. Current situation: Calc UI ODF Excel FDIST LEGACY.FDISTFDIST F.DIST COM.MICROSOFT.F.DISTF.DIST F.DIST.RT COM.MICROSOFT.F.DIST.RT F.DIST.RT New situation: Calc UIODF-old names, kept ODF Excel FDISTLEGACY.FDIST FDIST (no change) F.DIST COM.MICROSOFT.F.DIST FDISTF.DIST F.DIST.RTCOM.MICROSOFT.F.DIST.RT F.DIST.RT (no change) To be done in two steps. Shall I prepare step 1 for branch 4-4 and step 2 for master? Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Calc function names saved to file and backward compatibility
Hi Winfried, On Wednesday, 2015-02-18 13:08:30 +0100, Winfried Donkers wrote: Ok, I suggest the following: Calc UI ODF-old names to be kept ODF-new names Excel F.DIST COM.MICROSOFT.F.DIST FDIST _xlfn.F.DIST FDISTCOM.MICROSOFT.F.DIST.RT LEGACY.FDIST _xlfn.F.DIST.RT and FDIST (import only) Looks good to me. However, we should keep the F.DIST.RT also in the UI for the case of loading it from OOXML, to prevent user worries or for users being used to it and resave it to OOXML as it was, and only map it to LEGACY.FDIST when writing to ODF, so that it will be UI FDIST when loaded from ODF. Excel's FDIST is now obsolete, but still supported by Excel (how long?). My guess is forever.. I think the change could be done in one go for UI FDIST and F.DIST.RT, as new files can be read by older versions. Only for UI F.DIST a 2 step change will be needed. I don't think we should change UI names in this case. FDIST is what users are used to since ages, suddenly naming something else FDIST is just confusing. Maybe add a hint in scfuncs.src, ala this is OpenFormula FDIST and this is OpenFormula LEGACY.FDIST. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key ID 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/ Care about Free Software, support the FSFE https://fsfe.org/support/?erack pgpWKl_i5h4jP.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
FW: Calc function names saved to file and backward compatibility
Resending to the dev-list... Winfried -Oorspronkelijk bericht- Van: Winfried Donkers Verzonden: woensdag 18 februari 2015 12:14 Aan: 'Eike Rathke' Onderwerp: RE: Calc function names saved to file and backward compatibility hi Eike, What we usually do is add a compatibility name to older release branches so the next release there can read both, the new name and the old name, but continues to write the old name so earlier releases of the same (usually two) branches are not affected. Then for the next release branch (now master) switch from writing the old name to writing the new name, but still accept the old name forever. Ok, I suggest the following: Calc UI ODF-old names to be kept ODF-new names Excel F.DIST COM.MICROSOFT.F.DIST FDIST _xlfn.F.DIST FDISTCOM.MICROSOFT.F.DIST.RT LEGACY.FDIST _xlfn.F.DIST.RT and FDIST (import only) (current situation is Calc UI ODF Excel FDIST LEGACY.FDISTFDIST F.DIST COM.MICROSOFT.F.DIST_xlfn.F.DIST F.DIST.RT COM.MICROSOFT.F.DIST.RT _xlfn.F.DIST.RT - FDIST (not used) ) The ODF FDIST is identical with Excel2010's F.DIST, except for the optional 4th argument, which is handled in the code already. The ODF LEGACY.FDIST is identical with Excel's FDIST and Excel2010's F.DIST.LT. Excel's FDIST is now obsolete, but still supported by Excel (how long?). I think the change could be done in one go for UI FDIST and F.DIST.RT, as new files can be read by older versions. Only for UI F.DIST a 2 step change will be needed. Can you agree with my plans? Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
RE: Calc function names saved to file and backward compatibility
Hi Eike, What we usually do is add a compatibility name to older release branches so the next release there can read both, the new name and the old name, but continues to write the old name so earlier releases of the same (usually two) branches are not affected. Then for the next release branch (now master) switch from writing the old name to writing the new name, but still accept the old name forever. You can find examples of that in sc/source/core/tool/compiler.cxx ScCompiler::IsOpCode() in aOdffAliases. Thank you for your explanation. I will start with it. Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Calc function names saved to file and backward compatibility
Hi Winfried, On Thursday, 2015-02-12 11:22:04 +0100, Winfried Donkers wrote: In Calc, the current situation is: Calc UIODF Excel FDIST LEGACY.FDIST FDIST F.DIST COM.MICROSOFT.F.DIST _xlfn.F.DIST F.DIST.RT COM.MICROSOFT.F.DIST.RT _xlfn.F.DIST.RT (ODF's FDIST is not used) I think the desired situation is: Calc UIODF Excel FDIST COM.MICROSOFT.FDIST FDIST No, the UI FDIST is actually the ODF LEGACY.FDIST which was specified after those implementations. F.DIST FDIST _xlfn.F.DIST F.DIST.RT LEGACY.FDIST_xlfn.F.DIST.RT (in case of UI's F.DIST, on export to Excel add argument cum=true, if absent) Correct, I think (if the F.DIST.RT is actually the LEGACY.FDIST, I didn't check now). These F-distribution functions are not unique having this problem, at least (ISO)WEEKNUM (tdf#50950) and probably other distribution functions share this. Actually this one is easier, as it involves only some renaming of function names written to files, not functionality or changes in parameters and add-in vs. built-in function. I think an agreed method should be used to fix these problems, with the method to be determined (or is the method already defined?). In practice yes, in theory no ;-) I still wanted to have that written that down somewhere. IIRC I even created almost empty wiki pages but then got distracted.. have to retrieve them again. What we usually do is add a compatibility name to older release branches so the next release there can read both, the new name and the old name, but continues to write the old name so earlier releases of the same (usually two) branches are not affected. Then for the next release branch (now master) switch from writing the old name to writing the new name, but still accept the old name forever. You can find examples of that in sc/source/core/tool/compiler.cxx ScCompiler::IsOpCode() in aOdffAliases. So for older release branches you'd add FDIST with ocFDist_LT there, and in master you'd add COM.MICROSOFT.F.DIST with ocFDist_LT and in formula/source/core/resource/core_resource.src section RID_STRLIST_FUNCTION_NAMES_ENGLISH_ODFF replace COM.MICROSOFT.F.DIST with FDIST for SC_OPCODE_F_DIST_LT. AKAICS, this method ranges from one code change (breaking compatibility with older versions and documents), via stepped code changes (maintaining compatibility for e.g. 2 Lo versions) to (but excluding) not changing anything. It's maintaining compatibility for the last two release branches. We did the same for erroneously written ODF attributes btw. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key ID 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/ Care about Free Software, support the FSFE https://fsfe.org/support/?erack pgpI4TwgTEgkL.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Calc function names saved to file and backward compatibility
Hi, I'm working on tdf#40835 again and experience a problem that is easily solved in the code, but does present backward compatibility problems in the saved (ods) documents. There are 2 ODF functions (FDIST and LEGACY.FDIST) and 3 Excel functions (FDIST, F.DIST and F.DIST.RT). In Calc, the current situation is: Calc UIODF Excel FDIST LEGACY.FDIST FDIST F.DIST COM.MICROSOFT.F.DIST _xlfn.F.DIST F.DIST.RT COM.MICROSOFT.F.DIST.RT _xlfn.F.DIST.RT (ODF's FDIST is not used) I think the desired situation is: Calc UIODF Excel FDIST COM.MICROSOFT.FDIST FDIST F.DIST FDIST _xlfn.F.DIST F.DIST.RT LEGACY.FDIST_xlfn.F.DIST.RT (in case of UI's F.DIST, on export to Excel add argument cum=true, if absent) These F-distribution functions are not unique having this problem, at least (ISO)WEEKNUM (tdf#50950) and probably other distribution functions share this. I think an agreed method should be used to fix these problems, with the method to be determined (or is the method already defined?). AKAICS, this method ranges from one code change (breaking compatibility with older versions and documents), via stepped code changes (maintaining compatibility for e.g. 2 Lo versions) to (but excluding) not changing anything. I don't know if this is a developer/UX/ESC matter. Looking forward to suggestions :-) Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
