[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 3.0.4 RC3 (mingw 3.4.5)-2

From: Benjamin Lindner
Subject: Re: 3.0.4 RC3 (mingw 3.4.5)-2
Date: Tue, 17 Mar 2009 20:28:33 +0100
User-agent: Thunderbird (Windows/20081105)

John W. Eaton wrote:
On  3-Mar-2009, Benjamin Lindner wrote:

| John W. Eaton wrote:
| > On 30-Jan-2009, Benjamin Lindner wrote:
| > | > | To work around it in octave we need to rethink octave's way to save | > | anonymous function handles in ascii format. | > | I have tried something for in the development branch, which allows this | > | test to pass, but it means a small but significant change in the format | > | of saving anonymous function handles. This breaks backwards | > | compatibility, so I'm not really happy about my approach. | > | > We can open text files for reading in binary mode. It just means that
| > we have to handle the CRLF, CR, and LF line endings ourselves.  We
| > already do that (more or less) for .m files.  But it would maybe be a
| > good idea to come up with a unified way of doing it for all of Octave.
| > | | I have put some thought into this problem and have changed the behaviour | of reading ascii mode data by doing the following | *) files get always opened in binary mode when loading data (saving to | ascii is still done in text mode) | *) walked through the load_ascii( ) method of the various octave_value | derived classes and moved all newline/cr/lf related code into common | functions | *) created ls-ascii-helper.h and ls-ascii-helper.cc and stored the | common functions there | | With this, I get rid of the failing test in ov-fcn-handle.cc on mingw. I | have no additional failed tests. Saving and loading in "-text" format | seems to work, I have not encountered problems yet. | | I don't have access to matlab, so I could not check what happens with | data files in matlab's text format. I'd appreciate cross-checks.

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 ();

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]