[Octave-bug-tracker] [bug #52892] textread incorrectly reads a text file when empty lines are present

[Dan Sebald]

Follow-up Comment #8, bug #52892 (project octave):

I'm using the latest development code, so there's a good chance behavior is
different.  These file-reading routines have seen a lot of bug-fixes over the
years.

There is no IDE that is recommended or supported by development.  (The GUI
layout can work with qtcreator, I think, but that's about it.)

There are some suggestions for developers and creating patches/changesets
here:

https://octave.sourceforge.io/developers.php

Basically, useful tools are grep and some type of Mercurial source control
viewer such as "thg".  That just makes it convenient to look at changesets. 
The online Mercurial interface is OK, but not fast.  To become familiar with
code and where it resides in th source tree I suggest using thg and then type
"textread", or "textscan" is a another related file that I know has had some
changesets recently.  thg will then give a list of changeset that you may look
at to see just the changes, and also the names of the files and full/relative
directory path so that you may quickly locate where some of these routines
are.  For example, here's a recent change I made regarding the EOL behavior
for textscan:

http://hg.savannah.gnu.org/hgweb/octave/rev/f77da8da0f3f

When you think you've got something useful, commit your changes either from
the command line or from thg (which is convenient).  Use the changeset message
format that is commonly used in all the other changesets.  Once committed, do
something like

hg export tip > my_spiffy_changeset-abc2018jan17.patch

where abc is initials.  That's just the naming convention I use for my
organizational purpose because often I will create multiple revs over the
course of a few days, but any file naming convention is suitable.  The
extensions "patch" and "diff" are good because the file extension often is a
signal for people's editors (e.g., gvim) about the format and automatic
highlighting will be used.

Include a bug report number in the first line of the changeset message, if
appropriate.  Try to make the changesets atomic in the sense of only one
conceptual change per changeset.  E.g., don't address file reading and
plotting images with the same changeset.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52892>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/