Re: strread.m

[Philip Nienhuis]

John W. Eaton wrote:
> 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.

Textscan also has a lot of "behaviour modifiers" (parameter/value options).

> | 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 should have added:  " in sight."  :-)

> 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

Do you have a time schedule in mind?
That would help me make a better decision of what to do.

> differences in strread and textscan, I don't see how you can achieve
> good compatibility for both functions just by writing strread.

Please define "good compatibility".

I tried to avoid bug-for-bug compatibility. Admittedly, that encompasses 
a large gray area - you gave a fine example in your previous post.

Anyway strread's ML compatibility as it stands is already fairly good 
now - much, much better than it was. Same goes for textscan.

Even ML's textscan has several ambiguities, undocumented behaviour etc. 
Perhaps it offers just too many options and too much configurable behavior.

> 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.

Yes, ML strread and textread probably call the same mex file.

I like Ben's idea of textscan being the "core" routine that can be 
called by strread and textread.

> | 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.

One of the things I did was more or less doubling the number of tests 
for all three functions. Did you have a look yet? (Rik has several fixes 
to them pending)

Anyway, be my guest. Thank you for your trust in me.
From your example I infer that you already have a good nose for where 
the gotchas and pitfalls lie...

Philip