[PHP-DOC] Livedocs and xCHM building.
Hi. With the Livedocs system about to become live, does this impact on how the xCHM manual is to be built? I've not followed Livedocs, but the name suggests that commits are live in the docs (obvious really). So, this suggests that Livedocs is another tool to access the CVS which means that there should be no impact upon the xCHM build process. Richard.
Re: [PHP-DOC] Livedocs and xCHM building.
With the Livedocs system about to become live, does this impact on how the xCHM manual is to be built? I've not followed Livedocs, but the name suggests that commits are live in the docs (obvious really). So, this suggests that Livedocs is another tool to access the CVS which means that there should be no impact upon the xCHM build process. livedocs bring zero impact for chms. Livedocs is just a set of PHP scripts to produce another type of output (for now only webpages) from the xml sources. In theory no changes to the sources should be necessary. It is planned that in the future (probably far way) livedocs will be able to produce chm, xchm and pdf, and thus replace all other tools we use currently. Nuno
[PHP-DOC] Livedocs SoC proposal
Hello everyone! I've created a draft Livedocs proposal for the SoC, it can be seen here: http://wiki.phpdoc.info/LiveDocs/SocProposal Please feel free to make suggestions and provide feedback, I plan to submit it within a couple days. Thanks! Regards, Philip
Re: [PHP-DOC] Livedocs SoC proposal
Well I think it is pretty good, as long as you implement all the primary and longer term ideas ;) Really, I like your ideas. So far we haven't had any application to Livedocs, so I think yours is likely to be accepted. Nuno Hello everyone! I've created a draft Livedocs proposal for the SoC, it can be seen here: http://wiki.phpdoc.info/LiveDocs/SocProposal Please feel free to make suggestions and provide feedback, I plan to submit it within a couple days. Thanks! Regards, Philip
Re: [PHP-DOC] Livedocs SoC proposal
I also read through the application, and it seems to be decent. Although documentation writing is not something supported by the SoC program, hopefully documentation tools are something to stand behind. Goba Nuno Lopes wrote: Well I think it is pretty good, as long as you implement all the primary and longer term ideas ;) Really, I like your ideas. So far we haven't had any application to Livedocs, so I think yours is likely to be accepted. Nuno Hello everyone! I've created a draft Livedocs proposal for the SoC, it can be seen here: http://wiki.phpdoc.info/LiveDocs/SocProposal Please feel free to make suggestions and provide feedback, I plan to submit it within a couple days. Thanks! Regards, Philip
[PHP-DOC] Livedocs Problem
Hi, I didn't followed all the mail you said about livedocs but since all the updates, I have some problems... I was building everything but the constant ROOT_NODE was not found, so I reconfigure again. If I set caching enable, I receive ROOT_NODE undefined for manual.html. For all other webpage (cached or not) I receive the following : permissions problem for '/dat/dev/php/phpdoc-all/fr/chapters/tutorial.xml'? Moreover, everything is in UTF-8... I modified in file the line that start the parser by ISO but I don't think the problem is from there... So I modify the theme php.net to put the equiv parameter to iso... I always receive the UTF. Finally, I force apache to output pages with charset iso (AddDefaultCharset ISO-8859-1) and I receive again utf... The build process takes only 2 seconds and used to take about 1 hour before... This is my configure command : [EMAIL PROTECTED] livedocs]# ./configure --with-build-log=log.txt --with-doc=/var/www/php/phpdoc-fr --enable-content-caching=no --with-output-dir=/var/www/php/livedocs_web --with-theme=php.net --with-languages=fr en --with-web-base=/livedocs/ And in log.txt I receive some errors... about folder that didn't exist I check the log.txt and receive some errors... ./build.sh: line 17: cd: /dat/dev/php/phpdoc-all: Aucun fichier ou répertoire de ce type ... configure: error: HEY!! You should probably mkdir /home/httpd/html/phpman/htdocs... Thank you very much -- Jean-Sébastien Goupil [EMAIL PROTECTED]
Re: [PHP-DOC] Livedocs -- Pre-Built!
Sean Coates wrote: http://www.phpdoc.info/livedocs/built/ It's built nightly. I know today's (20050621) works well. Recent builds have 46 bytes - brilliant shrink but I'm afraid something is missing inside ;-). Not sure what that's all about, but I'll look into it once I'm out from under my pile of email. (I just moved, and my stupid stupid telco can't even switch lines properly..) Fixed. Logic error in my script was changing to the wrong directory.. oops (-: S
Re: [PHP-DOC] Livedocs -- Pre-Built!
http://www.phpdoc.info/livedocs/built/ It's built nightly. I know today's (20050621) works well. Recent builds have 46 bytes - brilliant shrink but I'm afraid something is missing inside ;-). Not sure what that's all about, but I'll look into it once I'm out from under my pile of email. (I just moved, and my stupid stupid telco can't even switch lines properly..) S
Re: [PHP-DOC] Livedocs -- Pre-Built!
Sean Coates wrote: http://www.phpdoc.info/livedocs/built/ It's built nightly. I know today's (20050621) works well. Recent builds have 46 bytes - brilliant shrink but I'm afraid something is missing inside ;-). Jakub Vrana
Re: [PHP-DOC] Livedocs -- Pre-Built!
In response to the conversation we had last week (you remember: the one where Goba shot down my XUL docs idea, and I conceded? (-; ), I've been working on packaging a pre-built Livedocs distribution. Ilia's recent changes have also been a catalyst for me to actually do something about this. I am glad you conceded :) This marks a great step forward in the life of livedocs, and probably in the future of php.net too. Let the champagne flow!! To be a bit more official, I will only be able to test this cool stuff the weekend, since I am having some important exams later this week. This does not mean I am not excited enough already :) Goba
Re: [PHP-DOC] Livedocs -- Pre-Built!
On little note, for all who will be testing livedocs in the next while. At this time development is done ONLY using the English translation. Until we confirm that it works as intended I will ignore bugs with other localizations. Once English works, then we can try to identify and resolve problems with other translations. Ilia Gabor Hojtsy wrote: In response to the conversation we had last week (you remember: the one where Goba shot down my XUL docs idea, and I conceded? (-; ), I've been working on packaging a pre-built Livedocs distribution. Ilia's recent changes have also been a catalyst for me to actually do something about this. I am glad you conceded :) This marks a great step forward in the life of livedocs, and probably in the future of php.net too. Let the champagne flow!! To be a bit more official, I will only be able to test this cool stuff the weekend, since I am having some important exams later this week. This does not mean I am not excited enough already :) Goba
Re: [PHP-DOC] Livedocs -- Pre-Built!
- Distribute as a PEAR package (PEAR's new channels seem like the perfect candidate, as does the upcoming PHP_Archive package). I didn't thought in PEAR initially, but seems to be a good idea, althought I've never used it :) (but this remainds me to work on the generalization of the code) I think it could be cool to remove the errors in the search.php and a way to select easily iso-8859-1 like illa said me in http://bugs.php.net/30440 for a public release. I'll work on the french language later, don't worry :) (because it is the most up-to-date translation) Long time ago, I had problems (do you remember them Nuno ;) when trying to install livedocs into phpdoc folder under windows, if I experiment these problems again, I'll try to post them. It should work fine now, as Ilia already applied my patch to fix the windows problems. And anyway they only existed in the build system, which is something you won't need to use with this packaged version. It should also work with microsoft's IIS, as Wez also patched livedocs for it. Nuno P.S.: well, as one of mine's colleague said, flame the threads, don't flame the forests :), I'd like to ask if we can have a playground for livedocs, either a separated cvs module or a separate branch. I've created a cvs repository just for me in my school's server, but I'd like to have anything where we all could work. P.S.2: that said, I still have at least more 2 exams (maybe more..), so I don't know when I'll start working. P.S.3: there is (or at least was) a bug in the function reference. if you click in the 'function reference' on the left, it will enter in an infinite cicle, because of the refgroup patching.
Re: [PHP-DOC] Livedocs -- Pre-Built!
Nuno Lopes wrote: I didn't thought in PEAR initially, but seems to be a good idea, althought I've never used it :) (but this remainds me to work on the generalization of the code) To be clear: I don't want to put it IN PEAR. I want to distribute it via an independent PEAR channel, as ONE distribution option. The tarball would always exist... and I wouldn't want Ilia complaining about bloat (-: P.S.: well, as one of mine's colleague said, flame the threads, don't flame the forests :), I'd like to ask if we can have a playground for livedocs, either a separated cvs module or a separate branch. I've created a cvs repository just for me in my school's server, but I'd like to have anything where we all could work. Now that Wez has put hacks into the CVS ACL system, Ilia, would it be possible to set up a livedocs DEV branch, where we can ask for karma (and anyone who has reasonable credentials can get it), and you can optionally merge on request/review? I don't think this would harm anything, as we wouldn't be allowed to touch livedocs-head, and it would even speed along development. P.S.3: there is (or at least was) a bug in the function reference. if you click in the 'function reference' on the left, it will enter in an infinite cicle, because of the refgroup patching. Seems to still exist... http://bugs.php.net/ (-: S
Re: [PHP-DOC] Livedocs -- Pre-Built!
Branching livedocs would only complicate things, if there are patches open bug reports and I'll review them or if these are features simple e-mail them to me (or Wez or Derick). Ilia
[PHP-DOC] Livedocs -- Pre-Built!
Hello fellow phpdocers. In response to the conversation we had last week (you remember: the one where Goba shot down my XUL docs idea, and I conceded? (-; ), I've been working on packaging a pre-built Livedocs distribution. Ilia's recent changes have also been a catalyst for me to actually do something about this. The project is currently in what I'd consider early alpha state, but the few people I've had test it say that it works fine. Please don't distribute the URL outside of this list.. yet. So, basically what it is, is a pre-configured phpdoc + a pre-built livedocs, with the paths mangled (to work at any location in the filesystem), and all of the unnecessary files stripped out of the phpdoc tree (leaving only the DocBook XML). It's likely that there are more files that can be stripped, so I'm open to suggestions. It also marks the function pages with an identifier: language/control-structures.xml $Revision: 1.119 $ | Sean's Pre-Built Livedocs 20050621 | generated: 2005-06-21 15:16:57 GMT Tarred and bzipped, we're to be slightly under 7 megs. Not too bad. Short term goals: - Get this working well on all tested platforms - Create a new theme for this that's lighter than the php.net theme, but DOES include a search box (only way to search, currently, is to hack on the URL (using the default theme)) - Port my script to docweb, once we're reasonably happy with stability (and save my bandwidth/CPU). Long term goals: - Distribute via php.net - Use translations (livedocs dependent) - Distribute as a PEAR package (PEAR's new channels seem like the perfect candidate, as does the upcoming PHP_Archive package). - Make your own docs where users can [un-]check the modules they [don't] want, reducing the size of the tarball, and creating a custom doc package. We could also have common configurations like MySQL developer (remove all other database docs), as a base, before [un-]checking modules. And now, the URL: http://www.phpdoc.info/livedocs/built/ It's built nightly. I know today's (20050621) works well. Feedback, please. S
Re: [PHP-DOC] Livedocs -- Pre-Built!
Sean Coates wrote: Tarred and bzipped, we're to be slightly under 7 megs. Not too bad. It's now 4.5 MB (I forgot, and included notes -- this shouldn't be). (fixed, BTW) S
Re: [PHP-DOC] Livedocs -- Pre-Built!
Sean Coates wrote: Feedback, please. Works for me without any problems (Win XP, Apache 2, PHP 5). Maybe it will be worthwhile to create a version without phpdoc/en/ as everyone already has a CVS version. I also wonder where en/*.ent and entities/*.ent are hidden. Jakub Vrána
Re: [PHP-DOC] Livedocs -- Pre-Built!
Jakub Vrana wrote: Works for me without any problems (Win XP, Apache 2, PHP 5). Maybe it will be worthwhile to create a version without phpdoc/en/ as everyone already has a CVS version. Thanks -- glad it works on Windows (-: WE have a CVS version, yes. This is targetted at a wider audience, though. Think CHM alternative. I also wonder where en/*.ent and entities/*.ent are hidden. I deleted them because they're unnecessary (livedocs pre-calculates the entities, and stores them in a sqlite DB0. S
Re: [PHP-DOC] Livedocs -- Pre-Built!
I think it could be cool to remove the errors in the search.php and a way to select easily iso-8859-1 like illa said me in http://bugs.php.net/30440 for a public release. OoOoO, it seems that search.php is now corrected :) just suggesting the new feature for encoding now :) Long time ago, I had problems (do you remember them Nuno ;) when trying to install livedocs into phpdoc folder under windows, if I experiment these problems again, I'll try to post them. Jean-Sébastien Goupil [EMAIL PROTECTED] Sean Coates wrote: Jakub Vrana wrote: Works for me without any problems (Win XP, Apache 2, PHP 5). Maybe it will be worthwhile to create a version without phpdoc/en/ as everyone already has a CVS version. Thanks -- glad it works on Windows (-: WE have a CVS version, yes. This is targetted at a wider audience, though. Think CHM alternative. I also wonder where en/*.ent and entities/*.ent are hidden. I deleted them because they're unnecessary (livedocs pre-calculates the entities, and stores them in a sqlite DB0. S
Re[2]: [PHP-DOC] Livedocs Deployment to End Users
||*()*|| Hi, Sean. I don't know of a showstopper. It will probably only turn out, if we push it out to a lot of testers. It might be a good idea to package up a manual with some pregenerated sqlite db, and offer it as some BETA (how popular this designation is nowadays :). Since the code gets pushed out, we can get some review and patches/improvements maybe. My only fear is that it is possible that we get too many improvements without no common direction, and not accepting a good percentage of them might discouradge quite some contributors. SC Ilia, Wez, SC What do you two (as primary Livedocs contributors) think? SC S I'm not Ilia or Wez and from my POV livedocs is more like a codepile rather than some kind of idea I can think about like a project or planned product. This idea one can get from sources, but not many people have time or desire to do reversing. It would be nice to have more descriptive info about http://wiki.phpdoc.info/LiveDocs with basic principles livedocs is based upon and perhaps some kind of diagram to quickly show the structure of livedocs, it's problems and program parts need to be finished. I suppose clear understanding of final point can attract people. t --
Re: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygook about theCHM)
Is there any reason why the docbook sources aren't distributed ? Seems that would remove some dependancies, and allow other viewers to pull the book(s) direct. They are... http://cvs.php.net/phpdoc/ Post ./configure'd, and ready to use. Don't know if you remember I was the bod that appeared in #phpdoc with the beginnings of a general docbook/xml viewer. OK, maybe I am repeating the same topic too often, but this is just to try to focus efforts on some best of breed solutions :) What would such a viewer do? How would it compare to livedocs? Goba
RE: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygookabout theCHM)
-Original Message- From: Gabor Hojtsy [mailto:[EMAIL PROTECTED] Sent: 14 June 2005 09:20 To: [EMAIL PROTECTED] Cc: 'Sean Coates'; phpdoc@lists.php.net Subject: Re: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygookabout theCHM) Is there any reason why the docbook sources aren't distributed ? Seems that would remove some dependancies, and allow other viewers to pull the book(s) direct. They are... http://cvs.php.net/phpdoc/ Post ./configure'd, and ready to use. Don't know if you remember I was the bod that appeared in #phpdoc with the beginnings of a general docbook/xml viewer. OK, maybe I am repeating the same topic too often, but this is just to try to focus efforts on some best of breed solutions :) What would such a viewer do? How would it compare to livedocs? Goba I think livedocs is trying to solve a different problem, I think. (Reducing time between edit/view?) I just want something I can dump several documents (possibly in different formats), to build a central library. http://homepage.ntlworld.com/jared.williams/php5/ss.png It takes complete documents using DOM to substitue all the entities, and splits it into chunks based on its doctype. (All docs in the screenshot are docbook, except for the mysql documentation which is TexInfoML.) The for actual presenting HTML, the chunk is simple transformed with a XSLT, again based on the original doctype, when requested, and possibly cached. Jared
Re: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygookabout theCHM)
I think livedocs is trying to solve a different problem, I think. (Reducing time between edit/view?) Livedocs is trying to a solve the problem of displaying a docbook document on the fly (with as small amount of preprocessing as possible). I just want something I can dump several documents (possibly in different formats), to build a central library. So your goals are similar :) http://homepage.ntlworld.com/jared.williams/php5/ss.png Looks nice. It takes complete documents using DOM to substitue all the entities, and splits it into chunks based on its doctype. (All docs in the screenshot are docbook, except for the mysql documentation which is TexInfoML.) The for actual presenting HTML, the chunk is simple transformed with a XSLT, again based on the original doctype, when requested, and possibly cached. Well, I think this would be interesting for quite some folks, so if you are interested in open sourcing it, I bet there would be some support from the community on eg. sf.net. Goba
[PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygook about the CHM)
Gabor Hojtsy wrote: Who has no webserver on his machine nowadays? Especially if he is interested in PHP? Livedocs offers a lot more possibilities also in an offline (ie without internet connection, with local webserver) setting, if used appropriately. You know.. I've been thinking about this. In order for something like this to work, we'd have to purge most extraneous tools from the build chain. For example, livedocs does a /path/to/phpdoc/configure when it ./build.sh which requires things like xsltproc So, now the questions: 1) is there a way to configure the docs (and build livedocs) without installing a bunch of libraries (especially on cygwin).. I'm thinking that a pure PHP solution is the the only reasonable expectation. 2) if not, does anyone care to work on something that would allow this OPTIONALLY? (Obviously, PHP scripts are going to be slower than the native C (e.g. xsltproc), most of the time.) S
Re: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygook about the CHM)
Who has no webserver on his machine nowadays? Especially if he is interested in PHP? Livedocs offers a lot more possibilities also in an offline (ie without internet connection, with local webserver) setting, if used appropriately. You know.. I've been thinking about this. In order for something like this to work, we'd have to purge most extraneous tools from the build chain. For example, livedocs does a /path/to/phpdoc/configure when it ./build.sh which requires things like xsltproc So, now the questions: 1) is there a way to configure the docs (and build livedocs) without installing a bunch of libraries (especially on cygwin).. I'm thinking that a pure PHP solution is the the only reasonable expectation. 2) if not, does anyone care to work on something that would allow this OPTIONALLY? (Obviously, PHP scripts are going to be slower than the native C (e.g. xsltproc), most of the time.) 1. We can easily ship an sqlite db for the complete manual, as we are going to do with all the mirror sites, when livedocs will be ready to handle serving the manual. 2. We can provide a web service for users to pick their customized manual, and get a customized sqlite db plus the needed XML files in a package. 3. For those, who want more, requiring the full phpdoc build system is not an issue. With #2, we can already expand in areas not thought of before by our kind readers. Goba
Re: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygook about the CHM)
1. We can easily ship an sqlite db for the complete manual, as we are going to do with all the mirror sites, when livedocs will be ready to handle serving the manual. Good point (-: 2. We can provide a web service for users to pick their customized manual, and get a customized sqlite db plus the needed XML files in a package. 3. For those, who want more, requiring the full phpdoc build system is not an issue. With #2, we can already expand in areas not thought of before by our kind readers. These are good ideas. +1 (-: S
Re: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygook about the CHM)
1. We can easily ship an sqlite db for the complete manual, as we are going to do with all the mirror sites, when livedocs will be ready to handle serving the manual. Good point (-: 2. We can provide a web service for users to pick their customized manual, and get a customized sqlite db plus the needed XML files in a package. 3. For those, who want more, requiring the full phpdoc build system is not an issue. With #2, we can already expand in areas not thought of before by our kind readers. These are good ideas. +1 (-: Well, sad thing is that we have some good perspectives with livedocs, but not much work is done on this front. We might have had some good chance to grab some coding hands with Google SOC, but we are quite late in the game :) Any ideas to help recruit more developers? I often think about exposing the possibilities of livedocs more to php.net users, maybe finding more developers, but all of them should accept the controlled development model of the source (which should not be a roadblock, as many other OS projects follow these semantics). Goba
Re: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygook about the CHM)
Well, sad thing is that we have some good perspectives with livedocs, but not much work is done on this front. We might have had some good chance to grab some coding hands with Google SOC, but we are quite late in the game :) Any ideas to help recruit more developers? I often think about exposing the possibilities of livedocs more to php.net users, maybe finding more developers, but all of them should accept the controlled development model of the source (which should not be a roadblock, as many other OS projects follow these semantics). I think people get discouraged about livedocs, because it's so hands-off. That said -- what's WRONG with livedocs, now? There are few bugs open at bugs.php.net -- is there a big unknown issue? PEARdoc ( friends like smarty-doc) support is on my wish-list.. but otherwise, is there a showstopper? S
Re: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygook about the CHM)
Well, sad thing is that we have some good perspectives with livedocs, but not much work is done on this front. We might have had some good chance to grab some coding hands with Google SOC, but we are quite late in the game :) Any ideas to help recruit more developers? I often think about exposing the possibilities of livedocs more to php.net users, maybe finding more developers, but all of them should accept the controlled development model of the source (which should not be a roadblock, as many other OS projects follow these semantics). I think people get discouraged about livedocs, because it's so hands-off. That said -- what's WRONG with livedocs, now? There are few bugs open at bugs.php.net -- is there a big unknown issue? PEARdoc ( friends like smarty-doc) support is on my wish-list.. but otherwise, is there a showstopper? I don't know of a showstopper. It will probably only turn out, if we push it out to a lot of testers. It might be a good idea to package up a manual with some pregenerated sqlite db, and offer it as some BETA (how popular this designation is nowadays :). Since the code gets pushed out, we can get some review and patches/improvements maybe. My only fear is that it is possible that we get too many improvements without no common direction, and not accepting a good percentage of them might discouradge quite some contributors. Goba
Re: [PHP-DOC] Livedocs Deployment to End Users
Gabor Hojtsy wrote: Well, sad thing is that we have some good perspectives with livedocs, but not much work is done on this front. We might have had some good chance to grab some coding hands with Google SOC, but we are quite late in the game :) Any ideas to help recruit more developers? I often think about exposing the possibilities of livedocs more to php.net users, maybe finding more developers, but all of them should accept the controlled development model of the source (which should not be a roadblock, as many other OS projects follow these semantics). I think people get discouraged about livedocs, because it's so hands-off. That said -- what's WRONG with livedocs, now? There are few bugs open at bugs.php.net -- is there a big unknown issue? PEARdoc ( friends like smarty-doc) support is on my wish-list.. but otherwise, is there a showstopper? I don't know of a showstopper. It will probably only turn out, if we push it out to a lot of testers. It might be a good idea to package up a manual with some pregenerated sqlite db, and offer it as some BETA (how popular this designation is nowadays :). Since the code gets pushed out, we can get some review and patches/improvements maybe. My only fear is that it is possible that we get too many improvements without no common direction, and not accepting a good percentage of them might discouradge quite some contributors. Ilia, Wez, What do you two (as primary Livedocs contributors) think? S
Re: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygookabout the CHM)
1. We can easily ship an sqlite db for the complete manual, as we are going to do with all the mirror sites, when livedocs will be ready to handle serving the manual. Good point (-: 2. We can provide a web service for users to pick their customized manual, and get a customized sqlite db plus the needed XML files in a package. 3. For those, who want more, requiring the full phpdoc build system is not an issue. With #2, we can already expand in areas not thought of before by our kind readers. These are good ideas. +1 (-: Well, sad thing is that we have some good perspectives with livedocs, but not much work is done on this front. We might have had some good chance to grab some coding hands with Google SOC, but we are quite late in the game :) Any ideas to help recruit more developers? What a nice idea :) Maybe I could apply at Google summer of code and get livedocs forward :) I often think about exposing the possibilities of livedocs more to php.net users, maybe finding more developers, but all of them should accept the controlled development model of the source (which should not be a roadblock, as many other OS projects follow these semantics). For me, the most problematic thing in livedocs is phpdoc-dependency. Althought it builds fine with smarty docs, for example, peardoc has shown that livedocs is too phpdoc specific. This refers mainly to the build/indexing part, which I would like to work on in my vacations. Nuno
Re: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygookabout the CHM)
Nuno Lopes wrote: What a nice idea :) Maybe I could apply at Google summer of code and get livedocs forward :) Well, we missed the window, but Chuck from the Horde project (which is on the list) has graciously suggested that if someone wants to piggyback on his project for PEAR development, he will consider it. Perhaps we could attempt the same with livedocs? S
Re: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygookabout the CHM)
What a nice idea :) Maybe I could apply at Google summer of code and get livedocs forward :) Well, we missed the window, but Chuck from the Horde project (which is on the list) has graciously suggested that if someone wants to piggyback on his project for PEAR development, he will consider it. Perhaps we could attempt the same with livedocs? It is possible to submit an application without a mentoring organization if I understand well, but Horde might mentor a livedocs project, yes. BUT application deadline is approaching quickly. It is tomorrow! Goba
RE: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygook about theCHM)
-Original Message- From: Sean Coates [mailto:[EMAIL PROTECTED] Sent: 13 June 2005 17:16 To: Gabor Hojtsy Cc: phpdoc@lists.php.net Subject: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygook about theCHM) Gabor Hojtsy wrote: Who has no webserver on his machine nowadays? Especially if he is interested in PHP? Livedocs offers a lot more possibilities also in an offline (ie without internet connection, with local webserver) setting, if used appropriately. You know.. I've been thinking about this. In order for something like this to work, we'd have to purge most extraneous tools from the build chain. For example, livedocs does a /path/to/phpdoc/configure when it ./build.sh which requires things like xsltproc So, now the questions: 1) is there a way to configure the docs (and build livedocs) without installing a bunch of libraries (especially on cygwin).. I'm thinking that a pure PHP solution is the the only reasonable expectation. 2) if not, does anyone care to work on something that would allow this OPTIONALLY? (Obviously, PHP scripts are going to be slower than the native C (e.g. xsltproc), most of the time.) Is there any reason why the docbook sources aren't distributed ? Seems that would remove some dependancies, and allow other viewers to pull the book(s) direct. Jared
Re: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygook about theCHM)
Is there any reason why the docbook sources aren't distributed ? Seems that would remove some dependancies, and allow other viewers to pull the book(s) direct. They are... http://cvs.php.net/phpdoc/ S
RE: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygook about theCHM)
Is there any reason why the docbook sources aren't distributed ? Seems that would remove some dependancies, and allow other viewers to pull the book(s) direct. They are... http://cvs.php.net/phpdoc/ S Post ./configure'd, and ready to use. Don't know if you remember I was the bod that appeared in #phpdoc with the beginnings of a general docbook/xml viewer. Jared
Re: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygook about theCHM)
Jared Williams wrote: Post ./configure'd, and ready to use. Don't know if you remember I was the bod that appeared in #phpdoc with the beginnings of a general docbook/xml viewer. I guess I could do that.. it's like 10 mins of scripting.. I'll put it on phpdoc.info.. and let you know when it's running. S
RE: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygook about theCHM)
Jared Williams wrote: Post ./configure'd, and ready to use. Don't know if you remember I was the bod that appeared in #phpdoc with the beginnings of a general docbook/xml viewer. I guess I could do that.. it's like 10 mins of scripting.. I'll put it on phpdoc.info.. and let you know when it's running. Cool, might be good to make sure it has a conditional get on it. The current plan is to have a cli app to admin it, somewhat similar to pear cli. So once a docbook source is registered, it can check if its been updated, without having to download. Jared
Re: [PHP-DOC] Livedocs Deployment to End Users (WAS: some gobblygook about theCHM)
Jared Williams wrote: Jared Williams wrote: Post ./configure'd, and ready to use. I guess I could do that.. it's like 10 mins of scripting.. I'll put it on phpdoc.info.. and let you know when it's running. Here: http://www.phpdoc.info/docs_prepared/ It should run every morning at 4:15AM Eastern, in the future. I'll also rotate out old stuff after probably a week or two, and add some convenience scripts (latest, for example). S
Re: [PHP-DOC] Livedocs and PEARDoc
Hi Sean, Livedocs isn't woking with peardoc, but I can't remember why (the last/only? guy who worked on this was Medhi). Some tweaking of the mk_peardoc.php file should do the trick. Nuno P.S.: anyway, I wouldn't spend much time on this, as I think the indexing process of livedocs should be rewritten, because it is too much phpdoc specific.. Anyone know the current status of livedocs and PEARDoc? I'd like to know what is/isn't working so I can attempt to get the latter fixed. I've built --with-build-type=peardoc, and got a really messed up livedocs.. I'm wondering if others suffer the same problem, or if I'm doing something wrong (http://livepear.phpdoc.info/ -- b0rked). Thanks, S
[PHP-DOC] Livedocs and PEARDoc
Anyone know the current status of livedocs and PEARDoc? I'd like to know what is/isn't working so I can attempt to get the latter fixed. I've built --with-build-type=peardoc, and got a really messed up livedocs.. I'm wondering if others suffer the same problem, or if I'm doing something wrong (http://livepear.phpdoc.info/ -- b0rked). Thanks, S
[PHP-DOC] livedocs patches
There's an increasing number of patches waiting to be applied to livedocs -
is someone able to look after them? Pretty please!
Also, after trying to hack a couple of things in, I noticed include used
instead of require where it really should not. (Just noting this to whoever
happens to have commit access, perhaps you could fix it).
As an aside: I was trying to work out why examples were showing with 3
spaces instead of 4 (the first space seemed to be removed, which made
docblock comments look stupid) and I noticed the below CSS was commented
out:
div.phpcode code {
white-space: pre;
}
Uncommenting it fixes the problem. Is there any reason this was uncommented?
could it perhaps be added back in? Thanks.
Kind Regards,
Aidan
Re: [PHP-DOC] livedocs patches
On Mon, 4 Oct 2004, Aidan Lister wrote: There's an increasing number of patches waiting to be applied to livedocs - is someone able to look after them? Pretty please! File bugreports. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org
[PHP-DOC] livedocs
Hi, Where can i find a specification design for the livedocs system? Just curious what it will be like. Until now it sounds sexy. Keep up the good work! Cheers Sander
Re: [PHP-DOC] livedocs
Where can i find a specification design for the livedocs system? Just curious what it will be like. Until now it sounds sexy. Keep up the good work! A lot of Livedocs related information (such as where to find the source, examples, where to submit patches...) can be found here: http://wiki.phpdoc.info/livedocs Regards, Philip
Re: [PHP-DOC] Livedocs
This style is also simpler in my eyes. Tested with IE 6 and Opera 7.23. I hope it works in other browsers too but I didn't test it. I have applied your patch. It will turn out if it breaks something else (like Mozilla browsers :). Goba It is still broken for me: IE 6 SP2. Opera and Firefox work well, but W3C's Amaya is broken, too. Nuno
Re: [PHP-DOC] Livedocs
Hi, The tableless layout for the manual is here: http://www.php.net/manual/en/tableless/index.php It displays quite fine in Mozilla Firefox, but is problematic in IE, since it does not interpret the float model correctly. I would be happy to see patches for this though :)) I definitely expect this to be fixed, and that livedocs should use this layout. If the only problems are that there is a horizontal scrollbar and Prev and Next sections don't have margins, here is my proposal: 1. Don't float .manualnavbar at right. 2. Swap the order of .prev and .next, and .langchooser and .langupdated and don't float .prev and .langchooser at left. 3. Don't clear .manualnavbar HR. 4. Remove .cleaner from .manualnavbar. This style is also simpler in my eyes. Tested with IE 6 and Opera 7.23. I hope it works in other browsers too but I didn't test it. I have applied your patch. It will turn out if it breaks something else (like Mozilla browsers :). Goba
Re: [PHP-DOC] livedocs uft-8
moshe doron i'rta: Just to remember, we still didn't changed the output encoding of livedocs to uft-8. Here the patch: http://phpil.net/patchs/livedocs-utf8.patch.txt Please cc: Ilia if posting livedocs patches. He is not on phpdoc. Goba
[PHP-DOC] livedocs uft-8
Just to remember, we still didn't changed the output encoding of livedocs to uft-8. Here the patch: http://phpil.net/patchs/livedocs-utf8.patch.txt -- Moshe.
Re: [PHP-DOC] Livedocs / Chapter names
Also, as an aside: The :: chapter, should be renamed to scope resolution operator? Maybe. I think it should have :: somewhere in the title, how about: Scope Resolution Operator (::) Fine with me. And, should this operator be listed somewhere here? http://php.net/manual/en/language.operators.php Yes it should be. Goba
Re: [PHP-DOC] Livedocs
Gabor Hojtsy wrote:
The tableless layout for the manual is here:
http://www.php.net/manual/en/tableless/index.php
It displays quite fine in Mozilla Firefox, but is problematic in IE,
since it does not interpret the float model correctly. I would be happy
to see patches for this though :)) I definitely expect this to be fixed,
and that livedocs should use this layout.
If the only problems are that there is a horizontal scrollbar and Prev
and Next sections don't have margins, here is my proposal:
1. Don't float .manualnavbar at right.
2. Swap the order of .prev and .next, and .langchooser and .langupdated
and don't float .prev and .langchooser at left.
3. Don't clear .manualnavbar HR.
4. Remove .cleaner from .manualnavbar.
This style is also simpler in my eyes. Tested with IE 6 and Opera 7.23.
I hope it works in other browsers too but I didn't test it.
Patch for phpweb is attached.
Jakub VranaIndex: include/shared-manual.inc
===
RCS file: /repository/phpweb/include/shared-manual.inc,v
retrieving revision 1.216
diff -u -r1.216 shared-manual.inc
--- include/shared-manual.inc 3 Aug 2004 19:12:53 - 1.216
+++ include/shared-manual.inc 27 Aug 2004 11:58:53 -
@@ -244,21 +244,26 @@
global $PGI, $LANG, $LANGUAGES, $INACTIVE_ONLINE_LANGUAGES;
// Start navbar with
-echo !--UdmComment--\ndiv class=\manualnavbar\\n span class=\prev\\n;
-if ($PGI['prev'][1]) {
-echo a href=\{$PGI['prev'][0]}\ .
- make_image('caret-l.gif', 'lt;') .
- $PGI['prev'][1] . /a\n;
-}
-echo /span\n span class=\next\\n;
+echo !--UdmComment--\ndiv class=\manualnavbar\\n span class=\next\\n;
if ($PGI['next'][1]) {
echo a href=\{$PGI['next'][0]}\ .
$PGI['next'][1] .
make_image('caret-r.gif', 'gt;') .
/a\n;
}
+echo /span\n span class=\prev\\n;
+if ($PGI['prev'][1]) {
+echo a href=\{$PGI['prev'][0]}\ .
+ make_image('caret-l.gif', 'lt;') .
+ $PGI['prev'][1] . /a\n;
+} else {
+echo nbsp;\n;
+}
echo /span\n hr /\n;
+// Provide last updated information on this page
+echo span class=\lastupdated\Last updated: {$PGI['lastmod']}/span\n;
+
// Print out language switch on top of manual pages
echo div class=\langchooser\\n;
if ($location != 'bottom') {
@@ -295,12 +300,12 @@
'/images/small_submit.gif border=0 width=11 height=11 ' .
'alt= align=baseline version of this page' . \n /form\n;
+} else {
+echo nbsp;\n;
}
echo /div\n;
-// Provide last updated information on this page anc close div
-echo span class=\lastupdated\Last updated: {$PGI['lastmod']}/span\n .
- div class=\cleaner\/div\n/div\n!--/UdmComment--\n\n;
+echo /div\n!--/UdmComment--\n\n;
}
// =
Index: styles/site.css
===
RCS file: /repository/phpweb/styles/site.css,v
retrieving revision 1.14
diff -u -r1.14 site.css
--- styles/site.css 1 Aug 2004 16:21:05 - 1.14
+++ styles/site.css 27 Aug 2004 11:39:59 -
@@ -455,7 +455,6 @@
/* Top and bottom navigation controls on manual pages - */
div.manualnavbar {
- float: right;
background-color: #e0e0e0;
color: inherit;
padding: 4px;
@@ -468,7 +467,6 @@
text-decoration: underline;
}
div.manualnavbar .prev, div.manualnavbar .langchooser {
- float: left;
padding-right: 4px;
}
div.manualnavbar .next, div.manualnavbar .lastupdated {
@@ -478,7 +476,6 @@
div.manualnavbar hr {
color: #cc;
background-color: #cc;
- clear: both;
}
div.manualnavbar form {
margin: 0px;
Re: [PHP-DOC] Livedocs
On Monday 23 August 2004 15:54, Derick Rethans wrote: On Mon, 23 Aug 2004, Friedhelm Betz wrote: On Monday 23 August 2004 11:03, Derick Rethans wrote: [...] I think we should start making the manual always output UTF8. Can people think of reasons why NOT to do this? Not really, but only the issue to ensure that the source .xml files are always saved/edited as utf-8. This should not be too hard to reach, as nowadays translators have to mange the proper encoding of their files. That is not needed as the XML parser detects the charset from the ?xml declaration and converts it internally into utf8 anyway. Ah, yes, you are right of course. It might increase performance, if the source xml files are already in utf-8? Friedhelm -- http://www.jungle-world.com/
Re: [PHP-DOC] Livedocs
On Tue, 24 Aug 2004, Friedhelm Betz wrote: On Monday 23 August 2004 15:54, Derick Rethans wrote: On Mon, 23 Aug 2004, Friedhelm Betz wrote: On Monday 23 August 2004 11:03, Derick Rethans wrote: [...] I think we should start making the manual always output UTF8. Can people think of reasons why NOT to do this? Not really, but only the issue to ensure that the source .xml files are always saved/edited as utf-8. This should not be too hard to reach, as nowadays translators have to mange the proper encoding of their files. That is not needed as the XML parser detects the charset from the ?xml declaration and converts it internally into utf8 anyway. Ah, yes, you are right of course. It might increase performance, if the source xml files are already in utf-8? Marginally, I wouldn't do the work to convert files to UTF-8 manually if there isn't a very good reason to do it. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org
Re: [PHP-DOC] Livedocs
On Sun, 22 Aug 2004, Gabor Hojtsy wrote: livedocs is now running on docs.php.net (do not announce it yet!) but not automatically updating so far. Please fix the following errors: [Sat Aug 21 16:49:25 2004] [error] [client 80.197.147.147] File does not exist: /local/Web/sites/livedocs/www/style.css [Sat Aug 21 16:49:35 2004] [error] [client 194.248.150.2] File does not exist: /local/Web/sites/livedocs/www/style.css [Sat Aug 21 16:49:41 2004] [error] [client 68.221.28.91] File does not exist: /local/Web/sites/livedocs/www/style.css [Sat Aug 21 16:49:42 2004] [error] [client 68.221.28.91] File does not exist: /local/Web/sites/livedocs/www/favicon.ico [Sat Aug 21 16:50:21 2004] [error] [client 80.197.147.147] File does not exist: /local/Web/sites/livedocs/www/styles/mirror.css [Sat Aug 21 16:51:06 2004] [error] [client 194.248.150.2] File does not exist: /local/Web/sites/livedocs/www/styles/mirror.css [Sat Aug 21 16:51:06 2004] [error] [client 80.197.147.147] File does not exist: /local/Web/sites/livedocs/www/favicon.ico [Sat Aug 21 16:51:06 2004] [error] [client 80.197.147.147] File does not exist: /local/Web/sites/livedocs/www/userprefs.js [Sat Aug 21 16:51:07 2004] [error] [client 194.248.150.2] File does not exist: /local/Web/sites/livedocs/www/images/spacer.gif [Sat Aug 21 16:51:07 2004] [error] [client 68.221.28.91] File does not exist: /local/Web/sites/livedocs/www/styles/mirror.css This is when using the php.net template. The php.net template expects a phpweb checkout in the background (in the same root folder as livedocs). These missing files are in phpweb, and if you also do a rsync (at least for these common files), it will work and look fine. I don't want to do a 1.3GB phpweb checkout really, the files should be in the theme itself so everything is self contained. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org
Re: [PHP-DOC] Livedocs
according to the the last changes on ext/xml, here (http://phpil.net/livedocs.patch.txt) patch that: 1. make the livedocs compatible with php 5.0.1 2. make livedocs on php4 the same as livedocs on php5. Moshe. Gabor Hojtsy [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] livedocs is now running on docs.php.net (do not announce it yet!) but not automatically updating so far. Please fix the following errors: [Sat Aug 21 16:49:25 2004] [error] [client 80.197.147.147] File does not exist: /local/Web/sites/livedocs/www/style.css [Sat Aug 21 16:49:35 2004] [error] [client 194.248.150.2] File does not exist: /local/Web/sites/livedocs/www/style.css [Sat Aug 21 16:49:41 2004] [error] [client 68.221.28.91] File does not exist: /local/Web/sites/livedocs/www/style.css [Sat Aug 21 16:49:42 2004] [error] [client 68.221.28.91] File does not exist: /local/Web/sites/livedocs/www/favicon.ico [Sat Aug 21 16:50:21 2004] [error] [client 80.197.147.147] File does not exist: /local/Web/sites/livedocs/www/styles/mirror.css [Sat Aug 21 16:51:06 2004] [error] [client 194.248.150.2] File does not exist: /local/Web/sites/livedocs/www/styles/mirror.css [Sat Aug 21 16:51:06 2004] [error] [client 80.197.147.147] File does not exist: /local/Web/sites/livedocs/www/favicon.ico [Sat Aug 21 16:51:06 2004] [error] [client 80.197.147.147] File does not exist: /local/Web/sites/livedocs/www/userprefs.js [Sat Aug 21 16:51:07 2004] [error] [client 194.248.150.2] File does not exist: /local/Web/sites/livedocs/www/images/spacer.gif [Sat Aug 21 16:51:07 2004] [error] [client 68.221.28.91] File does not exist: /local/Web/sites/livedocs/www/styles/mirror.css This is when using the php.net template. The php.net template expects a phpweb checkout in the background (in the same root folder as livedocs). These missing files are in phpweb, and if you also do a rsync (at least for these common files), it will work and look fine. Goba
Re: [PHP-DOC] Livedocs
On Mon, 23 Aug 2004, moshe doron wrote: according to the the last changes on ext/xml, here (http://phpil.net/livedocs.patch.txt) patch that: 1. make the livedocs compatible with php 5.0.1 2. make livedocs on php4 the same as livedocs on php5. I don't see why adding iconv calls helps with this, can you also nicely indent your changes in common.php? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org
Re: [PHP-DOC] Livedocs
Derick Rethans [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Mon, 23 Aug 2004, moshe doron wrote: according to the the last changes on ext/xml, here (http://phpil.net/livedocs.patch.txt) patch that: 1. make the livedocs compatible with php 5.0.1 2. make livedocs on php4 the same as livedocs on php5. I don't see why adding iconv calls helps with this, can you also nicely indent your changes in common.php? The iconv make the output 8bit (according to the assumption that bandwide is more important then generation speed of cached content). I didn't indent the common.php to make the patch clear. Here indent version: http://phpil.net/livedocs.patch1.txt. If you want the output uft-8, the patch is simpler just to change the charset here http://cvs.php.net/co.php/livedocs/themes/default/html_format.php?r=1.12#35 to utf-8 (and in the other themes), save xml_parser_create(UTF-8); and ignore all the another changes. Moshe. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org
Re: [PHP-DOC] Livedocs
On Mon, 23 Aug 2004, moshe doron wrote: I don't see why adding iconv calls helps with this, can you also nicely indent your changes in common.php? The iconv make the output 8bit (according to the assumption that bandwide is more important then generation speed of cached content). I didn't indent the common.php to make the patch clear. Here indent version: http://phpil.net/livedocs.patch1.txt. If you want the output uft-8, the patch is simpler just to change the charset here http://cvs.php.net/co.php/livedocs/themes/default/html_format.php?r=1.12#35 to utf-8 (and in the other themes), save xml_parser_create(UTF-8); and ignore all the another changes. I think we should start making the manual always output UTF8. Can people think of reasons why NOT to do this? regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org
Re: [PHP-DOC] Livedocs
On Monday 23 August 2004 11:03, Derick Rethans wrote: [...] I think we should start making the manual always output UTF8. Can people think of reasons why NOT to do this? Not really, but only the issue to ensure that the source .xml files are always saved/edited as utf-8. This should not be too hard to reach, as nowadays translators have to mange the proper encoding of their files. A big +1, AFAICS Friedhelm -- http://www.phpbar.de/
Re: [PHP-DOC] Livedocs
On Mon, 23 Aug 2004, Friedhelm Betz wrote: On Monday 23 August 2004 11:03, Derick Rethans wrote: [...] I think we should start making the manual always output UTF8. Can people think of reasons why NOT to do this? Not really, but only the issue to ensure that the source .xml files are always saved/edited as utf-8. This should not be too hard to reach, as nowadays translators have to mange the proper encoding of their files. That is not needed as the XML parser detects the charset from the ?xml declaration and converts it internally into utf8 anyway. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org
[PHP-DOC] Livedocs / Chapter names
With livedocs, If I update a page, is livedocs meant to regenerate that page on the next request? At the moment, on my build, it is not doing this. I have to delete the cached pages first. Is there a reason for this? Also, as an aside: The :: chapter, should be renamed to scope resolution operator? The do..while, maybe just do while is less misleading?
Re: [PHP-DOC] Livedocs
livedocs is now running on docs.php.net (do not announce it yet!) but not automatically updating so far. Please fix the following errors: [Sat Aug 21 16:49:25 2004] [error] [client 80.197.147.147] File does not exist: /local/Web/sites/livedocs/www/style.css I've got a bunch of fixes for the php.net theme, i'll send in a patch later today. http://livedocs.zirzow.dyndns.org/ Could someone also look at the php.net theme. http://docs.php.net/en/install.problems.html#install.problems.bugs should have a height of 100%, right? Why? It needs to be migrated to the tableless php.net layout IMHO anyway, in which it is not possible to size the page with 100% height. What about we also indent each level in the navigation? To easier distinguish them. Now they are displayed with different colors. Goba
Re: [PHP-DOC] Livedocs
Why? It needs to be migrated to the tableless php.net layout IMHO
anyway, in which it is not possible to size the page with 100% height.
body { height: 100%; } ?
[PHP-DOC] Livedocs
Heya, livedocs is now running on docs.php.net (do not announce it yet!) but not automatically updating so far. Please fix the following errors: [Sat Aug 21 16:49:25 2004] [error] [client 80.197.147.147] File does not exist: /local/Web/sites/livedocs/www/style.css [Sat Aug 21 16:49:35 2004] [error] [client 194.248.150.2] File does not exist: /local/Web/sites/livedocs/www/style.css [Sat Aug 21 16:49:41 2004] [error] [client 68.221.28.91] File does not exist: /local/Web/sites/livedocs/www/style.css [Sat Aug 21 16:49:42 2004] [error] [client 68.221.28.91] File does not exist: /local/Web/sites/livedocs/www/favicon.ico [Sat Aug 21 16:50:21 2004] [error] [client 80.197.147.147] File does not exist: /local/Web/sites/livedocs/www/styles/mirror.css [Sat Aug 21 16:51:06 2004] [error] [client 194.248.150.2] File does not exist: /local/Web/sites/livedocs/www/styles/mirror.css [Sat Aug 21 16:51:06 2004] [error] [client 80.197.147.147] File does not exist: /local/Web/sites/livedocs/www/favicon.ico [Sat Aug 21 16:51:06 2004] [error] [client 80.197.147.147] File does not exist: /local/Web/sites/livedocs/www/userprefs.js [Sat Aug 21 16:51:07 2004] [error] [client 194.248.150.2] File does not exist: /local/Web/sites/livedocs/www/images/spacer.gif [Sat Aug 21 16:51:07 2004] [error] [client 68.221.28.91] File does not exist: /local/Web/sites/livedocs/www/styles/mirror.css This is when using the php.net template. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org
Re: [PHP-DOC] Livedocs
Curt Zirzow wrote: * Thus wrote Derick Rethans: Heya, livedocs is now running on docs.php.net (do not announce it yet!) but not automatically updating so far. Please fix the following errors: [Sat Aug 21 16:49:25 2004] [error] [client 80.197.147.147] File does not exist: /local/Web/sites/livedocs/www/style.css I've got a bunch of fixes for the php.net theme, i'll send in a patch later today. http://livedocs.zirzow.dyndns.org/ Could someone also look at the php.net theme. http://docs.php.net/en/install.problems.html#install.problems.bugs should have a height of 100%, right? What about we also indent each level in the navigation? To easier distinguish them. -- Tom
Re: [PHP-DOC] Livedocs
Curt Zirzow wrote:
* Thus wrote Derick Rethans:
Heya,
livedocs is now running on docs.php.net (do not announce it yet!) but
not automatically updating so far.
Please fix the following errors:
[Sat Aug 21 16:49:25 2004] [error] [client 80.197.147.147] File does not exist:
/local/Web/sites/livedocs/www/style.css
I've got a bunch of fixes for the php.net theme, i'll send in a
patch later today.
http://livedocs.zirzow.dyndns.org/
Also:
table.table, table.informaltable {
border: solid 2px #cc;
border-collapse: collapse;
margin: 1em;
width: 600px;
}
Is there any reason there's a fixed table width of 600 pixels for both
the 'default' and 'php.net' themes? No such limit exists on the built
manual pages. It makes most of the tables really squashed and hard to read.
Curt
Dave
[PHP-DOC] Livedocs CVSTrac?
Hello all, More livedocs conversation. I ran into Ilia on IRC, yesterday, and asked him about Goba's idea to add Livedocs Issue to the bug types on bugs.php.net. Ilia suggested installing cvstrac for the livedocs module. (http://www.cvstrac.org/) I took a quick look over that software, and it looks perfect for livedocs development. I especially like the idea of a wiki tied into the actions log that also shows commits and bug reports. Opinions? S
Re: [PHP-DOC] Livedocs CVSTrac?
More livedocs conversation. I ran into Ilia on IRC, yesterday, and asked him about Goba's idea to add Livedocs Issue to the bug types on bugs.php.net. Ilia suggested installing cvstrac for the livedocs module. (http://www.cvstrac.org/) I took a quick look over that software, and it looks perfect for livedocs development. I especially like the idea of a wiki tied into the actions log that also shows commits and bug reports. Opinions? Fine with me. You need to convince systems@ about this anyway :) Goba
Re: [PHP-DOC] Livedocs CVSTrac?
Well, wanted to see what others thought, before taking it to [EMAIL PROTECTED] Seems there are a number of cvstrac vulnerabilities.. that's not good. S Gabor Hojtsy wrote: Opinions? Fine with me. You need to convince systems@ about this anyway :) Goba
Re: [PHP-DOC] Livedocs CVSTrac?
On Tue, 17 Aug 2004, Gabor Hojtsy wrote: Opinions? Fine with me. You need to convince systems@ about this anyway :) It is one more thing to maintain, and I don't really see the value of it (how cool cvstract might be) Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org
Re: [PHP-DOC] Livedocs CVSTrac?
On Tue, 17 Aug 2004 12:02:34 -0400, Sean Coates [EMAIL PROTECTED] wrote: Well, wanted to see what others thought, before taking it to [EMAIL PROTECTED] Seems there are a number of cvstrac vulnerabilities.. that's not good. S I'll add a bugs page to the livedocs patch system I'm busy hacking up atm. Regards --jm Gabor Hojtsy wrote: Opinions? Fine with me. You need to convince systems@ about this anyway :) Goba -- Jacques Marneweck http://www.powertrip.co.za/blog/
Re: [PHP-DOC] Livedocs CVSTrac?
Derick told me that he added Livedocs Problem as a new Type of Bug on bugs.php.net (should show up soon). Problem solved (IMHO). S
Re: [PHP-DOC] Livedocs CVSTrac?
Well, only one I know of (from first-hand experience today :-/) --Wez. On Tue, 17 Aug 2004 12:02:34 -0400, Sean Coates [EMAIL PROTECTED] wrote: Well, wanted to see what others thought, before taking it to [EMAIL PROTECTED] Seems there are a number of cvstrac vulnerabilities.. that's not good. S Gabor Hojtsy wrote: Opinions? Fine with me. You need to convince systems@ about this anyway :) Goba
Re: [PHP-DOC] Livedocs Status?
I've also a bug list here, that I'll try to fix when I have some time. I don't think that branching is the right way to go. I prefer posting my patches somewhere with a description and then let someone to review, comment and apply/discard them. I agree. My branch proposal was because it seemed the few people with karma were not paying attention. I have been proven wrong in this observation, though. I'd prefer not to branch. Nuno, could you post your bugs list somewhere, if you haven't, already? Thanks, S
Re: [PHP-DOC] Livedocs Status?
Instead of non-specific head is broken email, why not point out what is broken? Livedocs is running fine here; I built it only a week or so ago with no problems. Plus, I have a mirror that updates daily (livedocs.thebrainroom.net) with no problems (assuming that someone hasn't broken phpdoc) If you have a patch that works properly, by all means send it our way (either myself, Ilia, Derick or Goba). What we don't want is a half-baked patch that fixes stuff for one person/case and that breaks everything else; and that is the reason we tightened up the karma--some of us are *already* running livedocs in production. I've seen plenty of people say that livedocs isn't ready, but non of them have said why or come up with a firm list of what needs to be done to make it ready, let alone come up with patches for that. Would it help to open a new Livedocs issue type of bug at bugs.php.net, so people can submit problems / (links to) patches there? I have heard people submit trouble tickets at thebrainroom lately (AFAIR philip did that). It would be better to cleanly provide a way to report bugs against livedocs, now that it is getting used more and more. Goba
[PHP-DOC] Livedocs woes
Tonight, I wasted many hours upgrading livedocs. Many things broke, but with some help (IRC - freenode - #phpdoc (join us (-: ) ), I finally got it working. For anyone with the same troubles, here's what I did: 1) configure failed to detect my xsltproc binary, so I had to change XSLTPROC='no' to XSLTPROC=/usr/bin/xsltproc, otherwise, build.sh fails because it doesn't know how to execute no 2) when running build.sh, it bailed out complaining that the sqlite database was full (in mkindex.php). This happened during VACUUM, which, while beneficial, is not necessary, so comment out the line sqlite_query($idx, 'VACUUM full_search'); in mkindex.php 3) when using any of the themes, I had to link /path/to/livedocs/themes to /path/to/webroot/themes Other caveats: - when giving configure a --with-build-log, build.sh is annoyingly silent. It's much more convenient for me to ./build.sh | tee my_own_build.log, and exclude that configure option. - ignore the MANY lines that start with BAD ID, when running build.sh, I guess they don't matter. I'll try to post more on livedocs, and its current status, tomorrow. I need to sleep now. S
[PHP-DOC] Livedocs Status?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [This is a follow-up post to my previous post, Livedocs woes.] What is the current status of livedocs development? My understanding is that anyone with phpdoc karma, also, once, had livedocs karma. A commit was made that some maintainers did not like, and karma was removed, and only granted to certain people (Currently: iliaa,goba,wez,derick,sfox,alan_k). Please correct me if I am wrong. There are several outstanding issues with the livedocs code. As I said in my post, last night, HEAD seems broken. Also, Nuno has a number of patches available at http://livedocs.aborla.net/ My point? I'd like to determine the proper procedure for patching (getting patches approved for) livedocs, or find an alternative development method. I realize that livedocs is not ready for production, as it is intended. It is, however VERY useful for doc team members (see Philip's posts re: CHANGELOG and the EXIF changes he made for a practical example). I also understand that the original authors of livedocs don't want their code messed with. Isn't this the beauty of CVS, though? I suspect this idea won't be well-received, but if we're not willing/able to keep livedocs HEAD up to date, could we not branch the module for testing purposes? Karma could be re-granted on a per-case basis, with the condition that non-core developers do not commit to HEAD, but to the dev branch. My understanding of the staleness of livedocs is that Ilia and Wez are busy on PHP 5. I understand this. People like Nuno, though, have demonstrated a knowledge of livedocs code, and should be able to contribute, IMHO. I'd also like to see livedocs tagged regularly so we can easily rollback to a previous version (last night, while getting livedocs running, and failing miserably, I was tempted to start pulling random dates out for cvs up -D ). I'm not trying to point fingers, here, I'd just like to see livedocs move forward. Can we find a way to make this happen? can type=worms state=open / S -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBHijnWppknrQMxQIRAtiKAKCCWFtGKzlPxyn4Y3pMydqMVvCT0gCfXQsJ YihNZTBf+dl39Ch7BAODaNc= =UqpZ -END PGP SIGNATURE-
Re: [PHP-DOC] Livedocs Status?
Hi Sean, Currently the way of getting changes commited to the 'livedocs' in CVS is to submit patches to those who have karma. When submitting patches, remeber to do 'cvs diff -u' and save this patch to your website and mail them the link and explain to them what you are trying to do with the patch. Certain patches will not be commited and sometimes they will only after the commiter has changed the code slightly for coding standards or for some performance issues, etc. Regards --jm On Sat, 14 Aug 2004 10:59:51 -0400, Sean Coates [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [This is a follow-up post to my previous post, Livedocs woes.] What is the current status of livedocs development? My understanding is that anyone with phpdoc karma, also, once, had livedocs karma. A commit was made that some maintainers did not like, and karma was removed, and only granted to certain people (Currently: iliaa,goba,wez,derick,sfox,alan_k). Please correct me if I am wrong. There are several outstanding issues with the livedocs code. As I said in my post, last night, HEAD seems broken. Also, Nuno has a number of patches available at http://livedocs.aborla.net/ My point? I'd like to determine the proper procedure for patching (getting patches approved for) livedocs, or find an alternative development method. I realize that livedocs is not ready for production, as it is intended. It is, however VERY useful for doc team members (see Philip's posts re: CHANGELOG and the EXIF changes he made for a practical example). I also understand that the original authors of livedocs don't want their code messed with. Isn't this the beauty of CVS, though? I suspect this idea won't be well-received, but if we're not willing/able to keep livedocs HEAD up to date, could we not branch the module for testing purposes? Karma could be re-granted on a per-case basis, with the condition that non-core developers do not commit to HEAD, but to the dev branch. My understanding of the staleness of livedocs is that Ilia and Wez are busy on PHP 5. I understand this. People like Nuno, though, have demonstrated a knowledge of livedocs code, and should be able to contribute, IMHO. I'd also like to see livedocs tagged regularly so we can easily rollback to a previous version (last night, while getting livedocs running, and failing miserably, I was tempted to start pulling random dates out for cvs up -D ). I'm not trying to point fingers, here, I'd just like to see livedocs move forward. Can we find a way to make this happen? can type=worms state=open / S -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBHijnWppknrQMxQIRAtiKAKCCWFtGKzlPxyn4Y3pMydqMVvCT0gCfXQsJ YihNZTBf+dl39Ch7BAODaNc= =UqpZ -END PGP SIGNATURE- -- Jacques Marneweck http://www.powertrip.co.za/blog/
Re: [PHP-DOC] Livedocs woes
For anyone with the same troubles, here's what I did: 1) configure failed to detect my xsltproc binary, so I had to change XSLTPROC='no' to XSLTPROC=/usr/bin/xsltproc, otherwise, build.sh fails because it doesn't know how to execute no maybe you don't have /usr/bin in the PATH :) the configure script does a AC_PATH_PROG to check automatically for the xsltproc path. 2) when running build.sh, it bailed out complaining that the sqlite database was full (in mkindex.php). This happened during VACUUM, which, while beneficial, is not necessary, so comment out the line sqlite_query($idx, 'VACUUM full_search'); in mkindex.php This work perfectly on my two pcs. VACUUM is just a performance hack for SQLite. You need sqlite = 2.8.1. 3) when using any of the themes, I had to link /path/to/livedocs/themes to /path/to/webroot/themes I never had problems with this... neither on windows or linux! Other caveats: - when giving configure a --with-build-log, build.sh is annoyingly silent. It's much more convenient for me to ./build.sh | tee my_own_build.log, and exclude that configure option. Livedocs build process is aimed to be run by cron... Just type the build command and relax :) Livedocs works! - ignore the MANY lines that start with BAD ID, when running build.sh, I guess they don't matter. They exist, so they matter :) As livedocs is still in an earlier stage you will find many usefull debug info (some hidden in HTML comments). If you trace some problem, you can send me the info and I'll try to solve the problem. My programming skills aren't very good, but I'll try ;) About my patches: I've posted that patches in my website just to don't lost them. Some are tested and can be commited, but some are just proof-of-concept. They can be used later by Ilia, Wez or Derick to fix the problems that I've found (and they may be aware of, but hadn't time to fix yet). The patches have a simple explanation of the problem and of my fix. Creating branches or even other module for livedocs isn't a solution IMHO. The best option is to have an oficial livedocs patch queue (this was proposed by the docs.php.net project), so that they can be reviewed, improved and commited/deleted. Nuno
Re: [PHP-DOC] Livedocs Status?
What is the current status of livedocs development? Accepting patches (applied mostly by Ilia and Wez). There are several outstanding issues with the livedocs code. As I said in my post, last night, HEAD seems broken. Also, Nuno has a number of patches available at http://livedocs.aborla.net/ It would be nice if Ilia (and/or Wez) could review these patches, and apply / comment on them. My point? I'd like to determine the proper procedure for patching (getting patches approved for) livedocs, or find an alternative development method. I realize that livedocs is not ready for production, as it is intended. It is, however VERY useful for doc team members (see Philip's posts re: CHANGELOG and the EXIF changes he made for a practical example). I also understand that the original authors of livedocs don't want their code messed with. Isn't this the beauty of CVS, though? I suspect this idea won't be well-received, but if we're not willing/able to keep livedocs HEAD up to date, could we not branch the module for testing purposes? Karma could be re-granted on a per-case basis, with the condition that non-core developers do not commit to HEAD, but to the dev branch. My understanding of the staleness of livedocs is that Ilia and Wez are busy on PHP 5. I understand this. People like Nuno, though, have demonstrated a knowledge of livedocs code, and should be able to contribute, IMHO. I'd also like to see livedocs tagged regularly so we can easily rollback to a previous version (last night, while getting livedocs running, and failing miserably, I was tempted to start pulling random dates out for cvs up -D ). I'm not trying to point fingers, here, I'd just like to see livedocs move forward. Can we find a way to make this happen? All this is actually up to livedocs core developers (Ilia, Wez, Derick). BTW Derick offered a setup of livedocs to go for live testing at docs.php.net for this week. Goba
Re: [PHP-DOC] Livedocs woes
About my patches: I've posted that patches in my website just to don't lost them. Some are tested and can be commited, but some are just proof-of-concept. They can be used later by Ilia, Wez or Derick to fix the problems that I've found (and they may be aware of, but hadn't time to fix yet). The patches have a simple explanation of the problem and of my fix. Creating branches or even other module for livedocs isn't a solution IMHO. The best option is to have an oficial livedocs patch queue (this was proposed by the docs.php.net project), so that they can be reviewed, improved and commited/deleted. Since only you have pending patches currently against livedocs AFAIK, your queue is the only queue at this point in time. :) Goba
Re: [PHP-DOC] Livedocs Status?
On August 14, 2004 04:23 pm, you wrote: There are several outstanding issues with the livedocs code. As I said in my post, last night, HEAD seems broken. Also, Nuno has a number of patches available at http://livedocs.aborla.net/ It would be nice if Ilia (and/or Wez) could review these patches, and apply / comment on them. I reviewed the patches and applied 7 of them, thanks guys. The Cygwin patch was not applied because I have not way to test it and the last person I spoke to who build the manual on win32 via Cygwin had no issues. What in HEAD is broken? My point? I'd like to determine the proper procedure for patching (getting patches approved for) livedocs, or find an alternative development method. Follow, Nuno example :-). He is doing great work, which for the most part gets into CVS once Wez or I have the time to review it. I also understand that the original authors of livedocs don't want their code messed with. Isn't this the beauty of CVS, though Why commit if it'll be reverted. I suspect this idea won't be well-received, but if we're not willing/able to keep livedocs HEAD up to date, could we not branch the module for testing purposes? Karma could be re-granted on a per-case basis, with the condition that non-core developers do not commit to HEAD, but to the dev branch. My understanding of the staleness of livedocs is that Ilia and Wez are busy on PHP 5. I understand this. People like Nuno, though, have demonstrated a knowledge of livedocs code, and should be able to contribute, IMHO. I'd also like to see livedocs tagged regularly so we can easily rollback to a previous version (last night, while getting livedocs running, and failing miserably, I was tempted to start pulling random dates out for cvs up -D ). There are some critical bugs in the code in particular dealing with pregeneration logic that fails to create some pages. While it's mostly self contained inside pregenerate.php there are some spillbacks to other files. Until that is resolved I'd like to keep once branch only, once that is fixed we can tag a stable release as that's the only major issue I am aware of at this point. Ilia
Re: [PHP-DOC] Livedocs Status?
Ilia, I reviewed the patches and applied 7 of them, thanks guys. The Cygwin patch was not applied because I have not way to test it and the last person I spoke to who build the manual on win32 via Cygwin had no issues. What in HEAD is broken? Thank you very much. I know you're busy, I really appreciate your attention. HEAD, see http://news.php.net/php.doc/969363165 Nuno did not have these problems, but Curt Zirzow helped me install, and he had some of the same problems (VACUUM, etc) -- perhaps my software was out of date. Follow, Nuno example :-). He is doing great work, which for the most part gets into CVS once Wez or I have the time to review it. It seemed that this process was not working, hence my email. I was wrong. Now that we've seen this process work, it seems productive to contribute. Thanks again. (-: There are some critical bugs in the code in particular dealing with pregeneration logic that fails to create some pages. While it's mostly self contained inside pregenerate.php there are some spillbacks to other files. Until that is resolved I'd like to keep once branch only, once that is fixed we can tag a stable release as that's the only major issue I am aware of at this point. That sounds great (the tags, not the bugs (-: ). I look forward to a livedocs-stable. Thanks again, Ilia. Nuno, thanks to you, too. S
[PHP-DOC] livedocs css patch
Hello, I did a quick patch for the livedocs default theme: http://aidan.dotgeek.org/livedocs_css.diff It cleans up a bit of redudant code, and makes the method/class synopsis look nicer by dropping the func/class size.
[PHP-DOC] livedocs?
Is there an online version somewhere? Regards // Tom
Re: [PHP-DOC] livedocs?
We will have a livedocs on-line in the new website for the documentation teams. The website will be lauched soon. Stay tuned! :) Nuno - Original Message - From: Tom Sommer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, June 13, 2004 5:34 PM Subject: [PHP-DOC] livedocs? Is there an online version somewhere? Regards // Tom
Re: [PHP-DOC] Livedocs broken
It's working here, although you must copy xml_classes5.php manually (if using PHP 5, only), because the configure script isn't handling it automatically. Nuno P.S.: I already had a problem building, but then I've set the --with-build-dir=/tmp and it worked! :) - Original Message - Hi there, I've been trying to build a phpdoc-all without success for two days. Does it works for you ? didou
[PHP-DOC] Livedocs broken
Hi there, I've been trying to build a phpdoc-all without success for two days. Does it works for you ? didou
[PHP-DOC] livedocs bug
Hello,
Latest improvements on livedocs have broken it.
The problem is in handle_include(). It was modified so that it could solve
the problem with PCRE (for example).
However that implementation contains a bug. Let's see:
This 3 line long sql query never returns a result (at least on my machine):
list($row) = sqlite_array_query($GLOBALS['idx'], SELECT idents.id, lvl
from ents left join files on ents.value = files.filename left join idents on
files.fileid = idents.fileid left join toc on ents.entid=toc.docbook_id
where is_file=1 and ents.entid='$ref' limit 1);
so, $lvl isn't set.
Then we have:
$filename = sqlite_single_query($GLOBALS['idx'], SELECT value from ents
where entid='$ref' and is_file=1);
$path = PHPDOC . DIRECTORY_SEPARATOR . $filename;
if (!file_exists($path)) {
$path = PHPDOC . DIRECTORY_SEPARATOR . $GLOBALS['lang'] .
DIRECTORY_SEPARATOR . $filename;
}
The $filename returns for me the path to the file
('C:/cvs/phpdoc/en/reference/tidy/functions.xml' for example). So $path will
be:
C:\cvs\phpdoc\C:/cvs/phpdoc/en/reference/tidy/functions.xml. Why we need
that code to find the $path, when $path should be $filename?
So, the references pages aren't showing any functions.
Nuno
[PHP-DOC] livedocs PATCH
Hi Wez,
Today you have commited my patch, but it was modified. Check ref.spl or
ref.tidy and you will see that are broken, because you missed some parts of
my patch.
Attached is the patch to solve that issues (the parts that weren't commited)
and also a bugfix for the PCRE page.
Nuno
Index: BUGS
===
RCS file: /repository/livedocs/BUGS,v
retrieving revision 1.6
diff -u -r1.6 BUGS
--- BUGS1 May 2004 10:08:22 - 1.6
+++ BUGS23 May 2004 10:45:12 -
@@ -4,10 +4,6 @@
- The reserved constants and the missing stuff section are not working,
the later would be better left out from the livedocs output.
- - The ref.pcre page does not link properly to the pattern modifiers and
- pattern syntax docs (it thinks that those are functions but this is
- not true at all)
-
- Table spans don't work. Check nl_langinfo() function for an example
$Revision: 1.6 $
Index: livedoc.php
===
RCS file: /repository/livedocs/livedoc.php,v
retrieving revision 1.103
diff -u -r1.103 livedoc.php
--- livedoc.php 7 May 2004 13:32:58 - 1.103
+++ livedoc.php 23 May 2004 10:45:12 -
@@ -127,7 +127,7 @@
}
/* Checks if translated file is updated */
-if ($lang != 'en' isset($lang_rev)) {
+if ($lang != FALLBACK_LANG isset($lang_rev) $lang_rev 0) {
/* get english file revision */
$data = @file_get_contents(FALLBACK_BASE . $filename);
@@ -349,6 +349,19 @@
$entities['' . $r[0] . ';'] = $r[1];
}
+ /* If language!=English and entity was not found */
+ if($GLOBALS['lang'] != FALLBACK_LANG) {
+ foreach($entities_to_find as $ent) {
+ if(!isset($entities['' . $ent . ';'])) {
+ $q = sqlite_single_query($GLOBALS['fb_idx'],
SELECT value FROM ents WHERE entid='$ent');
+ if (!$q) {
+ break;
+ }
+ $entities['' . $ent . ';'] = $q;
+ }
+ }
+ }
+
/* substitute */
$data = strtr($data, $entities);
@@ -395,6 +408,7 @@
$data = preg_replace('@!--\s+.*\s--@Usm', '', $data);
/* Replace entities */
+ $data = str_replace($search, $replace, $data);
$data = bind_entities($data);
/* catch any undefined entities */
@@ -413,8 +427,6 @@
$data = preg_replace('/([a-zA-Z0-9-]+)\.([a-zA-Z0-9.-]+);/sm',
'phpdoc_include ref=\\1.\\2/', $data);
}
- $data = str_replace($search, $replace, $data);
-
$page = new DocBookToHTML($data);
@@ -504,32 +516,36 @@
* and generate a link to its node using its title */
function make_function_link($ref)
{
- $parts = explode('.', $ref);
-
- $stag = 'function';
- $etag = 'function';
-
- if (count($parts) == 4) {
- $id = 'function.' . $parts[3];
- $func_name = lookup_title($id);
- } elseif ($parts[3] == 'class' count($parts) == 5) {
- $id = 'class.' . $parts[4];
- $func_name = strtr($parts[4], array('-'='_'));
- $stag = xref linkend=\$id\;
- $etag = xref;
- } else {
- /* some weird node type we don't understand */
- $id = $ref;
- $func_name = 'Unknown ??';
- }
-
- if($parts[3] == 'class') {
- $title = ' - ' . lookup_title($id) . ' class';
- } else {
- $title = ' - ' . bind_entities(sqlite_single_query($GLOBALS['idx'],
SELECT descr from toc where docbook_id='$id'));
- }
-
- return div class=\function_link\$stag$func_name/$etag$title/div;
+ $parts = explode('.', $ref);
+
+ $stag = 'function';
+ $etag = 'function';
+
+ if (count($parts) == 5 $parts[3] == 'class') {
+ $id = 'class.' . $parts[4];
+ $stag = xref linkend=\$id\;
+ $etag = 'xref';
+ $name = strtoupper($parts[4]);
+ $title = $name class;
+ } else {
+ $id = 'function.' . strtolower($parts[3]);
+ $q = sqlite_array_query($GLOBALS['idx'], SELECT title,descr from toc
where docbook_id='$id', SQLITE_NUM);
+
+ if($q) {
+ $name = $q[0][0];
+ $title = $q[0][1];
+ } else {
+ $name = $id;
+ $title = '???';
+ }
+
+ /* Fetch english description */
+ if($GLOBALS['lang'] != FALLBACK_LANG $name == $title) {
+ $title = sqlite_single_query($GLOBALS['fb_idx'], SELECT descr
RE: [PHP-DOC] livedocs PATCH
Hey Nuno, I left out those other parts because: 1/ lookup_title() is good thing to use (take a look at what it does) 2/ Although I want to solve the dom problem, I don't want to hard code dom specifics into the guts of livedocs 3/ the version stuff is not phpdoc specific; it can happily live in the default theme. Sorry to be a pain, but can you list the specific issues that remain and which parts of your patch fix those things? Part of the problem is that you're fixing too much in one patch, and it makes it difficult to see what's what. Thanks, --Wez. -Original Message- From: Nuno Lopes [mailto:[EMAIL PROTECTED] Sent: 23 May 2004 11:51 To: PHPdoc Subject: [PHP-DOC] livedocs PATCH Hi Wez, Today you have commited my patch, but it was modified. Check ref.spl or ref.tidy and you will see that are broken, because you missed some parts of my patch. Attached is the patch to solve that issues (the parts that weren't commited) and also a bugfix for the PCRE page. Nuno
Re: [PHP-DOC] livedocs PATCH
Hey Nuno,
I left out those other parts because:
1/ lookup_title() is good thing to use (take a look at what it does)
Oh, it is caching the results But SPL, Tidy,... don't work.
Mine implementation fetches the title and the description with one DB query
instead of two that you would do with the call of lookup_title
Maybe I could use that cache in my implementation, too. Not dificult to do.
2/ Although I want to solve the dom problem, I don't want to hard code dom
specifics into the guts of livedocs
So how? How do you know if you to append 'dom-' to the id?
3/ the version stuff is not phpdoc specific; it can happily live in the
default theme.
No! PHPDOC is the only using the version stuff. With your modified patch, it
works perfectly, because you are doing:
if ($q LATEST_VERSION == $q) {
and I think the correct version would be:
if (!$q || LATEST_VERSION == $q) {
because If there is no version information on the DB, it is considered as
'CVS only', so it is only avaliable in latest version.
Sorry to be a pain, but can you list the specific issues that remain and
which
parts of your patch fix those things?
Part of the problem is that you're fixing too much in one patch, and it
makes
it difficult to see what's what.
Sorry, but I have tons of patches to livedocs... :) The issues adressed in
the patch I sent are:
* fixed a small problem with the message for outdated translations
* fetch english entites if the translated aren't avaliable (in
bind_entities)
* a fix for references pages, like SPL or Tidy (make_function_link)
* fix PCRE problem (handle_include)
* hard-coded a fix for dom
* small improvement for format_listing_hyperlink_function (don't link a
function if $id== $current_page)
I think thats all! ;-)
Nuno
Thanks,
--Wez.
RE: [PHP-DOC] livedocs PATCH
2/ Although I want to solve the dom problem, I don't want
to hard code dom
specifics into the guts of livedocs
So how? How do you know if you to append 'dom-' to the id?
There should be a generic mechanism to name functions based on the extension
that they are in.
3/ the version stuff is not phpdoc specific; it can happily
live in the
default theme.
No! PHPDOC is the only using the version stuff. With your
modified patch, it
works perfectly, because you are doing:
if ($q LATEST_VERSION == $q) {
This is correct.
and I think the correct version would be:
if (!$q || LATEST_VERSION == $q) {
because If there is no version information on the DB, it is
considered as
'CVS only', so it is only avaliable in latest version.
This is incorrect; read the comment in the source.
Not everything has version info (such as include/require) and this is showing
up incorrectly.
Sorry, but I have tons of patches to livedocs... :) The
issues adressed in
the patch I sent are:
* fixed a small problem with the message for outdated translations
* fetch english entites if the translated aren't avaliable (in
bind_entities)
* a fix for references pages, like SPL or Tidy (make_function_link)
* fix PCRE problem (handle_include)
* hard-coded a fix for dom
* small improvement for format_listing_hyperlink_function
(don't link a
function if $id== $current_page)
I think thats all! ;-)
Can you please post one patch per issue? (I know it's a pain in the ass)
--Wez.
Re: [PHP-DOC] livedocs PATCH
2/ Although I want to solve the dom problem, I don't want
to hard code dom
specifics into the guts of livedocs
So how? How do you know if you to append 'dom-' to the id?
There should be a generic mechanism to name functions based on the
extension
that they are in.
For, we should generate an id for ALL functions like $extension-$func_id?
3/ the version stuff is not phpdoc specific; it can happily
live in the
default theme.
No! PHPDOC is the only using the version stuff. With your
modified patch, it
works perfectly, because you are doing:
if ($q LATEST_VERSION == $q) {
This is correct.
and I think the correct version would be:
if (!$q || LATEST_VERSION == $q) {
because If there is no version information on the DB, it is
considered as
'CVS only', so it is only avaliable in latest version.
This is incorrect; read the comment in the source.
Not everything has version info (such as include/require) and this is
showing
up incorrectly.
But they could! :) Your patch has a problem. It matches only 'PHP 5?. And
what about 'PHP 5.1'?
You should use a substr() for example...
Can you please post one patch per issue? (I know it's a pain in the ass)
OMG...
OK, tomorrow or so, I'll do it.
Nuno
Re: [PHP-DOC] livedocs [PATCH] - allowing style_mapping to transform()
Wez Furlong [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Wouldn't it be better to do this in a RTL version of the style sheet (that just contains the RTL specific parts), and link to that sheet in addition to existing generic style sheet? Or are there other kinds of things that you need to do when generating the HTML? for this specific issue, overriding the default css can fit the needs, i just thought i adding here usefull flexibility for another usages (not rtl related). theoretically the align is not the only issue. there are map elements functions that i added and that cause to losing the attibutes, it's true that for now this behavior is harmless coz those elements are quite fundamental like 'varname' or 'term', but we opening here needless a gap of the rtl version comparing to the ltr (and loosing here nice way the documenters can hack the build system using tags attributes ;). sure that i can loop via the attibutes and add them but this looks to me unnecessary code duplication. --/moshe. --Wez. -Original Message- From: moshe doron [mailto:[EMAIL PROTECTED] Sent: 10 May 2004 14:10 To: [EMAIL PROTECTED] Subject: [PHP-DOC] livedocs [PATCH] - allowing style_mapping to transform() Hi: this patch allow style_mapping functions to continue transform the node via the default transform function: http://moshe.i-com-it.com/patchs/livedocs-styletransform.patch.txt i run into the issue when i see i have no elegant way override the text-align style using the transform function, without re-writing all the generation flow by hand. this behavior can be useful for small changes like duplication of childs nodes (e.g, make the first child title) or changing the html order of two node without manualy generating all the subnodes. explanations: 1. i splite the transform function into transform() that check if we calling to style_ function, and transfor_default() which is called if no style_ function. 2. if the map callback function begin with '+', the function suppose to get the $map beside the node. this map is moved into the $node-transform_default(). thoughts? --/moshe.
[PHP-DOC] livedocs on php4 - sqlite_single_query()
The following patch: http://cvs.php.net/diff.php/php-src/ext/sqlite/sqlite.c?r1=1.58r2=1.59ty=u is need to be adopted also for PHP_4_3 to make livedocs working on php4. in php4 there is no sqlite_single_query() function. --/moshe.
RE: [PHP-DOC] livedocs on php4 - sqlite_single_query()
pear upgrade sqlite % php -v PHP 4.3.6RC4-dev (cli) (built: Apr 9 2004 16:45:19) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies % php -r 'var_dump(function_exists(sqlite_single_query));' bool(true) -Original Message- From: moshe doron [mailto:[EMAIL PROTECTED] Sent: 10 May 2004 11:34 To: [EMAIL PROTECTED] Subject: [PHP-DOC] livedocs on php4 - sqlite_single_query() The following patch: http://cvs.php.net/diff.php/php-src/ext/sqlite/sqlite.c?r1=1.5 8r2=1.59ty=u is need to be adopted also for PHP_4_3 to make livedocs working on php4. in php4 there is no sqlite_single_query() function. --/moshe.
Re: [PHP-DOC] livedocs on php4 - sqlite_single_query()
my mistake. sorry. --/moshe. Wez Furlong [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] pear upgrade sqlite % php -v PHP 4.3.6RC4-dev (cli) (built: Apr 9 2004 16:45:19) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies % php -r 'var_dump(function_exists(sqlite_single_query));' bool(true)
[PHP-DOC] livedocs [PATCH] - allowing style_mapping to transform()
Hi: this patch allow style_mapping functions to continue transform the node via the default transform function: http://moshe.i-com-it.com/patchs/livedocs-styletransform.patch.txt i run into the issue when i see i have no elegant way override the text-align style using the transform function, without re-writing all the generation flow by hand. this behavior can be useful for small changes like duplication of childs nodes (e.g, make the first child title) or changing the html order of two node without manualy generating all the subnodes. explanations: 1. i splite the transform function into transform() that check if we calling to style_ function, and transfor_default() which is called if no style_ function. 2. if the map callback function begin with '+', the function suppose to get the $map beside the node. this map is moved into the $node-transform_default(). thoughts? --/moshe.
RE: [PHP-DOC] livedocs [PATCH] - allowing style_mapping to transform()
Wouldn't it be better to do this in a RTL version of the style sheet (that just contains the RTL specific parts), and link to that sheet in addition to existing generic style sheet? Or are there other kinds of things that you need to do when generating the HTML? --Wez. -Original Message- From: moshe doron [mailto:[EMAIL PROTECTED] Sent: 10 May 2004 14:10 To: [EMAIL PROTECTED] Subject: [PHP-DOC] livedocs [PATCH] - allowing style_mapping to transform() Hi: this patch allow style_mapping functions to continue transform the node via the default transform function: http://moshe.i-com-it.com/patchs/livedocs-styletransform.patch.txt i run into the issue when i see i have no elegant way override the text-align style using the transform function, without re-writing all the generation flow by hand. this behavior can be useful for small changes like duplication of childs nodes (e.g, make the first child title) or changing the html order of two node without manualy generating all the subnodes. explanations: 1. i splite the transform function into transform() that check if we calling to style_ function, and transfor_default() which is called if no style_ function. 2. if the map callback function begin with '+', the function suppose to get the $map beside the node. this map is moved into the $node-transform_default(). thoughts? --/moshe.
