[Octave-bug-tracker] [bug #59273] [octave forge] (io) can't reliably load XLSX files in release 2.6.2

[Philip Nienhuis]

Follow-up Comment #12, bug #59273 (project octave):

Thanks for the re-trials.

TBH it's unclear to me what is happening in the debian test suite. Apparently
a new pristine test environment gets built and then some test are run for
which I can't infer how the functions in the io package are invoked (no
command lines with input parameters).
I do see the detected interfaces and they make sense to me, give the
javaclasspath you gave in comment #4.

What is lacking in the logs is the output of line like eg., L. 341-343 in
xlopen:

    if (verbose)
      printf ("Invoking POI ...\n");
    endif


In the example you gave in comment #0:

octave:3> cd ~/debian/octave-io/debian/tests/
octave:4> xlsfinfo('test.xlsx', [], true)


'verbose' = true so I expected some output. But I suppose that the tests suite
doesn't specify it.
Maybe variable 'verbose' has to be set explicitly to true (or 1) somewhere at
the top of xlsopen.

Other than that I'm at loss what is happening here.
It all works fine on my boxes (Windows 10 and Mageia 7). Those may not be
representative and as you wrote io-3.6.1 did work fine (but I believe for the
wrong reason - I do suspect that maybe behind your back OCT got involved
rather than 'POI & OOXML').

(just a hunch) Does the JVM have enough memory allocated? maybe POI (needing a
lot of resources) chokes already at file open time.

(Another hunch) POI has been messing with the WorkbookFactory classes; maybe
in  private/__POI_spsh_open__.m  the call to ..workbookFactory0

        wb = javaMethod ("create", ...
                         "org.apache.poi.ss.usermodel.WorkbookFactory0",...
                         xlsin);


should have a trailing 1 rather than 0, or maybe the version comparison works
out incorrectly and the if block is in error (and only the upper stanza needs
to remain).

Perhaps you can try with older POI versions ( 4.0).

I'll try to search further. I have little time this week though ...


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59273>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/