date:20120906

Re: [PHP-DEV] Re: Moving to an AST-based parsing/compilation process

2012-09-06 Thread Ivan Enderlin @ Hoa



On 05/09/12 18:59, Andrew Faulds wrote:

On 05/09/12 13:48, Morgan L. Owens wrote:
I'm not a core dev, but I would like to add to the notes above that 
third parties, such as myself, who want to do things with PHP 
source other than run it through a PHP interpreter would also 
appreciate such a separation of concerns.


To date, I've been basing work, which exposes syntactic structure, on 
phc's maketea grammar (Phalanger's is more up to date, but also more 
complicated what with its provenance and the Linq and generics and 
all), but it's reverse-engineered and certainly wrong (oh, that 
reminds me...); the existing grammar is unsuitable because no-one 
wants to see _that_.


Something authoritative that _by definition_ tracks the current 
version would be more reassuring as regards accuracy and 
compatibility (and be more likely to result in something that 
deserves to be let out into the world with confidence).




To add to your point:

If we make it produce an AST, I wonder if we could possibly expose 
this through PHP, perhaps with some sort of extension. Then parsers 
and such for PHP could simply ask PHP to do the parsing for them, and 
then do analysis - no more duplicating official PHP grammar.


I'm just speculating here, but this would be pretty cool if we could 
do it.
+1. It will be very useful for static analysis, test, control flow graph 
etc.


--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] On BC and interfaces

2012-09-06 Thread Lester Caine


Stas Malyshev wrote:

Given many discussions on the list about changing stuff in PHP, I'd like
to bring everybody's attention to comment by Linus Torvalds in this
topic:https://plus.google.com/115250422803614415116/posts/hMT5kW8LKJk



It talks about Linux kernel and discussion has next to nothing to do
with PHP, but generic point about keeping the interfaces and importance
of not serving one use case I think very important for all widely used
platforms equally. I think the opinion of the author of one of the most
successful platforms in recent history may be interesting to consider.


To quote ...
Some gnome people seem to be in total denial about what their problem really is. 
They'll wildly blame everybody except themselves. This article seems to be a 
perfect example of that.


In addition to managing all of the changes being integrated into PHP I've been 
living with the 'improvements' in Linux. KDE3 became KDE4 and in my opinion 
totally unusable! OK I'm a dodo, but simply LEARNING how to cope with a new way 
of working and fighting a deliberate policy of blocking any 'classic' theme ... 
I moved over to Gnome which did at least work more like I was comfortable with, 
and they go and do the same pigging thing! But at least someone was listening 
and I'm on a 'classic' view currently. Progress needs to be productive not 
aesthetic?


How does this relate to PHP? It's exactly the same attitude here. SPL interfaces 
are something we can currently take or leave. Personally I'd just disable them 
altogether but it seems I can't? Some would like to force them on us, and 
generators are a nail now to hang making more stuff 'core' such as more 
exceptions. But personally I don't need them. All of my persistent storage is 
via the database, and fast access to that - filtering the information required - 
processing the output - purely uses the database interface. PDO gives me nothing 
there. It's still incomplete and there is little interest in 'completing' it. 
ADOdb may be a bit bloated, but a bit more attention to the extension from those 
of you who understand the fine detail and we could have a faster well 
established alternative? Currently each major project is going of designing it's 
own alternative some based on PDO, some database specific, simply because there 
is not a GOOD standard interface to work off. Even the ZendDB interface ends up 
getting it's own custom extensions on each project making maintenance a 
nightmare. I've three different zend framework based sites I've inherited and 
all three provide a 'different' database interface! They will be moved to my own 
framework simply because it's easier than trying to learn three new methods of 
working. That and I can get everything back onto Firebird which provides 
transparent background backup's.


The drive to release more often has to have a 'reason'. And getting bug and 
security fixes out promptly is the reason, not trying to placate some self 
inflated commentator who says PHP is crap because it doesn't have ... but they 
are never going to use it anyway?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mysqli_fetch_field() mysqlnd libmysql differences

2012-09-06 Thread Johannes Schlüter

Hi,

On Sep 6, 2012, at 1:24, Daniel Convissor dani...@analysisandsolutions.com 
wrote:

 Hi Johannes:
 
 On Thu, Jan 19, 2012 at 01:50:47PM +0100, Johannes Schlüter wrote:
 
unsigned long length
 
The width of the field. This corresponds to the display length,
in bytes.
 
The server determines the length value before it generates the
result set, so this is the minimum length required for a data
type capable of holding the largest possible value from the
result column, without knowing in advance the actual values that
will be produced by the query for the result set.
 
http://dev.mysql.com/doc/refman/5.5/en/c-api-data-structures.html
 
 Pardon me for looping back around to this old discussion.  I had a
 moment to look at this in PEAR::DB the other day.  A new perspective
 came to mind...
 
 It seems the field length in the C API is there to aid C programmers
 with memory allocation.
 
 The field length in PHP is there for PHP programmers to reverse engineer
 database structures.
 
 These are different purposes and the output should reflect such.
 
 For example, the userland PHP field length could lead to someone dumping
 a structure that has a VARCHAR(10).  The exported metadata would say
 VARCHAR(30).  Then it gets imported and dumped again, and now we're up
 to VARCHAR(90).  Not fun.

This is all correct - but there isn't much we can do. The server provides this 
data. Trying to fix it on the client side will likely become a mess. If we 
create a mess I prefer doing it in user land (db2, mdb, doctrine, propel, ...) 
where everybody can debug/fix it.

Johannes

 Thanks for your reconsideration,
 --Dan
 
 -- 
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Moving to an AST-based parsing/compilation process

2012-09-06 Thread Ivan Enderlin @ Hoa


Hi Dmitry,

On 06/09/12 07:37, Dmitry Stogov wrote:

Hi Nikita,

Personally, I don't see any reason to build AST. As you mentioned 
yourself, it will be slower and will require more memory. On the other 
hand AST itself would allow to perform only very basic optimizations. 
Most of them can be easily done on VM opcode level as well.
The lexing and parsing processes will not be slower than actual, and the 
construction of an AST is a new process. Well, as usual, new process 
requires new resources. But if we look further, it will certainly be a 
nice tool to perform better opcode caching, it will remove a lot of 
hacks, it will allow third-part tools working on safeness, security, 
quality etc. to go deeper at low-costs which is very important for PHP 
community, it will facilitate future works (implementations, features 
etc.) for PHP… Moreover, it may be possible that compiler compilers have 
a better lexing and parsing processes than actual?


Someone said that AST is more “academical”, yes it is and that is why we 
can benefit from already done researches in this area to avoid memory 
overhead (one among others). We are not the first ones facing this 
problem. It requires some researches before starting to develop this. 
Let's try as a POC and we will quickly see if this is a wrong way or not.


Cheers.




Also, as it's not an easy task, the old ugly hacks will be replaced 
with new mistakes, which would require new hacks in the future :)


The only real advantage could be an ability to expose AST to PHP 
scripts, but only few people may need it.


Thanks. Dmitry.

On 09/04/2012 11:57 PM, Nikita Popov wrote:

Hey folks!

Some people asked me what the advantages of using an AST-based
parsing/compilation process are, so I put together a few quick notes
in an RFC:

https://wiki.php.net/rfc/ast_based_parsing_compilation_process

It would be nice to get a few comments from other core devs on this.

Nikita






--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Moving to an AST-based parsing/compilation process

2012-09-06 Thread Leigh

The lexing and parsing processes will not be slower than actual, and the
construction of an AST is a new process. Well, as usual, new process
requires new resources. But if we look further, it will certainly be a nice
tool to perform better opcode caching, it will remove a lot of hacks, it
will allow third-part tools working on safeness, security, quality etc. to
go deeper at low-costs which is very important for PHP community, it will
facilitate future works

I think this is a good point to focus on, there has been a lot of comments
about the increased resource cost of the parse. What is being forgotten is
that you can offset this against all of the gains you will see as a result.

Maybe the upfront cost of a parse goes up, but once it is parsed and the
opcodes are cached, you won't have this cost again until you change the
script. Then you have all of the benefits for every subsequent request.

Increased cost once, benefits every time.
On Sep 6, 2012 8:53 AM, Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net
wrote:

Hi Dmitry,

On 06/09/12 07:37, Dmitry Stogov wrote:

Hi Nikita,

Personally, I don't see any reason to build AST. As you mentioned
yourself, it will be slower and will require more memory. On the other hand
AST itself would allow to perform only very basic optimizations. Most of
them can be easily done on VM opcode level as well.

Someone said that AST is more “academical”, yes it is and that is why we
can benefit from already done researches in this area to avoid memory
overhead (one among others). We are not the first ones facing this problem.
It requires some researches before starting to develop this. Let's try as a
POC and we will quickly see if this is a wrong way or not.

47 matches

Mail list logo