Wed 22 Jun 2016 09:07:14 PM UTC, comment #12:
Everything works now on both Windows and Linux.
I located another two instances in load-save.cc where the ifstream should be opened in binary mode. The full cset is here http://hg.savannah.gnu.org/hgweb/octave/rev/d31e0f704d0b.
|
Wed 22 Jun 2016 06:21:12 PM UTC, comment #11:
@JohnD: Thanks for the patch. I was just working through the code with the same idea in mind, that we were accidentally opening the file in text mode rather than binary mode. I'll run through the whole loop with mxe-octave so it will be several hours before I can verify the patch.
|
Wed 22 Jun 2016 06:08:54 PM UTC, comment #10:
If I change:
looks_like_mat_ascii_file fails like it does in Linux and doesn't attempt to load the data as a mat file.
|
Wed 22 Jun 2016 05:20:18 PM UTC, comment #9:
<<It seems that the original programmer knew this wasn't a great idea.>>
That would probably be me...
<<I wonder if it is possible to go back to the beginning and open the file in text mode and let the C++ standard libraries deal with the different endings (CR, LF, CRLF).>>
I think the problem with that is that you then limit yourself to the native system line endings, so on a Unixy system, you'll only recognize LF, not CR or CRLF and on a Windows system you'll only recgnize CRLF, not CR or LF.
That would be fine if text files were converted when transferred from one system type to another, but that doesn't always happen.
|
Wed 22 Jun 2016 04:58:18 PM UTC, comment #8:
@Avinoam: To build a debug version with MXE, run the configure script in the MXE directory with the additional options of
@JohnD: Thanks for testing. In load-save.cc I see the following code:
It seems that the original programmer knew this wasn't a great idea.
The code for looks_like_mat_ascii_file is buried in libinterp/corefcn/ls-mat-ascii.cc. Sure enough, there is code checking for '\n' and '\r'. This isn't very portable. I wonder if it is possible to go back to the beginning and open the file in text mode and let the C++ standard libraries deal with the different endings (CR, LF, CRLF).
|
Wed 22 Jun 2016 04:30:30 PM UTC, comment #7:
Since it works in Linux, but not windows, whats the chances it is an issue with binary vs text mode ?
|
Wed 22 Jun 2016 04:13:36 PM UTC, comment #6:
I put some prints in the file and ran it - the call to looks_like_mat_ascii_file returns true on mine.
|
Tue 21 Jun 2016 08:44:37 PM UTC, comment #5:
How do I build a version of MXE-octave that keeps the debugging symbols?
I can add printout for the output of is_octave_data_file.
|
Tue 21 Jun 2016 03:35:25 PM UTC, comment #4:
This shouldn't be that hard to debug. If possible, can you build a version of MXE-octave that keeps the debugging symbols?
The function is_octave_data_file is in load-save.cc, and it really just calls out to two different instances of get_file_format with different function signatures. I would just walk through the code under gdb. It might be is_hdf5 returns true for some reason, or that our code for detecting Matlab binary files mistakes this.
|
Thu 16 Jun 2016 01:31:03 AM UTC, comment #3:
The problem (reported on bug #45844, but not yet repeated here) seems to be that is_octave_data_file() seems to be returning true for (some? all?) PNG files on Windows. Octave is trying to be smart here and look at the file content rather than the file name, which is IMHO the right thing to do.
Any idea what file format Octave thinks this PNG is or why? Can we first identify what the problem is and how universal it is?
|
Mon 13 Jun 2016 04:51:29 AM UTC, comment #2:
Yes, "open a.png" opens a.png in external viewer.
|
Mon 13 Jun 2016 04:21:55 AM UTC, comment #1:
Does the open() command work on the png file?
|
Sat 11 Jun 2016 10:22:02 AM UTC, original submission:
This bug report is related to bug #45844
In this bug fix, double click in file explorer open files with default app by default.
Checking this in Win-7, it works with pdf ps and jpg files, but not in png. I get the error:
It seems that Octave is trying to load the png files, and not open it in default app.
|