[Top][All Lists]

[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: Sat, 14 Nov 2015 12:50:09 +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 #5, patch #8783 (project octave):

<just short comments, little time now>

ML's textscan (and for that matter, strread and textread) probably suffer from
what in my native mother tongue is called "the Xmas-tree effect" - too many
bells and whistles added w/o much of an underlying structured philosophy; and
sometimes the options can bite each other.

Like you I'm in favor of offering better functionality than ML. For me the
current textscan.m+strread.m combo often works better than ML's stuff, it can
do things that ML can't, like "cuddling" literals.

I deliberately tried the patch against 4.0.x rather than 4.0.0, in the hope it
wouldn't yield too many failed hunks, as 4.0.0 is IMO already outdated.

AFAIK an independent .oct file can be made fairly easily as long as the
mkoctfile command is fed all required include file locations (i.e., probably
also some needed for oct-stream.cc) and maybe other dependencies outside of
those for Octave itself.
Again, that's only a suggested temporarily convenience to avoid having to
rebuild Octave to build & debug just one function (that hasn't yet formally
been included in core either). It means one can develop textscan() in some
subdir completely separate from Octave by just running "mkoctfile <options>".
No .mk files should be edited, core Octave's build tree shouldn't be affected
in any way. But that's all your pick :-)


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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