Hi,
There is a problem with the patch committed. It incorrectly tokenizes
things like
$foo = %-{$bar}
(this breaks the PEAR installer, amongst other things)
I've attached a fix for it.
Also, it looks like you didn't accept the part of the fix that allows
for enhanced handling of heredocs.
At 11:35 AM 11/16/2002 -0500, George Schlossnagle wrote:
Hi,
There is a problem with the patch committed. It incorrectly tokenizes
things like
$foo = %-{$bar}
(this breaks the PEAR installer, amongst other things)
I've attached a fix for it.
Also, it looks like you didn't accept the part
Here's the patch. Looks like everything but the heredoc part is in cvs
now.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
George Schlossnagle wrote:
I'm a tool. I sent the wrong patch to the list. Thanks to Andrei for
pointing it out. Here is the _right_ patch (finally).
diff -u -3 -r1.53 zend_language_scanner.l
--- zend_language_scanner.l8 Nov 2002 13:40:54 -1.53
+++ zend_language_scanner.l15
Hey,
I think this patch makes the scanner much more complicated to understand. I
have an idea of a patch which would make it much cleaner although under
very certain cases might be a tad bit less optimized when it comes to the
amount of tokens but it'd save all of the yyless() and push_stacks
Andi Gutmans wrote:
Try it out and let me know how the results are. Also *please* send
diffs also as attachments so that when people apply them we won't get
bad whitespace in our sources.
php-dev seems to eat my attachments
--
PHP Development Mailing List http://www.php.net/
To
I propose something like the following: (not tested)
It's definitely a sexier patch :)
Andi
RCS file: /repository/ZendEngine2/zend_language_scanner.l,v
retrieving revision 1.62
diff -u -u -r1.62 zend_language_scanner.l
--- zend_language_scanner.l 5 Nov 2002 22:01:35 - 1.62
+++
At 06:23 PM 11/15/2002 -0500, George Schlossnagle wrote:
Andi Gutmans wrote:
Try it out and let me know how the results are. Also *please* send diffs
also as attachments so that when people apply them we won't get bad
whitespace in our sources.
php-dev seems to eat my attachments
Much sexier indeed. There are some flaws with it:
o Tokenizes heredocs on whitespace
o Doesn't count lines correctly for debug (since strings now have
newlines in them)
Here's a revised patch to yours that fixes those (heredocs are tokenized
on newlines - I think that is best case)
Andi
I commited it.
Thanks,
Andi
At 06:48 PM 11/15/2002 -0500, George Schlossnagle wrote:
Much sexier indeed. There are some flaws with it:
o Tokenizes heredocs on whitespace
o Doesn't count lines correctly for debug (since strings now have
newlines in them)
Here's a revised patch to yours
Hi Andi,
The last patch I submitted was broken as well. Following that, I had
the bright idea to run the prospective changes through the unit-tester
to ensure correct performance. Here's a patch which achieves that. It
does not work for heredocs (i.e. they are tokenized as before, but
The patch I submitted included BACKQUOTES in the token matching as
well. I'm not convinced that is bad, but I will try to thoroughly test
it tomorrow, and if it's broken, I'll just case it for and heredocs.
George
On Monday, November 11, 2002, at 01:56 AM, Andi Gutmans wrote:
OH I missed
Hi,
I still think the patch isn't good. encaps_list which is the main parser
rule can parse:
T_VARIABLE T_OBJECT_OPERATOR T_STRING
Your version of T_STRING would break this.
Again I might be missing something but my hunch is that it would break.
Andi
At 03:06 AM 11/11/2002 -0500, George
Hi,
You're right. This patch should address that concern:
diff -u -3 -r1.51 zend_language_scanner.l
--- zend_language_scanner.l 2 Nov 2002 16:32:26 - 1.51
+++ zend_language_scanner.l 11 Nov 2002 22:17:09 -
@@ -32,6 +32,7 @@
%}
%x ST_IN_SCRIPTING
+%x ST_EXPECTING_OBJECT
For those who came to Dan my or Derick's talk at the Int. PHP
Conference, we both covered the bad inefficiency in the parser that
results in strings with variables in them being tokenized on
whitespace. This results in a huge number of unnecessary opcodes in
strings.
Attached (hopefully, as
On Sun, 10 Nov 2002, George Schlossnagle wrote:
For those who came to Dan my or Derick's talk at the Int. PHP
Conference, we both covered the bad inefficiency in the parser that
results in strings with variables in them being tokenized on
whitespace. This results in a huge number of
On Sunday, November 10, 2002, at 05:06 PM, George Schlossnagle wrote:
For those who came to Dan my or Derick's talk at the Int. PHP
Conference, we both covered the bad inefficiency in the parser that
results in strings with variables in them being tokenized on
whitespace. This results in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It's the list, I don't think they allow attachmentsdo you have web space
you could upload to?
On Sunday 10 November 2002 05:16 pm, Derick Rethans wrote:
On Sun, 10 Nov 2002, George Schlossnagle wrote:
For those who came to Dan my or Derick's
I got the second attachment mail ok but I'll just inline it here:
--- Zend/zend_language_scanner.l2002-11-10 16:53:27.0
-0500
+++ /Users/george/src/php4/Zend/zend_language_scanner.l 2002-11-10
16:39:11.0 -0500
@@ -686,7 +686,6 @@
HNUM 0x[0-9a-fA-F]+
LABEL
--snip
+fprintf(stderr, %s:%d\n, __FILE__,__LINE__);
What's this fprintf()? This seems to be put just for debugging purpose.
Moriyosh
return T_STRING;
}
-ST_DOUBLE_QUOTES,ST_BACKQUOTE,ST_HEREDOC{LABEL_OR_WHITESPACE} {
that would be my debugging from my 'clean' cvs copy. :)
You don't want that. Sorry. Here's a better patch:
Index: zend_language_scanner.l
===
RCS file: /repository/Zend/zend_language_scanner.l,v
retrieving revision 1.51
diff -u
Hi,
A patch which improves on this would be welcome.
However, this patch at first glance is bogus. You are returning T_STRING
with possible spaces and other non A-Za-z_ chars. This token is also used
as tokens such as constants and function names .
Andi
At 06:31 PM 11/10/2002 -0500, George
Unless I misunderstand the way this works, it's not a problem that it
returns a T_STRING, only possibly that it does so inside a BACKQUOTES.
Function names and constants aren't available as barewords in
DOUBLE_QUOTES or HEREDOCs, right?
On Monday, November 11, 2002, at 01:12 AM, Andi Gutmans
OH I missed that. I'll check it out this evening as I have to go now.
Andi
At 01:48 AM 11/11/2002 -0500, George Schlossnagle wrote:
Unless I misunderstand the way this works, it's not a problem that it
returns a T_STRING, only possibly that it does so inside a BACKQUOTES.
Function names and
24 matches
Mail list logo
