PHP_Parser - was [ANNOUNCEMENT] phpDocumentor 1.2.0rc1 (beta) Released]

From: Date: Fri, 25 Apr 2003 17:19:08 +0000
Subject: PHP_Parser - was [ANNOUNCEMENT] phpDocumentor 1.2.0rc1 (beta) Released]
Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-15532@lists.php.net to get a copy of this message
I've been playing with the php parser a bit more - mainly due to the desperate need for a quick class navigational tool on the desktop - http://devel.akbkhome.com/classNav.jpg I've been finding that flipping from one file to another just to remember the API for a class / either mine or something like quickforms :).. In phpmole is just too annoying (and taking too much time.) It uses alot of the same principles as phpcodedoc - however it makes far better use of parse caching. Thinking about your comments before about the general structure and issues with phpdocu - from what I envision of a caching parser../ outputter.. Pass 1: select a directory or base file to start with. foreach of the files found.. - parse or grab the cached parse file. - remember class+filename ** dump the details at this point.. - to reduce memory consumption. - this could be extended to store stuff like packages, extends array's, last change dates.., .. this basically is enough to generate a list of files for outputting. and menus.. Pass 2; output layer: can do modification checks to see if the body needs outputing - suggest caching the page bodies. each page output can reload from the parse the full class/funciton details etc. - as they would be all cached in wddx files it should be extremely quick. and since the data is dumped after each output, memory consumption should be quite low. funily enought you could do alot of the hard work on the client side with javascript and wddx :) ------------------------------------ What i've not done - and dont really want to attack is the phpdoc comment parser.. Ideally A single/or group of classes that would take: $r = PHP_Parser_Comment::parse(
      "/**
* some comment * * @some tags.... **/"); and return some kind of structured array? how easy would that be to integrate into phpdocu - I have no idea if you have got a data structre for this already in phpdocu - have you got a print_r example? ---------- As far as the code goes - I managed to knock a second of the typical parse time by changing from a huge switch/case to method_exists() - due to the wonderfully way php handles big case statements internally.. :) something like DB_DataObjects takes 2 seconds to parse on a p3/1000, and obviously milliseconds if it uses a cached version... thanks to the wonders of subversion - the current version should always be at real code: http://www.akbkhome.com:81/svn/akpear/PHP_Parser/Parser.jay generated file: http://www.akbkhome.com:81/svn/akpear/PHP_Parser/Parser.php a pretty-print* wddx cache file http://www.akbkhome.com:81/svn/akpear/Gtk_ClassViewer/ClassViewer.php.wddx * this is using a little patch that went to php-dev a few days ago.. -------------- Any one want to +1 the PHP_Parser into PEAR? - although the output structure is extremely up in the air at present.. - at least the docs should be easy - it's only got two public methods ;) Regards Alan Greg Beaver wrote:
Hi Alan, This is definitely the direction we want to move for 2.0. Tal has been talking about working in C to write an extension to take care of some of the memory and time-intensive elements. We haven't had much trouble with the parser eating up memory, it's been the linking and conversion to output that has really been the killer. Large projects currently require a ton of information to guarantee that linking will work, and it all needs to be in memory at once, otherwise the speed of the disk would determine parsing speed, and we'd be looking at days to parse large projects. This is with the current design, mind you, so we are looking for bright ideas from bright people like you :). The current parser is slightly more complex due to the parsing of docblock templates. I like the idea of only processing docblocks that belong to an element, and requiring that they immediately precede the element, and of generating a parser from the same rules that PHP uses. I need to read more on jay/bison before I can give you an intelligent response, so I'll do that. Greg Alan Knowles wrote:
Greg, Whats the current state of your parser - I've not looked that closely at the code recently. The reason I was asking was I wanted to write a small gtk app to navigate and browse classes and was looking at a way to parse the classes into a datastructure - the thinking being that a small application could just parse a PHP file into a simple array and serialize it. into a file: eg. DB/DataObjects.php would have a serialized description as DB/DataObjects.php.serial you could then just do date checking on the 2 files to see if it needs re-parsing. Since parsing is generally the memory killer for these apps it should solve alot of problems, and In theory could be a small simple shared component of all 'PHP code analysis tools'..... anyway - the example code is at (The jay/bison base file) http://www.akbkhome.com:81/svn/akpear/PHP_CodeDoc/CodeDoc/Parser2.jay the generated php class http://www.akbkhome.com:81/svn/akpear/PHP_CodeDoc/CodeDoc/Parser2.php (you can modify the last line to play with it parsing other files..) how to use phpJay http://www.akbkhome.com:81/svn/akpear/PHP_CodeDoc/CodeDoc/test_jay.sh the current print_r version of the output. http://www.akbkhome.com:81/svn/akpear/PHP_CodeDoc/CodeDoc/Parser2_example_output.txt The intention is not for this to get involved in phpdoc comment parsing. - just to provide a generic file parser for PHP. (as in small reusable component) let me know if you have any thoughts.. Regards Alan Beaver wrote:
Hi, pear.php.net crapped out after 30 seconds in PEAR.php (don't know what the problem is), so there was no release announcement sent. phpDocumentor 1.2.0rc1 has been released, and is available for immediate installation through pear.php.net This release fixes nearly 50 bugs, and has all major features for the 1.2.0 release cycle implemented. The peardoc2 converter should be fully functional, source highlighting has been greatly enhanced, and all of the HTML:frames templates have been spiffed up by Marco von Ballmoos, our new favorite developer. Contrary to the release notes, there are a few open bugs in this release (oops), and there will possibly be more discovered. If you find any, please open a new bug at the sourceforge project page. to install phpDocumentor, use: pear install PhpDocumentor NOT pear install PHPDoc Regards Greg Beaver -- phpDocumentor http://www.phpdoc.org
-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com -- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com

« previous php.pear.dev (#15532) next »