New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] reset doesn't have to close the reader [sf#5] #140

Closed
lsf37 opened this Issue Feb 15, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@lsf37
Member

lsf37 commented Feb 15, 2015

Reported by deadsea on 2002-02-05 21:16 UTC
I would like reset to be a little bit more sophisticated.

If the reader (yy_reader) supports mark and reset, I
would like the contents of the buffer to be pushed back
onto the stream rather than the stream being closed.

This would involve calling mark() an the stream before
reading from it:
if yy_reader.markSupported()
yy_reader.mark(yy_buffer.length-yy_endRead);
int numRead = yy_reader.read(yy_buffer, yy_endRead,
yy_buffer.length-yy_endRead);

Then instead of closing the reader in yyreset, you could
reset it to the mark and then re-read anything that has
been truly consumed:
if yy_reader.markSupported(){
yy_reader.reset();
for (int i=0; i<yy_currentPos; i++){
yy_reader.read();
}
} else {
yyclose();
}

It might be desirable to trigger this behavior with
some special flag in the .lex file.

@lsf37 lsf37 changed the title from reset doesn't have to close the reader to [Feature] reset doesn't have to close the reader [sf#5] Feb 15, 2015

@lsf37 lsf37 closed this Feb 15, 2015

@lsf37

This comment has been minimized.

Show comment
Hide comment
@lsf37

lsf37 Feb 15, 2015

Member

Commented by lsf37 on 2002-02-10 15:13 UTC
Logged In: YES
user_id=93534

Closing the input stream in yyreset() was not a vey good
design decision, I'll remove that call in any case. It was
motivated by the fact that the input in the Reader is
invalid for further use (since the scanner reads ahead,
and there's no good way for the outside user to say how
much ahead it reads), but in light of reusing the same
Reader object with new input, it is definitely in the way.

Supporting "mark" also seems to be straightforward enough,
so I think I'll add that too. I'll try the minimal change
first and only add it in the skeleton (and not add an
extra switch for it in the generator).

Member

lsf37 commented Feb 15, 2015

Commented by lsf37 on 2002-02-10 15:13 UTC
Logged In: YES
user_id=93534

Closing the input stream in yyreset() was not a vey good
design decision, I'll remove that call in any case. It was
motivated by the fact that the input in the Reader is
invalid for further use (since the scanner reads ahead,
and there's no good way for the outside user to say how
much ahead it reads), but in light of reusing the same
Reader object with new input, it is definitely in the way.

Supporting "mark" also seems to be straightforward enough,
so I think I'll add that too. I'll try the minimal change
first and only add it in the skeleton (and not add an
extra switch for it in the generator).

@lsf37

This comment has been minimized.

Show comment
Hide comment
@lsf37

lsf37 Feb 15, 2015

Member

Updated by lsf37 on 2002-02-10 15:13 UTC

  • priority: 5 --> 3
Member

lsf37 commented Feb 15, 2015

Updated by lsf37 on 2002-02-10 15:13 UTC

  • priority: 5 --> 3
@lsf37

This comment has been minimized.

Show comment
Hide comment
@lsf37

lsf37 Feb 15, 2015

Member

Updated by lsf37 on 2004-04-12 12:30 UTC

  • status: open --> closed
Member

lsf37 commented Feb 15, 2015

Updated by lsf37 on 2004-04-12 12:30 UTC

  • status: open --> closed

@regisd regisd added the enhancement label Nov 4, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment