[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 3.0.4 RC3 (mingw 3.4.5)-2
From: |
Tatsuro MATSUOKA |
Subject: |
Re: 3.0.4 RC3 (mingw 3.4.5)-2 |
Date: |
Thu, 19 Mar 2009 19:28:50 +0900 (JST) |
Hello Benjamin
cc. jwe and Jaroslav
I have checked on mingw and cygwin.
Both tests have been passed well.
src/ov-fcn-handle.cc ................................... PASS 3/3
Thanks!!
Perhaps the below has been fixed.
controldemo fails at the Nyquist demo on octave-3.0.4RC5 (patched for plotting
issue)
http://www.nabble.com/controldemo-fails-at-the-Nyquist-demo-on-octave-3.0.4RC5-(patched-for-plotting-issue)-td22238920.html#a22238920
If my memory is correct, all issues on the octave-3.0.4 have been solved as far
as I know.
I hope that the official release of octave-3.0.4 will be carried out in the
near future.
Regards
Tatsuro
--- Benjamin Lindner wrote:
> >> I applied this patch with some style changes. I also had to remove
> >> this part of the patch:
> >>
> >> | diff -r 97991a9e7a18 -r 1315d5c25fa9 src/ls-oct-ascii.cc
> >> | --- a/src/ls-oct-ascii.cc Tue Mar 03 19:28:03 2009 +0100
> >> | +++ b/src/ls-oct-ascii.cc Tue Mar 03 10:09:56 2009 +0100
> >> | @@ -118,14 +119,15 @@
> >> | }
> >> | | retval = value.str ();
> >> | + skip_until_newline (is, false);
> >> | break;
> >> | }
> >> | else if (next_only)
> >>
> >> Otherwise I saw 6 new failures when running make check. Why was this
> >> line added? Is it needed for systems that have CRLF? If so, why?
> >
> > Without this line, I still get a failure in ov-fcn-handle.cc
> > And I guess the errors Tatsuro reported also base on this.
> >
> > This line is required because the code
> >
> > if (c != '\n' && c != '\r')
> > {
> > value << c;
> > while (is.get (c) && c != '\n' && c != '\r')
> > value << c;
> > }
> >
> > retval = value.str ();
> > break;
> >
> > leaves a stray '\n' in the input stream if line endings are CRLF, since
> > the while () loop breaks at the first '\r' and the following '\n' is not
> > removed.
> >
> > OK, I'll think of a workaround
> >
> > benjamin
> >
>
> Let's see, lap #1.
> Could you check with the attached changeset?
> This should now be a more consistent behaviour for LF and CRLF files (I
> hope at least)
>
> benjamin
> > # HG changeset patch
> # User Benjamin Lindner <address@hidden>
> # Date 1237386194 -3600
> # Node ID f3f7455b4e899dca75cc96600bf81db91cf7a1cc
> # Parent 5ffdac7a97eeebb307b67d597078f88136d72426
> fix leaving stray '\r' in stream when reading from CRLF data file
>
> diff -r 5ffdac7a97ee -r f3f7455b4e89 src/ChangeLog
> --- a/src/ChangeLog Wed Mar 18 15:23:14 2009 +0100
> +++ b/src/ChangeLog Wed Mar 18 15:23:14 2009 +0100
> @@ -1,3 +1,9 @@
> +2009-03-18 Benjamin Lindner <address@hidden>
> +
> + * ls-oct-ascii.cc (extract_keyword): fix leaving stray '\r' in stream
> + when reading from CRLF data file by replacing loop with call to
> + read_until_newline()
> +
> 2009-03-18 Benjamin Lindner <address@hidden>
>
> * ov-base-int.cc (load_ascii): Attempt to read data from file only
> diff -r 5ffdac7a97ee -r f3f7455b4e89 src/ls-oct-ascii.cc
> --- a/src/ls-oct-ascii.cc Wed Mar 18 15:23:14 2009 +0100
> +++ b/src/ls-oct-ascii.cc Wed Mar 18 15:23:14 2009 +0100
> @@ -110,14 +110,8 @@
> while (is.get (c) && (c == ' ' || c == '\t' || c == ':'))
> ; // Skip whitespace and the colon.
>
> - if (c != '\n' && c != '\r')
> - {
> - value << c;
> - while (is.get (c) && c != '\n' && c != '\r')
> - value << c;
> - }
> -
> - retval = value.str ();
> + is.putback(c);
> + retval = read_until_newline (is, false);
> break;
> }
> else if (next_only)
>
--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/
- Re: 3.0.4 RC3 (mingw 3.4.5)-2, (continued)
- Re: 3.0.4 RC3 (mingw 3.4.5)-2, Tatsuro MATSUOKA, 2009/03/05
- Re: 3.0.4 RC3 (mingw 3.4.5)-2, Tatsuro MATSUOKA, 2009/03/05
- Re: 3.0.4 RC3 (mingw 3.4.5)-2, Benjamin Lindner, 2009/03/08
- Re: 3.0.4 RC3 (mingw 3.4.5)-2, Tatsuro MATSUOKA, 2009/03/09
- Re: 3.0.4 RC3 (mingw 3.4.5)-2, Tatsuro MATSUOKA, 2009/03/09
Re: 3.0.4 RC3 (mingw 3.4.5)-2, John W. Eaton, 2009/03/10