Fri 28 Nov 2014 02:55:46 PM UTC, comment #10:
The corruption was caused as a side effect of a bug in xlswrite that must have been there for a looong time. I rarely if ever use xlswrite myself so I didn't hit it. The issue occurs if an empty string is supplied for the sheet name, as we did in specifying the OCT interface.
Could you please try (with untouched io-2.2.5):
xlswrite ("dummy.xlsx", ones(10))
and see if the OCT interface has been selected and if the resulting file is clean?
For a bug fix, grab xlswrite.m from the repo:
http://sourceforge.net/p/octave/io/ci/default/tree/inst/
I'm closing this report as "invalid" as a compiler mix-up was the original issue. But please report back anyway about xlswrite's behavior (see above).
Thanks for reporting and helping me
|
Fri 28 Nov 2014 07:23:24 AM UTC, comment #9:
Nice.
Ok I'll have a look at the corruption - I thought I fixed that a while ago.
|
Thu 27 Nov 2014 07:23:23 PM UTC, comment #8:
Okey, I removed all but one version. io-2.5.2 did install fine!!!
xlswrite ("dummy.xlsx", ones(10), "", "", "OCT") is successfully executed, but the excel file is corrupt und excel repairs it on opening - just like on your system I imagine.
Thanks for your advice. At least at the end it was not completely useless...
|
Thu 27 Nov 2014 06:47:39 PM UTC, comment #7:
Well, maybe it is compiler problem after all. I do have several ones on my system...
I also have 2 octave versions ...
I will try to make one clean install to make sure everything is done with the correct compiler and than report back.
|
Thu 27 Nov 2014 06:21:39 PM UTC, comment #6:
Only now I see the issue (I'm not very alert or awake ATM):
You did:
xlswrite ("dummy.xlsx",ones(10),"OCT")
but to invoke the OCT interface you should have entered:
xlswrite ("dummy.xlsx", ones(10), "", "", "OCT")
See help xlswrite for xlswrite's syntax.
Both work for me w/o Windows package loaded, the latter also with loaded Windows pkg.
However, I do see that Excel2013 isn't content with the file contents (no pun intended) made by OCT. Hmmm.
So your "sub-bug" is invalid, but I'll leave the Mac OSX one open.
What OSX version do you use? What gcc version is present on your system? (I wouldn't know how to uncover that, I'm an OSX n00b)
What gcc version does Octave report?
octave_config_info.CC_VERSION
octave_config_info.CXX_VERSION
octave_config_info.GCC_VERSION
octave_config_info.GXX_VERSION
<title adapted>
|
Thu 27 Nov 2014 06:06:14 PM UTC, comment #5:
Hmm.... on my Windows box, I get:
which shouldn't happen as OCT should be the only interface left.
I have some 15 minutes left now for a first look - otherwise it'll be next weekend.
|
Thu 27 Nov 2014 05:12:43 PM UTC, comment #4:
calccelladdress (1, 2) works fine:
ans = B1
|
Thu 27 Nov 2014 05:08:52 PM UTC, comment #3:
I wouldn't know, sorry.
io-2.2.5 uses two compiled .oct files to manipulate cell addresses, "num2col" and "col2num". My guess is those functions suffer from the same pickyness of your compiler.
Try:
calccelladdress (1, 2)
and see what happens. You can even try to step through it (debug mode) by setting a breakpoint in L. 41 (click to the left of the line number in the Octave editor) and then click the leftmost blue button or press <F10>).
If it crashes in L. 50 it is indeed the binary modules that seem to have been miscompiled.
BTW 'pickyness": on my boxes (Linux Mageia 4 & Windows 7 Professional & Enterprise) it works fine. So while it may be that your compiler on OSX is essentially correct, I see no reason for it to be so very alarmed.
Does "mkoctfile" (the function that is invoked by pkg.m command to compile the binary modules) pick up the right C++ compiler version? Maybe there's a mismatch between C++ compilers on your box (i.e., the one Octave was built with and the one installed on your box).
Mind you, I know virtually nothing about developing on OSX.
|
Thu 27 Nov 2014 04:48:44 PM UTC, comment #2:
Meanwhile I installed octave 3.8.1 with home-brew. I was able to install io-2.2.5, but it makes octave crash when using it.
Any ideas?
|
Thu 27 Nov 2014 04:39:14 PM UTC, comment #1:
Transplanting the entire share/octave/m/packages/io subdir should do.
AFAICS it is C++ code that provokes the error, esp. in xml* source code. There's nothing I can do about the xml c++ files, I don't maintain them, I just package them with the rest of the io package.
As far as the csv2cell warnings go, I don't follow; AFAICS it is valid code.
Perhaps your compiler is extremely picky.
|
Thu 27 Nov 2014 08:55:48 AM UTC, original submission:
OS X version 10.9.5
Is there a way to work around this quickly? I would really like to use the bugfixes and i-2.2.4 installs fine. Which files would I have to copy from 2.2.4 to 2.2.5?
Please check the output:
|