Re: Lpeg and malformed input / Lpeg and subjects that do not fit into memory

[Aladdin Lampé <genio570@...>]

Mark, that's another option I hadn't in mind because it would imply to modify Lpeg, which I don't feel like doing :-)

Now I think that this can be implemented with the existing Lpeg module as Roberto said, using a capture callback like this:
  local eos = lpeg.P(-1) / eos_cb

Then, you have to implement the eos_cb() function to request for more input data.
What's still not very clear in my mind is how to substitute the current subject with the new one, composed of the remaining part of the current subject concatened with the new one, and keep the Lpeg parser going as if "nothing had occured".
Roberto? Could you please help me on that one with a simple example? (reading from a file by successive fixed-size chunks, for instance)

Thanks a lot and have a nice day,
Aladdin

>This is just a suggestion, it may have been considered already,
>perhaps the implementation of LPeg doesn't easily allow for this, I
>don't know. But maybe a nice idea might be to allow the user (of LPeg)
>to specify an optional callback function, which is called whenever
>LPeg wants to read more data. The callback then returns the next piece
>of data, or nil on end of data/stream/file/whatever. The current
>implementation could be kept as the default fast path, for when no
>callback is specified. I think this may be a bit more flexible than
>the above solution, and doesn't require any changes to the
>grammar/captures to handle it.


_________________________________________________________________
Téléphonez gratuitement à tous vos proches avec Windows Live Messenger  !  Téléchargez-le maintenant !
http://www.windowslive.fr/messenger/1.asp