[Top][All Lists]

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

[Octave-bug-tracker] [bug #49454] strread commentstyle doesn't work as e

From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #49454] strread commentstyle doesn't work as expected
Date: Thu, 27 Oct 2016 20:44:47 +0000 (UTC)
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40

Follow-up Comment #4, bug #49454 (project octave):

Yeah it's quite a while since I fiddled with strread.m / textread.m /

Some observations:
The plan was (is?) to make strread.m a front end for textscan(); it used to be
the other way round until ~a year ago.

strread.m in Matlab is not deprecated but it is recommended to rather use
textscan. (In the Matlab docs the stanza that strread "will be removed in a
future version of Matlab" has disappeared; so I conclude that deprecation
_sensu stricto_ is not planned.)

I made a start with converting strread.m a year ago after Lachlan created the
binary txtscan() but ran in several issues. As textscan is a better
alternative, also recommended by Matlab, I wonder how much energy we should
put into keeping strread.m up-to-date anyway.
AFAIK TMW doesn't do much about it either. For example, about a year ago I
entered a bug report about the default emptyvalue (then documented to be NaN,
but Matlab's strread returned 0 (zero)); TMW simply changed the docs rather
than fix strread.

As to the comment processing: 
IIRC that part has been provided by Rik. He probably doesn't remember :-)

In Matlab strread.m has no option "endofline". I've put it into the Octave
version at the time as strread.m is/was the backend for textread and textscan
that do have that option. It was much more convenient to handle endofline
*processing* in strread.m.  *Assessment* of the "endofline" value is/was done
in textread.m and textscan.m

I think we should not use the "endofline" value but silently assume a LF or
CRLF during comment processing; to be overridden when "endofline" has been
specified by the user. The motive is that (IIRC) strread.m's default endofline
value is empty for a reason (that I do not have at hand right now).

Unlike strread, textscan returns all output from interpreting string/file
contents into one cell array so I think the output in comment #2 is correct.
The word boundary thing can be checked in Matlab.

Until after next November I have very little time/priority to fix strread.m.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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