Re: JUnit sc_complex fails in Localized enviroment
2012/2/28 Stephan Bergmann : > On 02/28/2012 11:38 AM, Markus Mohrhard wrote: >> >> Let me take this over. I think that we might miss a step in our java >> tests that forces the some parts of formulas. We had problems with >> this already in our c++ based tests but were able to force them to >> en-US too. >> >> I think this might be another case that we need to force it like in >> test/source/bootstrapfixture.cxx:95 and 96 > > > Not sure if something like that can also be done from remote (which would be > necessary for that sc_complex test). Setting LC_ALL within the relevant > makefile is possible, but can get nasty wrt multi-platform. (Another option > would be to migrate that test from a qadevOOo based one to a single-process > one.) This is not the only qaDevOOo test that assumes en_US in calc. Nearly all tests aussme it in some way, either in sheet names, separators, date formatting, ... I hope that there is a way to force this through UNO. > > >> IMHO it is not a good idea to change the tests so that they no longer >> use the sheet names because we have them all over the place and it >> will make the test code more complex tha necessary. > > > That would of course keep the test failing for the OP with --with-lang > lacking en-US. Not sure if we want to support that, though. It is not the only calc test failing if you build without en_US. I think we once defined building with en_US as a requirement otherwise we need to rethink the whole calc test concepts. They all assume that en_US is present and set. It is otherwise not possible to test correct import of anything (different formula names, different separator, different default number formats, ...) IMHO we should execute all tests in en_US and assume that everyone builds with en_US. Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: JUnit sc_complex fails in Localized enviroment
On 02/28/2012 11:38 AM, Markus Mohrhard wrote: Let me take this over. I think that we might miss a step in our java tests that forces the some parts of formulas. We had problems with this already in our c++ based tests but were able to force them to en-US too. I think this might be another case that we need to force it like in test/source/bootstrapfixture.cxx:95 and 96 Not sure if something like that can also be done from remote (which would be necessary for that sc_complex test). Setting LC_ALL within the relevant makefile is possible, but can get nasty wrt multi-platform. (Another option would be to migrate that test from a qadevOOo based one to a single-process one.) IMHO it is not a good idea to change the tests so that they no longer use the sheet names because we have them all over the place and it will make the test code more complex tha necessary. That would of course keep the test failing for the OP with --with-lang lacking en-US. Not sure if we want to support that, though. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: JUnit sc_complex fails in Localized enviroment
Hello Stephan, 2012/2/28 Stephan Bergmann : > On 02/28/2012 08:47 AM, Stephan Bergmann wrote: >> >> On 02/27/2012 08:19 PM, Maciej Rumianowski wrote: >>> >>> I have build with pl and de languages and when I set all locale >>> enviroment variables (LANG LC_*) to en_US.UTF-8 the test uses German >>> language with output like: >> >> >> So you configured --with-lang='pl de' (i.e., without any mention of >> en-US), and your solver/*/installation/opt/program/resource/ directory >> does not contain any *en-US.res files? That would explain it. > > > For the record, > > cd sc && LC_ALL=de_DE.utf8 make > /data/lo/core/workdir/unxlngx6/JunitTest/sc_complex/done > > suffices to make this fail for me in a --with-lang='en-US de' build. > Let me take this over. I think that we might miss a step in our java tests that forces the some parts of formulas. We had problems with this already in our c++ based tests but were able to force them to en-US too. I think this might be another case that we need to force it like in test/source/bootstrapfixture.cxx:95 and 96 IMHO it is not a good idea to change the tests so that they no longer use the sheet names because we have them all over the place and it will make the test code more complex tha necessary. Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: JUnit sc_complex fails in Localized enviroment
On 02/28/2012 08:47 AM, Stephan Bergmann wrote: On 02/27/2012 08:19 PM, Maciej Rumianowski wrote: I have build with pl and de languages and when I set all locale enviroment variables (LANG LC_*) to en_US.UTF-8 the test uses German language with output like: So you configured --with-lang='pl de' (i.e., without any mention of en-US), and your solver/*/installation/opt/program/resource/ directory does not contain any *en-US.res files? That would explain it. For the record, cd sc && LC_ALL=de_DE.utf8 make /data/lo/core/workdir/unxlngx6/JunitTest/sc_complex/done suffices to make this fail for me in a --with-lang='en-US de' build. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: JUnit sc_complex fails in Localized enviroment
On 02/27/2012 08:19 PM, Maciej Rumianowski wrote: I have build with pl and de languages and when I set all locale enviroment variables (LANG LC_*) to en_US.UTF-8 the test uses German language with output like: So you configured --with-lang='pl de' (i.e., without any mention of en-US), and your solver/*/installation/opt/program/resource/ directory does not contain any *en-US.res files? That would explain it. Markus, I know very little about the Calc UNO API, but do you think it would be possible to enhance checkEmptyCell and checkFilledCell in sc/qa/complex/cellRanges/CheckXCellRangesQuery.java so that they no longer need to use hard-coded strings that start with "Sheet1" and break down in non-en-US locales? Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: JUnit sc_complex fails in Localized enviroment
Dnia 2012-02-27, pon o godzinie 10:58 +, Michael Meeks pisze: > Hi there, > > On Sat, 2012-02-25 at 17:52 +0100, Maciej Rumianowski wrote: > > I hjave discovered a problem when checking libreoffice build (master), > > below is log. It seems that test is not fully localized. > > Interesting - what locale are you using out of interest ? It's pl_PL.UTF-8 > But I think this problem is unrelated. Can you confirm that this passes > with a LANG=en_US.UTF8 set ? are you sure it's locale related ? :-) I have build with pl and de languages and when I set all locale enviroment variables (LANG LC_*) to en_US.UTF-8 the test uses German language with output like: > > Checking an empty cell... > > Query column differences > > Getting: Tabelle1.C4 > > Should have been: Sheet1.C4 > > disposing xSheetDoc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: JUnit sc_complex fails in Localized enviroment
Hey, 2012/2/27 Kohei Yoshida : > On Sat, 2012-02-25 at 17:52 +0100, Maciej Rumianowski wrote: >> > Time: 8,179 >> > There were 2 failures: >> > 1) checkEmptyCell(complex.cellRanges.CheckXCellRangesQuery) >> > java.lang.AssertionError: Query column differences did not return the >> > correct value. >> > at >> > complex.cellRanges.CheckXCellRangesQuery.checkEmptyCell(CheckXCellRangesQuery.java:179) >> > 2) checkFilledCell(complex.cellRanges.CheckXCellRangesQuery) >> > java.lang.AssertionError: Query column differences did not return the >> > correct value. >> > at >> > complex.cellRanges.CheckXCellRangesQuery.checkFilledCell(CheckXCellRangesQuery.java:207) > > I don't run sc_complex, so I don't know what test fails. But this > failure could have been triggered by my recent commit to optionally hide > the to total row(s) and/or column(s) under certain conditions. If > that's the case, and if the test still expects the old behavior, then we > may need to adjust the test code itself to make it pass. > > It would be good to get more details on the failed test itself just to > be sure... This is not related to your work, the failure is a localization problem. > Checking an empty cell... > Query column differences > Getting: Arkusz1.C4 > Should have been: Sheet1.C4 > disposing xSheetDoc > E.creating a Spreadsheet document > Getting spreadsheet > Getting a cell from sheet > Checking a filled cell... > Query column differences > Getting: Arkusz1.C4 > Should have been: Sheet1.C4 Which means that somehow it did not take the en_US locale data for the test. If Stephan does not find time in the near future I will try to have a look at it. Regards, Markus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: JUnit sc_complex fails in Localized enviroment
On Sat, 2012-02-25 at 17:52 +0100, Maciej Rumianowski wrote: > > Time: 8,179 > > There were 2 failures: > > 1) checkEmptyCell(complex.cellRanges.CheckXCellRangesQuery) > > java.lang.AssertionError: Query column differences did not return the > > correct value. > > at > > complex.cellRanges.CheckXCellRangesQuery.checkEmptyCell(CheckXCellRangesQuery.java:179) > > 2) checkFilledCell(complex.cellRanges.CheckXCellRangesQuery) > > java.lang.AssertionError: Query column differences did not return the > > correct value. > > at > > complex.cellRanges.CheckXCellRangesQuery.checkFilledCell(CheckXCellRangesQuery.java:207) > > I don't run sc_complex, so I don't know what test fails. But this failure could have been triggered by my recent commit to optionally hide the to total row(s) and/or column(s) under certain conditions. If that's the case, and if the test still expects the old behavior, then we may need to adjust the test code itself to make it pass. It would be good to get more details on the failed test itself just to be sure... Kohei -- Kohei Yoshida, LibreOffice hacker, Calc ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: JUnit sc_complex fails in Localized enviroment
Hi there, On Sat, 2012-02-25 at 17:52 +0100, Maciej Rumianowski wrote: > I hjave discovered a problem when checking libreoffice build (master), > below is log. It seems that test is not fully localized. Interesting - what locale are you using out of interest ? > Is "make check" meant to work in non-English enviroment? Yes, naturally :-) > I had once such problem with filters_tests in Calc > (http://nabble.documentfoundation.org/calc-filters-test-problem-in-Localized-enviroment-td3382023.html). > I don't know How Michael fixed it. That was fixed by: commit 6f1dbfbe71b57f70fee88c49487436cb1e23ec6f Author: Michael Meeks Date: Fri Sep 30 14:57:15 2011 +0100 set the core locale as well as the UI one to English But I think this problem is unrelated. Can you confirm that this passes with a LANG=en_US.UTF8 set ? are you sure it's locale related ? :-) > > There were 2 failures: > > 1) checkEmptyCell(complex.cellRanges.CheckXCellRangesQuery) > > java.lang.AssertionError: Query column differences did not return the > > correct value. > > at > > complex.cellRanges.CheckXCellRangesQuery.checkEmptyCell(CheckXCellRangesQuery.java:179) > > 2) checkFilledCell(complex.cellRanges.CheckXCellRangesQuery) > > java.lang.AssertionError: Query column differences did not return the > > correct value. > > at > > complex.cellRanges.CheckXCellRangesQuery.checkFilledCell(CheckXCellRangesQuery.java:207) Nasty. So - the JUnit stuff does a lot more heavy lifting, and (no doubt) could more easily hit one of our multiple, duplicate ways of fetching / acting on the translation / environment :-) 'make check' and the JUnit stuff is Stephan's baby really. HTH, Michael. -- michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
JUnit sc_complex fails in Localized enviroment
Hi *, I hjave discovered a problem when checking libreoffice build (master), below is log. It seems that test is not fully localized. Is "make check" meant to work in non-English enviroment? I had once such problem with filters_tests in Calc (http://nabble.documentfoundation.org/calc-filters-test-problem-in-Localized-enviroment-td3382023.html). I don't know How Michael fixed it. Best Regards, Maciej Rumianowski > maciej@maciej-desktop:~/Dokumenty/LibreOffice-Dev/master/sc$ make -sr -j10 > /home/maciej/Dokumenty/LibreOffice-Dev/master/workdir/unxlngi6.pro/JunitTest/sc_complex/done > [ build JUT ] sc_complex > JUnit version 4.8.2 > .creating a Spreadsheet document > Getting spreadsheet > Getting a cell from sheet > Checking an empty cell... > Query column differences > Getting: Arkusz1.C4 > Should have been: Sheet1.C4 > disposing xSheetDoc > E.creating a Spreadsheet document > Getting spreadsheet > Getting a cell from sheet > Checking a filled cell... > Query column differences > Getting: Arkusz1.C4 > Should have been: Sheet1.C4 > disposing xSheetDoc > E > No core dump at > /home/maciej/Dokumenty/LibreOffice-Dev/master/workdir/unxlngi6.pro/JunitTest/sc_complex/user, > to create core dumps (and stack traces) > for crashed soffice instances, enable core dumps with: > >ulimit -c unlimited > > setUpConnection() > .Creating a Spreadsheet document > Getting a sheet > Filling a table > Getting test objects > Insert the DataPilotTable > Starting 'testDataPilotFieldObject' > test for getName() > getting the name "Col1" > ... getName() - OK > testing setName() ... > set the name of object to "Col1X" > check that container has element with this name > getting the name "Col1X" > ... setName() - OK > Checking 'HasSortInfo' > Getting: false > Setting to :true > Checking 'HasAutoShowInfo' > Getting: false > Setting to :true > Checking 'UseSelectedPage' > Getting: false > Setting to :true > Checking 'HasLayoutInfo' > Getting: false > Setting to :true > Checking 'Subtotals' > Getting: [Lcom.sun.star.sheet.GeneralFunction;@1acd47 > Setting to :[Lcom.sun.star.sheet.GeneralFunction;@4f459c > Checking 'LayoutInfo' > Checking 'IsGroupField' > Getting: false > Setting to :true > Checking 'AutoShowInfo' > Checking 'SortInfo' > Checking 'GroupInfo' > Checking 'Orientation' > Checking 'Reference' > Checking 'HasReference' > Getting: false > Setting to :true > Checking 'SelectedPage' > Getting: > Setting to :New > Checking 'Function' > Getting: com.sun.star.sheet.GeneralFunction@1f4cbee > Setting to :com.sun.star.sheet.GeneralFunction@71dc3d > Checking 'ShowEmpty' > Getting: true > Setting to :false > Bound: none > Constrained: none > *** No bound properties found *** > *** No constrained properties found *** > *** No bound properties found *** > *** No constrained properties found *** > disposing xSheetDoc > .Creating a Spreadsheet document > Getting a sheet > Filling a table > Getting test objects > Insert the DataPilotTable > Starting 'testDataPilotTableObject' > test for getName() > getting the name "DataPilotTable" > ... getName() - OK > testing setName() ... > set the name of object to "DataPilotTableX" > check that container has element with this name > getting the name "DataPilotTableX" > ... setName() - OK > getDataPilotFields returned not Null value -- OK > count of returned fields -- OK > Field : 'Col1' ... > Column > Field : 'Col2' ... > Row > Field : 'Col3' ... > Data > Field : 'Col4' ... > Hidden > Field : 'Col5' ... > Page > getColumnFields > Fields returned > Col1 > - OK > getRowFields > Fields returned > Col2 > - OK > getDataFields > Fields returned > Col3 > - OK > getHiddenFields > Fields returned > Col4 > - OK > getPageFields > Fields returned > Col5 > - OK > disposing xSheetDoc > tearDownConnection() > > No core dump at > /home/maciej/Dokumenty/LibreOffice-Dev/master/workdir/unxlngi6.pro/JunitTest/sc_complex/user, > to create core dumps (and stack traces) > for crashed soffice instances, enable core dumps with: > >ulimit -c unlimited > > .creating a sheetdocument > getting sheets > getting a sheet > Property 'IsVisible' OK > old = true > new = false > result = false > Property 'IsVisible' OK > old = false > new = true > result = true > Property 'PageStyle' OK > old = Default > new = Report > result = Report > Property 'PageStyle' OK > old = Report > new = Default > result = Default > Property 'TableLayout' OK > old = 0 > new = 1 > result = 1 > Property 'TableLayout' OK > old = 1 > new = 0 > result = 0 > disposing xSheetDoc > .creating a sheetdocument > getting Drawpages > getting sheets > getting a sheet > Property 'Anchor' OK > old = Cell in Column 0 and Row 0 > new = Cell in Column 5 and Row 5 > result = Cell in Column 5 and Row 5 > Property 'HoriOrientPosition' OK > old = 700 > new = 1000 > result = 1000 > Value for 'VertOrientPosition' hasn't changed as expected > old = 49 > new = 1000 > res
