|
»
»
« Return to Thread: Possible bug in "load" function in octave 3.0.4
Re: Possible bug in "load" function in octave 3.0.4
by Benjamin Lindner
::
Rate this Message:
Jaroslav Hajek wrote:
> On Sun, Apr 5, 2009 at 5:56 PM, Benjamin Lindner <lindnerben@...> wrote:
>> Jaroslav Hajek wrote:
>>> On Sun, Apr 5, 2009 at 12:01 PM, Massimiliano Culpo
>>> <misticoannoiato@...> wrote:
>>>> Please find attached a possible bug occurring in octave 3.0.4.
>>>>
>>>> Regards,
>>>> Massimiliano Culpo
>>>>
>>>> _______________________________________________
>>>> Bug-octave mailing list
>>>> Bug-octave@...
>>>> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>>>>
>>>>
>>> Confirmed; this is quite blatant. Too bad there was no test for ASCII
>>> loading :(
>>> It appears that the changeset fixing CRLF issues on MinGW/Cygwin
>>> http://hg.tw-math.de/release-3-0-x/rev/34b75a47e712
>>> broke things up. Is anyone interested in fixing this in 3.0.x series?
>>> (the simplest fix is of course to just revert the broken patch)
>>> Does not exist in 3.1.5x.
>> Oh shit (sorry for that).
>> Well, since I introduced it, I'll try to see to a fix. I think it should be
>> fixed in 3.0.x
>>
>> Strange that it does not exist in 3.1.x. Has the save/load code been changed
>> from 3.0 -> 3.1 ?
>>
>> benjamin
>>
>>
>
> Hmmm. Correct me if I'm wrong, but I think your patch was originally
> for 3.1.x. It was (IIRC) Tatsuro who backported ported it for 3.0.x.
> So maybe Tatsuro can comment whether he had made any non-trivial
> modifications. If not, then probably this is an unexpected interaction
> between some changed parts.
> Anyway, I think there were numerous changes to the load/save code
> since 3.0 (as well as most other parts of Octave).
> I also think that this shows that 15 months since the 3.0 fork is
> really too much.
>Yep, but I did some backporting on this patch. Then the patch for 3.1.x
was also updated because it was buggy. Anyway, since this bug is not
found in 3.1.x I did a comparison of the ascii loading code and found
the problem.
get_mat_data_input_line() in ls-mat-ascii.cc was eating a whole line
when it should have only read a newline.
This is done correctly in 3.1.x, the attached changeset aligns the 3.0.x
code properly.
I get now
B=load("t:\\msh_p2.txt");
size(B)
ans =
192 2
benjamin
# HG changeset patch
# User Benjamin Lindner <lindnerb@...>
# Date 1238948977 -7200
# Node ID 7064e7eebb0abd101a7ae1337e8f9bd14680ca2e
# Parent ffb20e8faf5bfaff8cc6c22521c4a8fd36b2dcfb
fix broken ascii loading
diff -r ffb20e8faf5b -r 7064e7eebb0a src/ChangeLog
--- a/src/ChangeLog Sun Apr 05 18:05:33 2009 +0200
+++ b/src/ChangeLog Sun Apr 05 18:29:37 2009 +0200
@@ -1,3 +1,9 @@
+2009-04-05 Benjamin Lindner <lindnerb@...>
+
+ * ls-mat-ascii.cc (get_mat_data_input_line): fix eating a whole
+ line when only newline should be read. fixes broken ascii matrix
+ loading
+
2009-03-18 Benjamin Lindner <lindnerb@...>
* ls-oct-ascii.cc (extract_keyword): fix leaving stray '\r' in stream
diff -r ffb20e8faf5b -r 7064e7eebb0a src/ls-mat-ascii.cc
--- a/src/ls-mat-ascii.cc Sun Apr 05 18:05:33 2009 +0200
+++ b/src/ls-mat-ascii.cc Sun Apr 05 18:29:37 2009 +0200
@@ -84,7 +84,8 @@
if (c == '\n' || c == '\r')
{
// Let skip_until_newline handle CR/LF issues...
- skip_until_newline (is, false);
+ is.putback (c);
+ skip_preceeding_newline (is);
break;
}
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
> On Sun, Apr 5, 2009 at 5:56 PM, Benjamin Lindner <lindnerben@...> wrote:
>> Jaroslav Hajek wrote:
>>> On Sun, Apr 5, 2009 at 12:01 PM, Massimiliano Culpo
>>> <misticoannoiato@...> wrote:
>>>> Please find attached a possible bug occurring in octave 3.0.4.
>>>>
>>>> Regards,
>>>> Massimiliano Culpo
>>>>
>>>> _______________________________________________
>>>> Bug-octave mailing list
>>>> Bug-octave@...
>>>> https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
>>>>
>>>>
>>> Confirmed; this is quite blatant. Too bad there was no test for ASCII
>>> loading :(
>>> It appears that the changeset fixing CRLF issues on MinGW/Cygwin
>>> http://hg.tw-math.de/release-3-0-x/rev/34b75a47e712
>>> broke things up. Is anyone interested in fixing this in 3.0.x series?
>>> (the simplest fix is of course to just revert the broken patch)
>>> Does not exist in 3.1.5x.
>> Oh shit (sorry for that).
>> Well, since I introduced it, I'll try to see to a fix. I think it should be
>> fixed in 3.0.x
>>
>> Strange that it does not exist in 3.1.x. Has the save/load code been changed
>> from 3.0 -> 3.1 ?
>>
>> benjamin
>>
>>
>
> Hmmm. Correct me if I'm wrong, but I think your patch was originally
> for 3.1.x. It was (IIRC) Tatsuro who backported ported it for 3.0.x.
> So maybe Tatsuro can comment whether he had made any non-trivial
> modifications. If not, then probably this is an unexpected interaction
> between some changed parts.
> Anyway, I think there were numerous changes to the load/save code
> since 3.0 (as well as most other parts of Octave).
> I also think that this shows that 15 months since the 3.0 fork is
> really too much.
>
was also updated because it was buggy. Anyway, since this bug is not
found in 3.1.x I did a comparison of the ascii loading code and found
the problem.
get_mat_data_input_line() in ls-mat-ascii.cc was eating a whole line
when it should have only read a newline.
This is done correctly in 3.1.x, the attached changeset aligns the 3.0.x
code properly.
I get now
B=load("t:\\msh_p2.txt");
size(B)
ans =
192 2
benjamin
# HG changeset patch
# User Benjamin Lindner <lindnerb@...>
# Date 1238948977 -7200
# Node ID 7064e7eebb0abd101a7ae1337e8f9bd14680ca2e
# Parent ffb20e8faf5bfaff8cc6c22521c4a8fd36b2dcfb
fix broken ascii loading
diff -r ffb20e8faf5b -r 7064e7eebb0a src/ChangeLog
--- a/src/ChangeLog Sun Apr 05 18:05:33 2009 +0200
+++ b/src/ChangeLog Sun Apr 05 18:29:37 2009 +0200
@@ -1,3 +1,9 @@
+2009-04-05 Benjamin Lindner <lindnerb@...>
+
+ * ls-mat-ascii.cc (get_mat_data_input_line): fix eating a whole
+ line when only newline should be read. fixes broken ascii matrix
+ loading
+
2009-03-18 Benjamin Lindner <lindnerb@...>
* ls-oct-ascii.cc (extract_keyword): fix leaving stray '\r' in stream
diff -r ffb20e8faf5b -r 7064e7eebb0a src/ls-mat-ascii.cc
--- a/src/ls-mat-ascii.cc Sun Apr 05 18:05:33 2009 +0200
+++ b/src/ls-mat-ascii.cc Sun Apr 05 18:29:37 2009 +0200
@@ -84,7 +84,8 @@
if (c == '\n' || c == '\r')
{
// Let skip_until_newline handle CR/LF issues...
- skip_until_newline (is, false);
+ is.putback (c);
+ skip_preceeding_newline (is);
break;
}
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/bug-octave
« Return to Thread: Possible bug in "load" function in octave 3.0.4
| Free embeddable forum powered by Nabble | Forum Help |
