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

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

[Octave-patch-tracker] [patch #8783] C++ implementation of textscan


From: Philip Nienhuis
Subject: [Octave-patch-tracker] [patch #8783] C++ implementation of textscan
Date: Fri, 12 Feb 2016 09:46:15 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38

Follow-up Comment #44, patch #8783 (project octave):

@JWE:
Yes any help is welcome, thanks.
Currently we have two things to sort out:

1. does it work well on other platforms than Linux and Windows? (e.g., OSX) ?

2. if textscan.cc is to be used as a backend for strread.m, we have to do
something with absence/presence of a trailing EOL in text files / text
strings, as strread.m uses that to decide if output arrays should be padded to
equal length. Similarly for textread.m, I think.
Maybe textscan.cc needs an undocumented flag so that it knows it was called
from strread.m and needs to adapt its behavior.
Once there, strread.m and textread.m have to be overhauled. I'd happily take
that up. That can be done somewhat independent of textscan.cc

I adviced to make it a stand-alone module (temporarily) to allow easier
debugging, esp. on other platforms like mxe/Windows.
But maybe that is moot as based on my own use, it works fine on Windows and on
*nix-like platforms like OSX, Octave incl. textscan.cc can be built "natively"
(unlike Windows).


@Lachlan:
If there is a seek()-like function as JWE said, theoretically it should be
possible to map pointer(s) into a buffer into a file pointer. It implies a bit
of bookkeeping, sure, esp. when multiple whitespace and multi-char line
endings and delimiters come into play, but maybe not that daunting.

FTR, I once had a textscan.m working that did exactly that, using pointers
handed to it by an extra output arg. from strread.m. It even worked when
reading from text strings using an extra output arg, something that Matlab
doesn't do.
At the time I didn't pursue further as inside strread.m it soon became a
headache, due to the way strread.m is set up. 
With textscan.cc it could be a lot easier as that linearly processes a file,
unlike strread.m that works on a rectangular cell array from which a file
pointer had to be inferred while all delimiters and whitespace already had
gone after the original file text string was morphed into that cell array.
(Nowadays textscan.m only keeps pointers to lines in the text file.)


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?8783>

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




reply via email to

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