Fri 28 Aug 2015 03:53:16 PM UTC, comment #13:
Jordi: Open another bug report about the way strings are displayed (assuming there is not already a report about that). Maybe we should display them as "foo" or 'foo' (depending on whether they are double- or single-quoted strings.
|
Thu 27 Aug 2015 11:27:41 PM UTC, comment #12:
@Rick: It is working now, thanks! I hadn't run "hg update", just "hg pull" (I'm more used to git), so it wasn't applying the last changes. Sorry for the noise, and thank you and John for the fix!
|
Thu 27 Aug 2015 09:54:56 PM UTC, comment #11:
@Jordi: Did you run 'hg update' to get to the latest changeset? Also try running 'run-octave -f' so that no initialization files get read. It's possible there is something in your specific configuration. Otherwise, yes, the example m-file and text file ran fine for me with the patched Octave.
|
Thu 27 Aug 2015 09:17:13 PM UTC, comment #10:
Hi,
Thanks for looking into it and the fix. Does it really pass the original example for you? I just tried it and still find the same result:
ans = 1
ans = y
(By the way, I find it confusing that strings are not quoted now, but that's a different story.)
I've got the repository updated until this log:
changeset: 20465:44eb1102f8a8
bookmark: @
tag: tip
user: John W. Eaton <jwe@octave.org>
date: Wed Aug 26 16:05:49 2015 -0400
summary: don't recycle scanf format string if all conversions are done (bug #45808)
and I compiled it in debian sid, without any octave package installed and with a recent version of the repository (until the commit mentioned above), and just to be sure I "make clean" and "make distclean"-ed before compiling again.
|
Thu 27 Aug 2015 04:32:59 PM UTC, comment #9:
Passes all of the test suite now as well as the example in this bug report. Marking as Fixed and closing report.
|
Thu 27 Aug 2015 03:30:44 PM UTC, comment #8:
I pushed the following modified version of the change I proposed earlier. The io tests all succeed for me now.
http://hg.savannah.gnu.org/hgweb/octave/rev/44eb1102f8a8
|
Wed 26 Aug 2015 10:07:13 PM UTC, comment #7:
Running 'make check' with the patch applied produces 12 failures, so the patch seems to have some side effects. The output from fntests.log is shown below.
|
Wed 26 Aug 2015 09:02:25 PM UTC, comment #6:
The patch works for me. I think you can go ahead and push it to Mercurial.
|
Wed 26 Aug 2015 08:08:22 PM UTC, comment #5:
I think the attached patch fixes the problem. There was already some logic to handle not recycling through the list but it didn't correctly handle the case of literal or whitespace conversions at the beginning and end of a format with a limited number of conversions.
(file #34748)
|
Wed 26 Aug 2015 05:42:35 PM UTC, comment #4:
I went back to first principles and assume that fscanf should behave as the low-level C function.
I've attached a simple example, fscanf.c, and an accompanying data file, fscanf.txt. Use 'gcc fscanf.c' to compile and then run a.out.
The newline character is counted as whitespace and eats as much as possible. In the example file I have a line following the first that is just made of of spaces, a tab, and a completing newline. All of it gets eaten by fscanf. So the Matlab result is correct.
At least at the C level, I checked and it seems that a partially failing template still eats whitespace following the last successfuly read parameter.
(file #34740, file #34741)
|
Wed 26 Aug 2015 04:37:58 PM UTC, comment #3:
I don't think the problem is really with newlines. It's that a limit on the number of requested values is specified but Octave is cycling through the format string again. So it skips the whitespace (newline) and then the ";" on the second line of the file matches the beginning of the format string but there is a failure to read the "y" with "%d". Only when that format element fails to match does it return and move on to the next call to fscanf.
So I think the solution is to not recycle a format string if a fixed limit on the number of requested values is supplied. But I'm not sure of exactly what is supposed to happen. For example, does
stop reading immediately after the first "%d" conversion, or does it also grab any literal text and whitespace following that conversion? What about something like
Does the limit apply immediately to values read or does it also process the second (skipped) number?
I don't quite understand the rules yet.
|
Wed 26 Aug 2015 06:46:58 AM UTC, comment #2:
Thanks for the input. That would work for this particular example, but I'm finding the problem as part of a larger script that parses a more-or-less complex text file. I've tried several changes, including your suggestion, and it breaks the parsing later on, one way or another, in a non-trivial way.
The fact is that matlab can easily parse those files, and I've given up for the moment trying to have octave parse them too with the same code, because it got so complicated.
In any case, octave is behaving different than matlab there, so it can be fixed. Unfortunately I don't know about a workaround that worked for me, but I can wait until it's fixed in octave.
|
Tue 25 Aug 2015 04:04:29 AM UTC, comment #1:
Confirmed. There does seem to be an issue with newlines in the format string and this was on a Linux platform.
Could you try the attached workaround? It simply removes the newline from the format string. I believe both Matlab and Octave will reset their internal positioning counter at the end of each line and this should work on both platforms.
(file #34718)
|
Fri 21 Aug 2015 11:48:51 PM UTC, original submission:
When there is a newline ('\n') in the format string for fscanf, it seems that further calls to fscanf don't read from where it is supposed to.
For example, running the attached program produces:
In matlab:
ans = 1
ans = ';'
In octave:
ans = 1
ans = 'y'
I have tried it in windows, but may be present in other systems too.
|