Re: [Libreoffice-qa] Calc quality and compatibility tests
Hi Pedro, On Thursday, 2013-02-28 08:55:54 -0800, Pedro wrote: So - datefuns works perfectly for me in master and in 4.0; 18 out of 18. Really? I get 14 out of 18. No wonder, that document uses functionality that varies depending on the locale in use and as such is an example of how a document is not to be designed if it is to be used in an internationalized context. Instead of using DATEVALUE() with an arbitrary string the DATE() function should be used (best) or DATEVALUE() with an ISO 8601 string that works in any locale (alternative). It surprises me that the MONTH function worked for you. It should fail for everyone everywhere because the date for 0 (zero) in Excel is 1/0/1900 while in Calc it is 12/30/1899 as default. So MONTH returns 1 in Excel and 12 in Calc... Only for MONTH(0) but that is not used in the document. Excel has that famous 1900 is a leap year bug so claims 1900-02-29 would exist, the one day offset in Calc compensates for that, with the result that dates between 1900-01-01 and 1900-02-28 are one day off when imported from Excel, but all dates starting at 1900-03-01 are correct. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. New GnuPG key 0x65632D3A : 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Old GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD Support the FSFE, care about Free Software! https://fsfe.org/support/?erack pgpMsg3PelthF.pgp Description: PGP signature ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Calc quality and compatibility tests
Hi Eike Eike Rathke-2 wrote No wonder, that document uses functionality that varies depending on the locale in use and as such is an example of how a document is not to be designed if it is to be used in an internationalized context. Instead of using DATEVALUE() with an arbitrary string the DATE() function should be used (best) or DATEVALUE() with an ISO 8601 string that works in any locale (alternative). I will look into creating a modified/improved version of the test files. Thanks! Pedro -- View this message in context: http://nabble.documentfoundation.org/Calc-quality-and-compatibility-tests-tp4040705p4042451.html Sent from the QA mailing list archive at Nabble.com. ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Calc quality and compatibility tests
Hi Pedro, On Thu, 2013-02-28 at 08:55 -0800, Pedro wrote: So - datefuns works perfectly for me in master and in 4.0; 18 out of 18. Really? I get 14 out of 18. There must be some locale sensitivity in the sheet the; in en_US.UTF-8 locale it works fine for me; take a look: http://users.freedesktop.org/~michael/datefuns.png Which highlights some of the problems with building reliable tests I suspect ;-) Michael Meeks-2 wrote Not sure; as I say there are a lot of corner-cases in that document collection that we don't pass - some of those need major structural change in calc (eg. the boolean type) to make them work. I'm not sure I follow your logic here. There are major structural changes needed so it's best not to touch it? Is it like a wasp's nest? Certainly not - we need to fix this specific issue - but we also have some other major structural changes that we plan in the calc core. We want to do those changes fire since they will conflict with and/or hinder that work, and doing them later will make them easier to do IMHO etc. Not all tasks are standalone - but if you want to work on something here let me know. Michael Meeks-2 wrote As an example of a pair of those. If we have other (small) torture-test documents to exercise one particular feature - implicit intersections say; it'd be great to have help extending that. Are you interested ? :-) no doubt Markus would have some good advice as to exactly what would help improve coverage most. I'm puzzled! How come =sum(2,2) equals 5??? It doesn't ;-) notice the file is called 'hard-recalc.ods' - the filter loads and shows the (wrong) number stored in the .ods as the result without re-calculating, and then tests the functionality behind: https://help.libreoffice.org/Calc/Recalculate With a hard-recalculate. So we know that that works and hasn't regressed :-) I am available to help. But first shouldn't we try to understand why these files work correctly in Excel and Gnumeric but not in Calc? Isn't it a LibreOffice goal to be 100% compatible with Excel files (at least on first import...)? Sure why not said that - as Markus says, if there are corner cases that are not whole categories of problem - (eg. the boolean issue is not tractable just yet), and are isolated to single functions, and are not related to Excel's date complications, then - it'd be good to have some nice clean regression tests for those - and we can split them up into bugs or easy-hacks to fix. All the best, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Calc quality and compatibility tests
Hi Markus Markus Mohrhard wrote I'm not sure I follow your logic here. There are major structural changes needed so it's best not to touch it? Is it like a wasp's nest? It means that it is not as easy as you imagine it. All these large refactoring normally feel for a Calc developer like a open heart transplantation so we are very conservative in major changes there. I never said it was easy (I never imagined it was easy!). But it seemed like an option to avoid doing the heart transplantation definitely (or to ignore the heart condition in the hope that it would heal itself or not get worst if it was ignored :) ). Michael already explained what he meant. Markus Mohrhard wrote No. The target is to be OpenFormula compatible and then as second step check how to be as good in opening Excel files as possible. Our native format is ODF with OpenFormula so this is our main target and we should make always sure to support it as good as possible. Then our next goal is to support Excel roundtrips which is not always trivial as not all concepts between the two can be mapped and our calc formula model is built around ODF. We are working on improving the support for both Excel and OpenFormula but these are long term goals. That is an interesting statement (and probably the most sincere I have read). It makes perfect sense but if only the first goal is achieved then LibreOffice will become an isolated island... Markus Mohrhard wrote So if you want to help out the best thing right now is to go through these files and use the working corner cases in them to create test files that we can use in our existing tests. I will look into this. Thank you for your answer and suggestions ;) Kind regards, Pedro -- View this message in context: http://nabble.documentfoundation.org/Calc-quality-and-compatibility-tests-tp4040705p4040866.html Sent from the QA mailing list archive at Nabble.com. ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Calc quality and compatibility tests
Hi Michael Michael Meeks-2 wrote There must be some locale sensitivity in the sheet the; in en_US.UTF-8 locale it works fine for me; take a look: http://users.freedesktop.org/~michael/datefuns.png Which highlights some of the problems with building reliable tests I suspect ;-) There was no need at all for the screenshot... Yes, locale must have something to do with it. But changing locale is not causing changes... Actually the MONTH problem seems to highlight an inconsistency between OSes (unless you manually selected 01/01/1900 as the reference date...) Michael Meeks-2 wrote I'm not sure I follow your logic here. There are major structural changes needed so it's best not to touch it? Is it like a wasp's nest? Certainly not - we need to fix this specific issue - but we also have some other major structural changes that we plan in the calc core. We want to do those changes fire since they will conflict with and/or hinder that work, and doing them later will make them easier to do IMHO etc. Not all tasks are standalone - but if you want to work on something here let me know. Excellent. Sounds like a good plan. I will focus on the corner cases then ;) Michael Meeks-2 wrote I'm puzzled! How come =sum(2,2) equals 5??? It doesn't ;-) notice the file is called 'hard-recalc.ods' - the filter loads and shows the (wrong) number stored in the .ods as the result without re-calculating, and then tests the functionality behind: https://help.libreoffice.org/Calc/Recalculate With a hard-recalculate. So we know that that works and hasn't regressed :-) Interesting. But then pressing F9 should result in 4 and changing Recalculation on file load for ODF Spreadsheet to Prompt user should ask to recalculate and result in 4 and neither of these actions do anything... Am I missing something or did I just find a couple of bugs/regressions? ( BTW changing Recalculation on file load for ODF Spreadsheet to Always Recalculate does result in 4. Yay! :) ) Michael Meeks-2 wrote Sure why not said that - as Markus says, if there are corner cases that are not whole categories of problem - (eg. the boolean issue is not tractable just yet), and are isolated to single functions, and are not related to Excel's date complications, then - it'd be good to have some nice clean regression tests for those - and we can split them up into bugs or easy-hacks to fix. I will look into those. Wouldn't it make sense that when opening an XLS or XLSX file the reference date was the same as in Excel? Shouldn't this date also be available as an option? Cheers, Pedro -- View this message in context: http://nabble.documentfoundation.org/Calc-quality-and-compatibility-tests-tp4040705p4040875.html Sent from the QA mailing list archive at Nabble.com. ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Calc quality and compatibility tests
On Fri, 2013-03-01 at 03:20 -0800, Pedro wrote: https://help.libreoffice.org/Calc/Recalculate With a hard-recalculate. So we know that that works and hasn't regressed :-) Interesting. But then pressing F9 should result in 4 and changing Notice the '-hard-' in the test ;-) hard re-calc is ctrl-shift-F9 cf. the above wiki page: works for me. I will look into those. Wouldn't it make sense that when opening an XLS or XLSX file the reference date was the same as in Excel? Shouldn't this date also be available as an option? Again - that's a rats nest of evil politics and the consensus so far has been that there are bigger and more useful problems to solve :-) I'd encourage you to work on them first. ATB, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
[Libreoffice-qa] Calc quality and compatibility tests
Hi all While searching for a file in my HDD I found this old datefuns.xls (dated from 2007) After a little search I found out that it belongs to a set of test files from back in 1999 (Yes, from the last century and/or millenium :) ) https://mail.gnome.org/archives/gnumeric-list/1999-June/msg5.html The files are stored here http://projects.gnome.org/gnumeric/func-tests/ The set was created to test Gnome's own Gnumeric compatibility with Excel functions. (in fact there was a young developer named Michael Meeks interested on those problems https://mail.gnome.org/archives/gnumeric-list/1999-June/msg4.html back in 1999 :) ) The interesting part is that many of the functions are still not compatible with LibreOffice 3.6.5.2 (haven't installed 4.0.1.2 which is already available) Can someone convince Yoshida san to look at these? :) In addition there are even some Perl scripts to automagically test if the builds pass the tests... https://github.com/GNOME/gnumeric/blob/master/test/t1006-datefuns.pl I believe this would hugely increment the Quality control (at least in Calc...) Cheers, Pedro -- View this message in context: http://nabble.documentfoundation.org/Calc-quality-and-compatibility-tests-tp4040705.html Sent from the QA mailing list archive at Nabble.com. ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Calc quality and compatibility tests
Hi Pedro, On Thu, 2013-02-28 at 07:12 -0800, Pedro wrote: While searching for a file in my HDD I found this old datefuns.xls (dated from 2007) After a little search I found out that it belongs to a set of test files from back in 1999 (Yes, from the last century and/or millenium :) ) Sure sure - gnumeric has some nice test documents. The set was created to test Gnome's own Gnumeric compatibility with Excel functions. (in fact there was a young developer named Michael Meeks interested on those problems These young people ! they're the very end ;-) The interesting part is that many of the functions are still not compatible with LibreOffice 3.6.5.2 (haven't installed 4.0.1.2 which is already available) So - datefuns works perfectly for me in master and in 4.0; 18 out of 18. In addition there are even some Perl scripts to automagically test if the builds pass the tests... We could easily do that headless during the build in LibreOffice if someone was interested. I believe this would hugely increment the Quality control (at least in Calc...) Not sure; as I say there are a lot of corner-cases in that document collection that we don't pass - some of those need major structural change in calc (eg. the boolean type) to make them work. We actually have some really good unit tests for calc - where we load/calculate and compare to some known-good CSV files. We're always trying to encourage people to add more exotic (but comprehensible) tests of that form here: $ find sc/qa -name 'hard-recalc*' sc/qa/unit/data/contentCSV/hard-recalc.csv sc/qa/unit/data/ods/hard-recalc.ods As an example of a pair of those. If we have other (small) torture-test documents to exercise one particular feature - implicit intersections say; it'd be great to have help extending that. Are you interested ? :-) no doubt Markus would have some good advice as to exactly what would help improve coverage most. All the best, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
Re: [Libreoffice-qa] Calc quality and compatibility tests
Michael Meeks-2 wrote In addition there are even some Perl scripts to automagically test if the builds pass the tests... We could easily do that headless during the build in LibreOffice if someone was interested. I assume people in the QA team would be interested? We are already such tests in the build. See the sc/qa/unit directory for all sorts of tests that we are excecuting during a build. We are already executing import, export and further tests. Michael Meeks-2 wrote Not sure; as I say there are a lot of corner-cases in that document collection that we don't pass - some of those need major structural change in calc (eg. the boolean type) to make them work. I'm not sure I follow your logic here. There are major structural changes needed so it's best not to touch it? Is it like a wasp's nest? It means that it is not as easy as you imagine it. All these large refactoring normally feel for a Calc developer like a open heart transplanation so we are very conservative in major changes there. Michael Meeks-2 wrote As an example of a pair of those. If we have other (small) torture-test documents to exercise one particular feature - implicit intersections say; it'd be great to have help extending that. Are you interested ? :-) no doubt Markus would have some good advice as to exactly what would help improve coverage most. I'm puzzled! How come =sum(2,2) equals 5??? I am available to help. But first shouldn't we try to understand why these files work correctly in Excel and Gnumeric but not in Calc? Isn't it a LibreOffice goal to be 100% compatible with Excel files (at least on first import...)? No. The target is to be OpenFormula compatible and then as second step check how to be as good in opening Excel files as possible. Our native format is ODF with OpenFormula so this is our main target and we should make always sure to support it as good as possible. Then our next goal is to support Excel roundtrips which is not always trivial as not all concepts between the two can be mapped and our calc formula model is built around ODF. We are working on improving the support for both Excel and OpenFormula but these are long term goals. So if you want to help out the best thing right now is to go through these files and use the working corner cases in them to create test files that we can use in our existing tests. Additionally filing bug reports for every case where you see an error would help (maybe also tracking them with a master bug). That helps to make sure that whatever we do in the future non of the working corner cases becomes broken. If you are interested in this task or know people who are willing to help out with it I once wrote a wiki page for non-coders how they can add test cases: https://wiki.documentfoundation.org/Development/Calc_Import_Unit_Tests There is an additional set of test documents from the OOo Calc team at http://www.openoffice.org/sc/testdocs/ that can also be used and transformed into test cases for our automatic tests. Regards, Markus ___ List Name: Libreoffice-qa mailing list Mail address: Libreoffice-qa@lists.freedesktop.org Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
