> Nor should it, EOF is only raised if the proc interface was so poor it
> couldn't signal it in any other way.
That's not very regular, but as long as the documentation clearly states it, I
guess it's OK.
> > NB: I don't know what target Nim aims at (C89? C99? POSIX? the same ones
> > with ex
Some greps can indeed be quite good.
Really, I think this algorithmic intelligence should be able to be just used
from Nim `strutils`. Nim strings know their length. Many/most of those
read-only procs like `strutils.find` "should" be able to work on types like
`MemSlice` or really some kind of
> Won't raise an exception for EOF.
Nor should it, EOF is only raised if the proc interface was so poor it couldn't
signal it in any other way. Eventually we will get `io.nim` that uses a proper
sum type for this.
> I guess 3. could be a function like your checkErr() but then it should always
@Araq
So, I read the version from:
[https://github.com/nim-lang/Nim/blob/devel/lib/system/sysio.nim](https://github.com/nim-lang/Nim/blob/devel/lib/system/sysio.nim)
I hope that was the right one.
proc checkErr(f: File) =
if c_ferror(f) != 0:
c_clearerr(f)
rai
@BossHogg The IO routines have been fixed but I wouldn't mind another pair of
eyes on the code.
Yeah. I haven't tried out your code, but an API idea might be to have the
caller instruct the iterator what to do with any improper/undelimited record at
the end -- includeUnterminated=False or something. Only the caller really knows
what is desired.
One observation, algo performance-wise, is t
> Anyway, this idea is just sort of the simplest/first step into a wider world
> of efficient substring search algorithms that you might enjoy reading about
> some day.
Mmmyeah... or I'll call `grep` (seriously, I did it for another program because
it was faster than my lousy simplistic algorit
