Everything

php

Long awaited line directive

php.internals

Marcus Boerger

20 years ago

Hello internals,

attached is a patch that brings the '#line' directive to php.
This is especially usefull for parser generators or any other
code shuffling/generator tools. Any opinions? If nothing speaks
against i'd like to commit this before heading towards OSCON
be end of next week. (oatch is against head of course).

--
Best regards,
Marcus                          mailto:mail@marcus-boerger.de

Pierre Joye

20 years ago

On Sat, 15 Jul 2006 20:26:22 +0200
mail@marcus-boerger.de (Marcus Boerger) wrote:

> Hello internals,
>
>   attached is a patch that brings the '#line' directive to php.
> This is especially usefull for parser generators or any other
> code shuffling/generator tools. Any opinions? If nothing speaks
> against i'd like to commit this before heading towards OSCON
> be end of next week. (oatch is against head of course).
>

To complete the request, one example (if you are not familiar with
other generators or languages):

1. include 'somfile.php'
2.
#line 1 "linedirective.php"
4.  class Foo                 // treated as line 1
5.  {                         // treated as line 2
6.   var $prop1;              // treated as line 3
7.                            // treated as line 4
8.   function bar ($args)     // treated as line 5
9.   {                        // treated as line 6
10.   Some invalid syntax;    // treated as line 7
11.   return;                 // treated as line 8
...

Even if the syntax error happens on line 10 of this file, it will be
reported on line 7 of the file "linedirective.php". Not sure if it will
work exactly like that in php, but this is how it works in c# for
example.

I would love to have it in 5.x :)

Cheers,
--Pierre

Marcus Börger

20 years ago

Hello Pierre,

Saturday, July 15, 2006, 8:48:01 PM, you wrote:

> On Sat, 15 Jul 2006 20:26:22 +0200
> mail@marcus-boerger.de (Marcus Boerger) wrote:

>> Hello internals,
>>
>>   attached is a patch that brings the '#line' directive to php.
>> This is especially usefull for parser generators or any other
>> code shuffling/generator tools. Any opinions? If nothing speaks
>> against i'd like to commit this before heading towards OSCON
>> be end of next week. (oatch is against head of course).
>>

> To complete the request, one example (if you are not familiar with
> other generators or languages):

> 1. include 'somfile.php'
> 2.
>         #line 1 "linedirective.php"
> 4.  class Foo                 // treated as line 1
> 5.  {                         // treated as line 2
> 6.   var $prop1;              // treated as line 3
> 7.                            // treated as line 4
> 8.   function bar ($args)     // treated as line 5
> 9.   {                        // treated as line 6
> 10.   Some invalid syntax;    // treated as line 7
> 11.   return;                 // treated as line 8
> ...

> Even if the syntax error happens on line 10 of this file, it will be
> reported on line 7 of the file "linedirective.php". Not sure if it will
> work exactly like that in php, but this is how it works in c# for
> example.

> I would love to have it in 5.x :)

Yes it works as expected. The directive is taken into account for both
compiler and executor.

Best regards,
Marcus

Richard Lynch

20 years ago

On Sat, July 15, 2006 1:48 pm, Pierre wrote:

> On Sat, 15 Jul 2006 20:26:22 +0200
> mail@marcus-boerger.de (Marcus Boerger) wrote:
>
>> Hello internals,
>>
>>   attached is a patch that brings the '#line' directive to php.
>> This is especially usefull for parser generators or any other
>> code shuffling/generator tools. Any opinions? If nothing speaks
>> against i'd like to commit this before heading towards OSCON
>> be end of next week. (oatch is against head of course).
>>
>
> To complete the request, one example (if you are not familiar with
> other generators or languages):
>
> 1. include 'somfile.php'
> 2.
>         #line 1 "linedirective.php"
> 4.  class Foo                 // treated as line 1

Please don't do this.

It's hard enough to get the masses of PHP users to provide decent
source and line number matchups to help them debug their messes as it
is.

They're just going to use this to make life much much worse...

I can understand why there are SOME uber-geek desires for this, but,
honestly, I just don't see the benefits outweighing the nightmare it
creates...

Sorry.

--
Like Music?
http://l-i-e.com/artists.htm

Robert Cummings

20 years ago

On Sat, 2006-07-15 at 22:35, Richard Lynch wrote:

> On Sat, July 15, 2006 1:48 pm, Pierre wrote:
> > On Sat, 15 Jul 2006 20:26:22 +0200
> > mail@marcus-boerger.de (Marcus Boerger) wrote:
> >
> >> Hello internals,
> >>
> >>   attached is a patch that brings the '#line' directive to php.
> >> This is especially usefull for parser generators or any other
> >> code shuffling/generator tools. Any opinions? If nothing speaks
> >> against i'd like to commit this before heading towards OSCON
> >> be end of next week. (oatch is against head of course).
> >>
> >
> > To complete the request, one example (if you are not familiar with
> > other generators or languages):
> >
> > 1. include 'somfile.php'
> > 2.
> >         #line 1 "linedirective.php"
> > 4.  class Foo                 // treated as line 1
>
> Please don't do this.
>
> It's hard enough to get the masses of PHP users to provide decent
> source and line number matchups to help them debug their messes as it
> is.
>
> They're just going to use this to make life much much worse...
>
> I can understand why there are SOME uber-geek desires for this, but,
> honestly, I just don't see the benefits outweighing the nightmare it
> creates...

This has some really good implications for helping PHP users get the
line numbers more correct. For instance, from what I gather, my template
engine can use this to dynamically generate PHP code from an XML tag and
when the generated code fails due to some syntax error based on the
tag's attributes, If my engine included this directive then the engine
will tell them in what included template source file and on what line
they screwed up rather than them seeing an error that has no obvious
relationship whatsoever to what they did (did I get that right Marcus?).

Cheers,
Rob.

--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

Stanislav Malyshev

20 years ago

RC>>will tell them in what included template source file and on what line
RC>>they screwed up rather than them seeing an error that has no obvious
RC>>relationship whatsoever to what they did (did I get that right
RC>>Marcus?).

Why can't you make your engine put comments in the code?

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Marcus Börger

20 years ago

Hello Stanislav,

Sunday, July 16, 2006, 9:52:59 AM, you wrote:

RC>>>will tell them in what included template source file and on what line
RC>>>they screwed up rather than them seeing an error that has no obvious
RC>>>relationship whatsoever to what they did (did I get that right
RC>>>Marcus?).

> Why can't you make your engine put comments in the code?

He most likely can. But then he still has to do some arithmetic in the
error messages after having looked up the code. Ok let's get this in
a more detailed exxample. Lets look at what a potential xml-template
based code generator might do. Not that the example makes much sense
- sorry for that - but i had to find an easy warning. and I also had
to come up with a very easy generator, for that i hope my mini template
stuff is self explanatory....

file-a.pxp: The template
1. <template><code><![CDATA[include 'file-b.php';]]></code>
2. <include file='file-c.inc'/>
3. <code><![CDATA[var_dump(in_array(1,1));]]</code>
4. <finalize/>
5. </template>

file-b.php: Some valid php file
1. <?php
2. var_dump(in_array(1,1));
3. ?>

file-c.inc: Some code note that we do not have '<?php' here
1. var_dump(in_array(1,1));
2. var_dump(in_array(1,1));

output.php: generated file
1. <?php #line 1 "file-a.pxp"
2. include 'file-b.php';     // line 1, file-a.pxp, include errors unchanged
3. #line 1 "file-c.inc"
4. var_dump(in_array(1,1));  // line 1, file-c.php
5. var_dump(in_array(1,1));  // line 2, file-c.php
6. #line 3 "file-a.pxp"
7. var_dump(in_array(1,1));  // line 3, file-a.pxp
8. #line 9 "output.php"
9. var_dump(in_array(1,1));

Now the above works quite fine and for all errors you get the correct
original source location:

Warning: in_array() expects parameter 2 to be array, integer given in file-b.php on line 2
NULL

Warning: in_array() expects parameter 2 to be array, integer given in file-c.inc on line 1
NULL

Warning: in_array() expects parameter 2 to be array, integer given in file-c.inc on line 2
NULL

Warning: in_array() expects parameter 2 to be array, integer given in file-a.pxp on line 3
NULL

Warning: in_array() expects parameter 2 to be array, integer given in output.php on line 9
NULL

The problem is that not all generator output all line informations. That
is some only get the directive for the original input file. And others
create their own code but do not start those blocks with line directives.

Case one means the second error message would be
output.php: generated file
1. <?php #line 1 "file-a.pxp"
2. include 'file-b.php';     // line 1, file-a.pxp, include errors unchanged
4. var_dump(in_array(1,1));  // line 2, file-a.pxp
5. var_dump(in_array(1,1));  // line 3, file-a.pxp
6. #line 3 "file-a.pxp"
7. var_dump(in_array(1,1));  // line 4, file-a.pxp
9. var_dump(in_array(1,1));

Now the error in line 5 is output as line 3 in file-a.pxp. It will take
you an endless amount to locate the original source. And this is exactly
what happens when you work with comments, only then you even get the
error message as output.php.

In the second case the problem is the omitted line 8 which leads to the
last error been seen as line 5 of file-a.pxp. This will make you think
either your code generator or php is broken.

Best regards,
Marcus

Marcus Börger

20 years ago

Hello Robert,

Sunday, July 16, 2006, 4:47:08 AM, you wrote:

> On Sat, 2006-07-15 at 22:35, Richard Lynch wrote:
>> On Sat, July 15, 2006 1:48 pm, Pierre wrote:
>> > On Sat, 15 Jul 2006 20:26:22 +0200
>> > mail@marcus-boerger.de (Marcus Boerger) wrote:
>> >
>> >> Hello internals,
>> >>
>> >>   attached is a patch that brings the '#line' directive to php.
>> >> This is especially usefull for parser generators or any other
>> >> code shuffling/generator tools. Any opinions? If nothing speaks
>> >> against i'd like to commit this before heading towards OSCON
>> >> be end of next week. (oatch is against head of course).
>> >>
>> >
>> > To complete the request, one example (if you are not familiar with
>> > other generators or languages):
>> >
>> > 1. include 'somfile.php'
>> > 2.
>> >         #line 1 "linedirective.php"
>> > 4.  class Foo                 // treated as line 1
>>
>> Please don't do this.
>>
>> It's hard enough to get the masses of PHP users to provide decent
>> source and line number matchups to help them debug their messes as it
>> is.
>>
>> They're just going to use this to make life much much worse...
>>
>> I can understand why there are SOME uber-geek desires for this, but,
>> honestly, I just don't see the benefits outweighing the nightmare it
>> creates...

> This has some really good implications for helping PHP users get the
> line numbers more correct. For instance, from what I gather, my template
> engine can use this to dynamically generate PHP code from an XML tag and
> when the generated code fails due to some syntax error based on the
> tag's attributes, If my engine included this directive then the engine
> will tell them in what included template source file and on what line
> they screwed up rather than them seeing an error that has no obvious
> relationship whatsoever to what they did (did I get that right Marcus?).

Perfectly correct.

Best regards,
Marcus

Richard Lynch

20 years ago

On Sat, July 15, 2006 9:47 pm, Robert Cummings wrote:

> This has some really good implications for helping PHP users get the
> line numbers more correct. For instance, from what I gather, my
> template
> engine can use this to dynamically generate PHP code from an XML tag
> and
> when the generated code fails due to some syntax error based on the
> tag's attributes, If my engine included this directive then the engine
> will tell them in what included template source file and on what line
> they screwed up rather than them seeing an error that has no obvious
> relationship whatsoever to what they did (did I get that right
> Marcus?).

So, what would the code look like that fixes this issue, from the
sample posted?

It seems to me like you're still going to get an error message about
the right line number, but in the wrong file name.

Or is #file also going in with #line, so your template engine can
forge the filename for __FILE__ to the included file?  I can see that
working to solve this for you.

Working backwards from generated code to source files in templates is
never fun, but solving this in PHP code instead of the template itself
seems like a case of killing a fly with a cannon.

It may make life a tiny bit easier for the experts, but I suspect
#line is going to be abused by the naive to make life hell on the
masses...

--
Like Music?
http://l-i-e.com/artists.htm

Robert Cummings

20 years ago

On Wed, 2006-08-02 at 17:14 -0500, Richard Lynch wrote:

> On Sat, July 15, 2006 9:47 pm, Robert Cummings wrote:
> > This has some really good implications for helping PHP users get the
> > line numbers more correct. For instance, from what I gather, my
> > template
> > engine can use this to dynamically generate PHP code from an XML tag
> > and
> > when the generated code fails due to some syntax error based on the
> > tag's attributes, If my engine included this directive then the engine
> > will tell them in what included template source file and on what line
> > they screwed up rather than them seeing an error that has no obvious
> > relationship whatsoever to what they did (did I get that right
> > Marcus?).
>
> So, what would the code look like that fixes this issue, from the
> sample posted?
>
> It seems to me like you're still going to get an error message about
> the right line number, but in the wrong file name.
>
> Or is #file also going in with #line, so your template engine can
> forge the filename for __FILE__ to the included file?  I can see that
> working to solve this for you.

A file specification will also be part of the line directive. I believe
Marcus mentioned that in one of his posts.

> Working backwards from generated code to source files in templates is
> never fun, but solving this in PHP code instead of the template itself
> seems like a case of killing a fly with a cannon.

It can't be properly solved in PHP land without hacks that are still not
as useful as the line directive.

> It may make life a tiny bit easier for the experts, but I suspect
> #line is going to be abused by the naive to make life hell on the
> masses...

I don't think the naive will go near it. They would need someone to tell
them about it :) Of course, I'm sure it will happen, but that's why
documentation exists.

Cheers,
Rob.

--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

Sara Golemon

20 years ago

>  attached is a patch that brings the '#line' directive to php.
> This is especially usefull for parser generators or any other
> code shuffling/generator tools. Any opinions? If nothing speaks
> against i'd like to commit this before heading towards OSCON
> be end of next week. (oatch is against head of course).
>

Marcus-

Thanks for pounding this out, I think this is an excellently timed
counterpart to the four letter word and should serve code generators very
well.  One minor thought I'd offer up is an option INI setting to disable
creation of the opcode.  This allows the #line directives to be used in
dev/debug environments without causing an impact for production servers
during execution.  It's not a major performance hit, but it's something.

-Sara

Jeff Moore

20 years ago

On Jul 15, 2006, at 11:29 PM, Sara Golemon wrote:

> One minor thought I'd offer up is an option INI setting to disable
> creation of the opcode.  This allows the #line directives to be used
> in dev/debug environments without causing an impact for production
> servers during execution.  It's not a major performance hit, but it's
> something.

Hi Sara,

Why not leave it up to the user land code generator to include the
directive in the debug version or generate without it in the production
version?

Best Regards,

Jeff

Sara Golemon

20 years ago

>> One minor thought I'd offer up is an option INI setting to disable
>> creation of the opcode.  This allows the #line directives to be used in
>> dev/debug environments without causing an impact for production servers
>> during execution.  It's not a major performance hit, but it's something.
>>
> Why not leave it up to the user land code generator to include the
> directive in the debug version or generate without it in the production
> version?
>

Indeed.  This suggestion was cross-wired with another thought when an
enable/disable switch made more sense.  For the sake of code-generators it
does make more sense to simply not generate the line during pre-compile.

-Sara

Marcus Börger

20 years ago

Hello Sara,

Monday, July 17, 2006, 7:09:30 AM, you wrote:

>>> One minor thought I'd offer up is an option INI setting to disable
>>> creation of the opcode.  This allows the #line directives to be used in
>>> dev/debug environments without causing an impact for production servers
>>> during execution.  It's not a major performance hit, but it's something.
>>>
>> Why not leave it up to the user land code generator to include the
>> directive in the debug version or generate without it in the production
>> version?
>>
> Indeed.  This suggestion was cross-wired with another thought when an
> enable/disable switch made more sense.  For the sake of code-generators it
> does make more sense to simply not generate the line during pre-compile.

That is actually the preferred solution. An additional opcode does not
have any impact on the runtime. So having the ocode linger around doesn't
do anything. Which is the same for regenerating the code without #line
directives. On the contray adding a new ini setting affects every request
so i guess the answer is quite obvious.


Best regards,
Marcus

Andi Gutmans

20 years ago

Can you please send me the latest patch for review? I can't find it for some
reason.
Thx.

Andi