Re: strread.m

[John W. Eaton]

On  3-Aug-2011, Philip Nienhuis wrote:

| Admittedly this all looks like, or it just is, prolonged polishing of a 
| big kludge, but IMO it is doable, would need less time investment, and 
| could be done faster than rebuilding textscan (-.oct) from the ground up 

I don't see that it is quite like building it from scratch.  We have
scanf, which works similarly except that textscan has a different set
of conversions and produces different output.

| Dumping my work in favor of a compiled textscan (or oct-file called by 
| textscan-as-it-stands) isn't a problem for me and even preferrable. I 
| just needed my patches to get urgent things done. I might still go ahead 
| fixing the current scripts for myself as long as I see an urgent need 
| while there is no viable alternative.

I will probably try to write textscan in C++.  It's up to you whether
you want to continue fixing problems in strread, but given the
differences in strread and textscan, I don't see how you can achieve
good compatibility for both functions just by writing strread.

As I understand it, textread and strread, although different from
textscan, are basically the same function but unlike textscan you have
to use a different function name if you want to read from a file
vs. reading from a string.  But in any case, also writing these in C++
shouldn't be too hard either.  They can probably share some code with
textscan and scanf, but they can't simply call those functions because
the conversions are different.

| I've got little proficiency at C++; I can understand simple existing 
| code and even fix little things, but creating complete functions is 
| beyond me.
| So fixing the script versions is all I can do.

It would help to have a good set of tests for textscan and
strread/textread.  I could probably also use your help in understanding
how these functions are supposed to work.

jwe