e rest in one? [doesn't feel good]
Are we going to have "lazy scalars" which collude with the regexp engine
so that if the regexp engine hits the current end more is read from
the file handle?
Something else?
Or is this no-a-problem for some reason I've not thought of?
Nicholas Clark
can actually be done to avert the need
to buffer a lot of script in these situations. You mustn't attempt to seek
the script file handle as it might be from something unseekable such as a
pipe (or socket. BEGIN {socket STDIN...})
Nicholas Clark
PROTECTED]/msg00029.html
v3: http:[EMAIL PROTECTED]/msg00354.html
> ST> Perhaps we really need a new kind of regex that works by-design against
> ST> streams of bytes?
I don't think any change is needed in the regex syntax. I think just being
careful to use minimal matching whenever possible should be sufficient.
Nicholas Clark
On Mon, Nov 27, 2000 at 05:17:47PM +, Nicholas Clark wrote:
> On Mon, Nov 27, 2000 at 11:09:03AM -0500, Chaim Frenkel wrote:
> > >>>>> "ST" == Sam Tregar <[EMAIL PROTECTED]> writes:
>
> > Look throught the RFCs this was one of Damian Conway&#
e parser starts?
[I'm assuming that you're implying that regular files (determinate length,
seekable) are easy so we don't worry about optimising them until we make the
harder stuff work. So we forget I ever sent that last paragraph for some
months]
Nicholas Clark
file;
};
erm. can't have bytes[0]; because that's not portable.
Can't really be short because who said that that was 2 bytes?
For that matter I know of one compiler which doesn't have any type
sizeof(2), and sizeof (struct counted_file) is 8 here on this arm machine
:-) Wierdo but ANSI compliant alignment constraints.
[yes, I forced that one using the second struct inside the first]
Nicholas Clark
er have a dependency on the IO library?
Bah. Can't have them both at the same time.
Nicholas Clark
On Tue, Nov 28, 2000 at 04:47:42PM -0500, Dan Sugalski wrote:
> At 09:05 PM 11/28/00 +0000, Nicholas Clark wrote:
>>On Tue, Nov 28, 2000 at 03:35:37PM -0500, Dan Sugalski wrote:
Not sure:
Dan:
>>>>> is treated as if it points to a stream of bytes, where the first f
On Wed, Nov 29, 2000 at 03:33:16PM -0500, Dan Sugalski wrote:
> Good integration with source filters may well solve a large chunk of our
> little language problem. They're a pain and a half to write now but if we
> can get them easier to write that'd be a good thing. ('Specially if we can
> man
rm to standard C.
>
> - Damien
Not sure if it's what prompted you to say this, but perl5-porters has
recently turned up one such system, Cray PVP (SV1 or YMP)
It doesn't like casting between data pointers and function pointers:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-12/msg00558.html
Nicholas Clark
uot;
as a prompt.
I don't think you can do that with eval in perl5, can you?
If not, it represents something new the parser will have to be able to
communicate with the outside world.
Nicholas Clark
On Sun, Dec 17, 2000 at 12:43:15PM +, Simon Cozens wrote:
> On Sun, Dec 17, 2000 at 01:20:07AM +0000, Nicholas Clark wrote:
> > I'm assuming we're all sort of thinking that input is certainly
> > [good stuff]
Thanks, but you were supposed to tell me what I'd mis
On Sun, Dec 17, 2000 at 02:11:50PM -0700, Nathan Torkington wrote:
> Nicholas Clark writes:
> > Would it be sane to get the parser to return suitable information on the
> > source to let a syntax analyser (such as a highlighting editor) know that
> > character positions
arser API we'd not yet considered.
And this is the parser-api list, so it seemed very on topic.
I think I'm not wrong in saying that making the parser state totally
encapsulated makes the parser restartable and goes a long way to making
it re-entrant.
Nicholas Clark
14 matches
Mail list logo
