lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Hi Pierre!

You're right!  But I don't think 'subtle' would be allowed..

The Lua 5.2 reference for lua_Reader talks about the reader's behaviour in terms of 'chunks'
I've been talking in this thread about a reader that streams data to the parser
... it's not aware of a 'chunk'.  In other words I'm not doing the reader correctly.

So to make my application work I'd either have to make the reader chunk-aware (which seems to be implied by the Lua reference) or do a major extension to the parsing framework, eg. lua_Streamer or something like that

I reckon the major extension is the wrong move at the moment.
So I'd like ideas for making a reader chunk-aware.

I've already got plenty of ideas floating around in my head to do this reader, but
unfortunately I tend to be good at complicating things :-(

So!  I'm all ears.  What's the best least-way of doing this 'chunking' in the reader???

My context and restrictions are:
  - The lua_Reader is serialising discontiguous data for the parser
  - The discontiguities are block-ish, 1-byte to say the size of a TCP segment
  - reallocations and mem copies should be avoided if at all possible
  - single OS thread (Integrity RTOS)


-- Steve

> -----Original Message-----
> From: [] On
> Behalf Of Pierre-Yves Gérardy
> Sent: Thursday, 2 February 2012 12:08 p.m.
> To: Lua mailing list
> Subject: Re: Lua 5.2 - How do I resume an interrupted parse?
> On Wed, Feb 1, 2012 at 23:20,  <> wrote:
> > The parser-tokeniser would feed the stack and as soon as the stack
> > gets to an executable state, the lua runtime would execute it.
> Now I understand better.
> You'll need something more subtle. For example take `a = math.sin(b)`.
> The expected result is obvious, but the approach you suggest would stop
> parsing before the dot and assign the `math` table to `a`.
> A possible solution would be to compile each statement as a chunk, i.e. wait
> for a semi-column or the beginning of the next statement to compile the last
> one.
> It should be possible to patch the parser to that end, but I haven't looked at it
> in a while so I can't guide you...
> -- Pierre-Yves