octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #41579] textscan: file offset after partial re


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #41579] textscan: file offset after partial read differs from Matlab
Date: Tue, 24 Oct 2017 13:16:22 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #13, bug #41579 (project octave):

OK, thanks.  The take-away from these two examples is that ML does not
consider EOLs to be delimiters.  (If there is one historical rule I've noticed
about ML is that they go for simplicity of code and let idiosyncrasies be what
they are.)

However, EOLs are considered delimiters for Octave, and it looks like they are
also considered white-spaces.  That's a significant deviation from ML.  Octave
has gone to great lengths to nuance the treatment of EOLs, so much so that I'm
wondering what the developer had in mind and whether ML-compatibility was even
a concern.

I'm attaching a diff file in which I've basically gutted the skip_delim()
routine and the behavior is the same as the original example for ML.  No need
to test this, it should be clear that basically I've removed all EOL
treatment.  However, I did have to remove this line too:


//    int c1 = skip_whitespace (is, true);  // 'true': stop once EOL is read


which generally speaking is probably too much (but the test.txt file given is
nice an clean as far as extraneous white space)--but again, I think there too
the EOL is considered whitespace when it shouldn't be.

I think the design "flaw" (if one wants to call it that) is intermingling EOL
treatment with the delimiter treatment and the whitespace treatment.  Instead,
it would probably make more sense to be more OOP-mindful and pull out the EOL
code and place it into its own "skip_eol()" method.  Then we can strategically
place

skip_whitespace()
skip_eol()
skip_delim()

in various locations and various combinations to match ML behavior.  That's
shaking the tree a bit, but hopefully the greater granularity makes the code
easier to debug.

Do we want to go that route?

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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