[BUG] Linux runs do not generate .ods results file
XenonPK opened this issue · comments
The files are in this attachment, this is the same file referred in #9.
This was used to parse the ezfio output csv files one by one, in order to generate the .ods files found in the linux dir within the first attachment.
The runs were executed in an ubuntu server 16.04 install , with the following arguments:
/usr/bin/python $HOME/script/.fio/ezfio.py -d /dev/sdb -o $OUT_DIR --yes
Would you have the STDOUT/STDERR logs from a Linux run that doesn't make the ODS file? A quick check shows the CSV files that go into making it are in good shape (ex: ezfio_tests_34GB_4cores_3400MHz_sdb_ubuntunfs_2016-12-18_19-26-55.csv, ezfio_timeseries_34GB_4cores_3400MHz_sdb_ubuntunfs_2016-12-18_19-26-55.csv)
Best guess is the original.ods file is not being found by the Linux script. Could have something to do with running the test where $CWD != where the ezfio.py script is located.
Best guess is we need something like this around line 317...
'- odssrc = os.getcwd() + "/original.ods"
'+ odssrc = os.path.realpath(file) + "/original.ods"
Yup, that was the problem. I've pushed a new version with a simple fix after testing that things like "python ezfio/ezfio.py ..." works (i.e. invoking from a different directory).
Can you pull the latest main branch and try and close if it's fixed for you?
I will test it tomorrow, thanks for the quick reply. About the stderr logs, I had them, but since then, the machine was formatted, and I only kept the results.
By the way, assuming it works, would the linux version be affected by the same problem reported in #9 ? Running the script with LC_ALL=C should fix it right? I will test with the system defaults first and see if it reproduces on linux.
Good question. If both fio.bin and python agree on the locale and use the standard library it should "just work" without any problem. The Windows issue is most likely related to the WIX porting library so there's another layer of indirection there to go weird.
I'm a little worried about the locale of the actual generated ODS file in either case, though. May need overrides in floating-point formatting to go culture-invariant or something to make LibreOffice grok "1.234" or "1,234" appropriately.
So, the first execution with the default system locale showed the same results as before (no .ods file was generated)
I'm traveling this week so can't check it myself, but is this related to the Linux or Windows issue? For Linux the ODS generation vs. locale is pretty much a don't care so I don't understand the behaviour you're reporting. Did you try the master/HEAD or the windowsfix/HEAD? You want the master/main branch for the Linux fix since I pushed it after I was able to test and see both a fail before and a pass after the 1-line change.
Basically the problem under Linux was you were running outside of the location of the ezfio script, so when it tried to open "$CWD/original.ods" it wasn't there (it was in the directory of the file (there should be 2 underscores around file, but Github seems to turn them into BOLD always here). So that I was able to test and reproduce both your failure and see the fix running.
Haven't heard back and I was able to reproduce the failure (as far as I understand it) and make it work with the patch so closing. If this pops up again, please re-open or make a new one and capture as much STDOUT/STDERR and the full directory as a tarball, please.