[PHP-DOC] A thought or two on the early part of the PHP manual.
a note i made to myself a while back when first going thru the online PHP manual, so i thought i'd put it out there and let others ignore it at their leisure. i find the order of the two early sections -- getting started and installation and configuration -- a bit backwards since that earlier section assumes that PHP is, somehow, running to some extent as it gives the reader some samples to test. as an alternative, it would seem to make more sense to have the installation chapter first, but start it off with a prelim section along the lines of, is PHP already installed and can i skip the rest of this chapter? because i'm guessing that numerous linux distros will, if the web server is installed, also have PHP installed and ready to go. so before getting into *any* installation, it would save the reader a pile of time to have a quick checklist of what to look for to verify that PHP is on the system and behaving properly. and, to that end, a bit more complicated, but it might be worth expanding on what might or might not be installed depending on what you want to use PHP for. for instance, the manual currently talks about PHP being used for 3 purposes: * server-side (web) scripting * command line scripting * desktop (GUI) applications but depending on what you want it for, you may not have to install everything. for instance, if you want only command-line scripting, on fedora, you need install only the php-cli package, and so on. so one could write a short section explaining that, for which one would have to verify only that, on linux, you have the php utility installed. if you wanted to go further and do server-side web scripting, then there are more packages to install and verify. you get the idea. in any event, it would seem to make more sense to start things off by just asking the reader to look at his/her current system, run some commands to see what's there and, if they're lucky, conclude that they're all set to go and can skip the rest of the install chapter. thoughts? rday
[PHP-DOC] Hello world in PHP
probably about to embarrass myself but i'm looking at the PHP manual page Your first PHP-enabled page, which suggests this as an initial PHP program: html head titlePHP Test/title /head body ?php echo 'pHello World/p'; ? /body /html but if i enter, then browse to that page, i get as browser output: = hi world '; ? = um ... what's with those trailing characters? did i just do something hideously dumb? misconfiguration? rday
Re: [PHP-DOC] Hello world in PHP
Quoting Philip Olson phi...@roshambo.org: On Apr 30, 2010, at 7:35 AM, Robert P. J. Day wrote: probably about to embarrass myself but i'm looking at the PHP manual page Your first PHP-enabled page, which suggests this as an initial PHP program: html head titlePHP Test/title /head body ?php echo 'pHello World/p'; ? /body /html but if i enter, then browse to that page, i get as browser output: = hi world '; ? = um ... what's with those trailing characters? did i just do something hideously dumb? misconfiguration? Aside from the amazing mind reading ability of PHP to know you wanted 'hi' instead of 'hello', my guess is you do not have PHP enabled (at least, for the file extension you're using). first part was cut and paste error, argh. and, yes, i embarrassed myself as i was ssh'ed into the wrong test box which didn't even have the PHP package installed. and that, people, is the danger of drinking decaf. never forget it. rday
Re: [PHP-DOC] Hello world in PHP
Quoting Daniel Brown danbr...@php.net: On Fri, Apr 30, 2010 at 10:47, Robert P. J. Day rpj...@crashcourse.ca wrote: first part was cut and paste error, argh. and, yes, i embarrassed myself as i was ssh'ed into the wrong test box which didn't even have the PHP package installed. and that, people, is the danger of drinking decaf. never forget it. Incidentally, the closing remarks regarding decaf caused me to spit a mouthful of regular coffee onto my keyboard as I laughed (and subsequently choked a bit). Alas, the true definition of irony. hmmm ... apparently, it's not as simple as i thought. i'm on a test, fresh install of fedora 13 beta, i've installed apache 2 and started it, i've done a # yum install php and i can see: # rpm -qa *php* php-5.3.2-1.fc13.x86_64 php-cli-5.3.2-1.fc13.x86_64 php-common-5.3.2-1.fc13.x86_64 # i created /var/www/html/phpinfo.php which, unsurprisingly, simply runs phpinfo(), i've checked that there is a /etc/httpd/conf.d/php.conf file, i've verified that there is a shared object /usr/lib64/httpd/modules/libphp5.so ... and yet, when i browse to localhost's phpinfo.php, i see only (verbatim): ?php phpinfo(); ? httpd -M verifies that, yes, php5_module is loaded. so, again, what have i done stupidly? and even if it's a trivial solution, i'm going to verify that a fresh install of fedora 13 with both httpd and php doesn't support php, which is just weird. rday p.s. at this point, this clearly belongs on the main php list but, since i started it here, i might as well finish it here.
Re: [PHP-DOC] Hello world in PHP
Quoting Robert P. J. Day rpj...@crashcourse.ca: Quoting Daniel Brown danbr...@php.net: On Fri, Apr 30, 2010 at 10:47, Robert P. J. Day rpj...@crashcourse.ca wrote: first part was cut and paste error, argh. and, yes, i embarrassed myself as i was ssh'ed into the wrong test box which didn't even have the PHP package installed. and that, people, is the danger of drinking decaf. never forget it. Incidentally, the closing remarks regarding decaf caused me to spit a mouthful of regular coffee onto my keyboard as I laughed (and subsequently choked a bit). Alas, the true definition of irony. hmmm ... apparently, it's not as simple as i thought. i'm on a test, fresh install of fedora 13 beta, i've installed apache 2 and started it, i've done a # yum install php and i can see: # rpm -qa *php* php-5.3.2-1.fc13.x86_64 php-cli-5.3.2-1.fc13.x86_64 php-common-5.3.2-1.fc13.x86_64 # i created /var/www/html/phpinfo.php which, unsurprisingly, simply runs phpinfo(), i've checked that there is a /etc/httpd/conf.d/php.conf file, i've verified that there is a shared object /usr/lib64/httpd/modules/libphp5.so ... and yet, when i browse to localhost's phpinfo.php, i see only (verbatim): ?php phpinfo(); ? httpd -M verifies that, yes, php5_module is loaded. so, again, what have i done stupidly? and even if it's a trivial solution, i'm going to verify that a fresh install of fedora 13 with both httpd and php doesn't support php, which is just weird. *sigh*. never mind, just restarting apache seemed to do it. maybe i'll just start my weekend now. rday
Re: [PHP-DOC] User commentary in docs
On Tue, 6 Apr 2010, Rich Bowen wrote: A few of us on the Apache HTTP Server documentation team are investigating what it would take to add a user commentary system to the Apache HTTPD docs, like that used on the PHP docs. What software is used for that? Is it easily reusable in other places? Where can I get some more info about it? please reconsider that idea. as it is, there's simply too much nonsense that's been added by users at the PHP docs site. here's an example: http://www.php.net/manual/en/language.variables.php if you look closely at that page, it's simply a ***table of contents***, fer cryin' out loud. nevertheless, numerous commenters found it necessary to expound on it. for what conceivable purpose? if you want to support user commentary, the only sane way is to regularly peruse those comments, trash the garbage, and incorporate the reasonable comments into the documentation proper. just leaving the comments there in perpetuity is, IMHO, a terrible idea. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Re: [PHP-DOC] User commentary in docs
On Tue, 6 Apr 2010, Rasmus Lerdorf wrote: Robert, you could pitch in and help clean up and incorporate the comments then. I am sure Dan and the others would appreciate the help. There is simply too much user feedback and too few volunteers to get them all into the documentation in a timely manner. We found long ago that the best alternative was to have a quick way to get rid of bad comments and let the majority of stuff through because there really is some good contents in there. You may not like them, but I can tell you that the huge majority of feedback we get on them is positive. Almost everywhere I go, no matter where it is in the world, the user comments in the documentation is something people say they love about PHP. sorry, that last post of mine came across as unnecessarily harsh, and i apologize. sure, after i dig out from under my current project, i can probably help out. and, yes, there are the occasional gems of advice, no doubt about it. but you do appreciate my original observation regarding pages like this: http://www.php.net/manual/en/language.variables.php the fact that readers *can* comment should not suggest that they *must* comment. and, more importantly, they should try to comment on the appropriate page so that their comment makes sense. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Re: [PHP-DOC] What to do with PHP 6
On Tue, 30 Mar 2010, Philip Olson wrote: Hello everyone, As most of us know, PHP 6 has disappeared. It used to be 5.3+unicode but now it's unknown and certainly not worth mentioning in the PHP manual (at least, as a version that introduces features/changes). With that said, let's talk about what to do. First: $ egrep --exclude=\*.svn\* -r -n PHP 6 * |wc -l 105 Or, better than grep ;) $ ack PHP 6 * |wc -l 105 Around 13 are in versions.xml, and 51 in ini.xml. We must handle this as a case-by-basis because not all of these features are unicode specific, and even those that are may [or may not] be in the next PHP version for all we know... nobody really knows. Our options: (a) Remove or comment out the docs (a sad thought) (b) Make guesses as to which PHP version they'll be in (5.4 is likely for many, but easily wrong) (c) Move them to an appendix (doesn't feel right) (d) Write Future PHP Release or similar until we know (seems okay) (e) ... I lean towards (d) for most cases. Thoughts? call it PHP NG, with a huge early disclaimer that you're not sure what the number will be. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Re: [PHP-DOC] random observations on online PHP manual
On Mon, 22 Mar 2010, Richard Quadling wrote: On 21 March 2010 14:15, Robert P. J. Day rpj...@crashcourse.ca wrote: i wasn't suggesting reproducing the entire command-line section. i was more thinking along the lines of something early in the installation section, maybe a very first section, how can you tell if you have PHP installed already? if people are truly beginners, they may not even *know* if PHP is on their system. so a simple sequence of commands they can run, with a rationale for them, such as: $ type php # is it here and where is it? $ php -v # what version is it? $ php -m # what modules are loaded? $ php -h # get general help not only would this get a new reader at least typing a few commands, but you can recommend that if they *do* need to install, they can re-use this list as a sanity check to verify the install went well. you might also mention that when they eventually ask for help, people will ask them these very questions, what version are you running? what modules are loaded? For windows, the type php isn't the same command. Windows type is similar to cat. Assuming that PHP _is_ in the path, then, at the command line ... FOR %A IN (PHP.EXE) DO @ECHO %~$PATH:A will produce output of ... C:\PHP5\php.exe i'm aware it wouldn't work the same way under windows, i was just trying to propose a simple sanity test someone could run to verify that PHP seemed to be installed and working properly. naturally, you can tweak that text accordingly. and regarding installation, i would *strongly* encourage readers to install from packages if they can, leaving downloading and building the source as a last resort only. virtually every OS these days should have PHP and related packages ready to go. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Re: [PHP-DOC] random observations on online PHP manual
On Mon, 22 Mar 2010, Christopher Jones wrote: On 03/22/2010 04:42 AM, Robert P. J. Day wrote: and regarding installation, i would *strongly* encourage readers to install from packages if they can, leaving downloading and building the source as a last resort only. virtually every OS these days should have PHP and related packages ready to go. Some commonly used server platforms (e.g. RH Linux) favor keeping compatibility and don't ship current PHP releases. Installing from packages is often not the most appropriate choice - unless you like using PHP 4.3.9. Chris (who builds PHP RPMs and whose company sells Linux support) that's why i qualified with that with, if they can. but even with centos/RHEL, PHP 5.3-related packages are extremely easy to come by. it may be that you have to look for the generally-approved repos (in this case, http://rpms.famillecollet.com/enterprise/5/, among others), but they're easily findable. i stand by my position that having to download, configure and build from source should still be listed as a last resort for most sane, mainstream linux distros. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
[PHP-DOC] install page for openbsd could use some updating
here: http://www.php.net/manual/en/install.unix.openbsd.php that page seems stuck on PHP 4. some quick googling shows that phpxs isn't even available since PHP 4.3: http://www.mail-archive.com/openbsd-newb...@sfobug.org/msg00688.html and there's a whole openbsd page devoted to PHP 5: http://www.openbsd.org/4.4_packages/powerpc/php5-core-5.2.6.tgz-contents.html rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Re: [PHP-DOC] random observations on online PHP manual
On Sat, 20 Mar 2010, Philip Olson wrote: On Mar 20, 2010, at 8:00 AM, Robert P. J. Day wrote: ... extends the feature set adding SimpleXML and XMLReader support. - is there a reason to mention XMLReader but not XMLWriter? (what *is* the state of XML support in PHP these days? must keep reading.) That section is a bit outdated and easily forgotten. Please file a bug report about this being outdated. http://bugs.php.net/bug.php?id=51343 is that the proper format? rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
[PHP-DOC] building svn checkout of manual: BuildOptionsParser.php error
a short report on the latest attempt to checkout and build the manual from SVN. checkout worked fine, i installed phd, then ran build.sh, several lines of what looked like reasonable output, then: [09:25:09 - E_USER_ERROR ] /usr/share/pear/phpdotnet/phd/BuildOptionsParser.php:134 Invalid Package $ Couldn't get a file descriptor referring to the console am i just missing a required package? if so, that should be mentioned in the comments section of the build.sh script. or did i just do something dumb? rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Re: [PHP-DOC] random observations on online PHP manual
On Sat, 20 Mar 2010, Philip Olson wrote: On Mar 20, 2010, at 8:00 AM, Robert P. J. Day wrote: * very early on, i might be tempted to have a short section explaining how readers can examine the current state of PHP on their system, mostly from the command line. when i was starting out, i was thrilled to discover php -m. a short page walking readers through something like: $ php --help $ php -v $ php -m $ php -i and so on would probably not hurt, and it's something they could do with no further background, just to verify that they have a working and properly-configured PHP setup. Sounds useful, and the command line part was restructured recently so sections like this can be easily found (and pointed to) without getting lost. - http://php.net/manual/features.commandline So early on, this can be referenced. It's difficult to know where a tutorial should go but we lean towards having them within their specific topics, as opposed to being lumped together in the Getting Started tutorial. Although there really aren't many tutorials currently, eventually a tutorial index feels useful. i wasn't suggesting reproducing the entire command-line section. i was more thinking along the lines of something early in the installation section, maybe a very first section, how can you tell if you have PHP installed already? if people are truly beginners, they may not even *know* if PHP is on their system. so a simple sequence of commands they can run, with a rationale for them, such as: $ type php# is it here and where is it? $ php -v # what version is it? $ php -m # what modules are loaded? $ php -h # get general help not only would this get a new reader at least typing a few commands, but you can recommend that if they *do* need to install, they can re-use this list as a sanity check to verify the install went well. you might also mention that when they eventually ask for help, people will ask them these very questions, what version are you running? what modules are loaded? rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Re: [PHP-DOC] building svn checkout of manual: BuildOptionsParser.php error
On Sun, 21 Mar 2010, Hannes Magnusson wrote: On Sun, Mar 21, 2010 at 14:27, Robert P. J. Day rpj...@crashcourse.ca wrote: a short report on the latest attempt to checkout and build the manual from SVN. checkout worked fine, i installed phd, then ran build.sh, several lines of what looked like reasonable output, then: svn up and try again, there were couple of bugs in that script :] See http://svn.php.net/viewvc?view=revisionrevision=296477 just svn uped, at rev 296477, same error: [11:17:36 - E_USER_ERROR ] /usr/share/pear/phpdotnet/phd/BuildOptionsParser.php:134 Invalid Package [rpj...@localhost phpdoc-en]$ Couldn't get a file descriptor referring to the console this is on a reasonably up-to-date version of fedora 12. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Re: [PHP-DOC] building svn checkout of manual: BuildOptionsParser.php error
On Sun, 21 Mar 2010, Hannes Magnusson wrote: On Sun, Mar 21, 2010 at 14:27, Robert P. J. Day rpj...@crashcourse.ca wrote: a short report on the latest attempt to checkout and build the manual from SVN. checkout worked fine, i installed phd, then ran build.sh, several lines of what looked like reasonable output, then: svn up and try again, there were couple of bugs in that script :] See http://svn.php.net/viewvc?view=revisionrevision=296477 just FYI: $ pear remote-list -c doc.php.net Channel doc.php.net Available packages: === Package Version PhD 1.0.0 PhD_Generic 1.0.0 PhD_PHP 1.0.0 PhD_PEAR 1.0.0 PhD_GeSHi1.0.0 PhD_GeSHi11x 1.0.0 PhD_IDE -n/a- $ rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Re: [PHP-DOC] building svn checkout of manual: BuildOptionsParser.php error
On Sun, 21 Mar 2010, Hannes Magnusson wrote: Do note that I added the phd_php package as a requirement in the comments in build.sh ah, quite right. but why not just enhance the build.sh script to make it bulletproof, along the lines of: = #!/bin/sh # svn co http://svn.php.net/repository/phpdoc/modules/doc-en # pear install doc.php.net/phd # pear install doc.php.net/phd_php # cd doc-en pear info doc.php.net/PhD /dev/null 21 if [ $? 0 ] ; then echo You need to install the PEAR package PhD first, exiting. exit fi pear info doc.php.net/PhD_PHP /dev/null 21 if [ $? 0 ] ; then echo You need to install the PEAR package PhD_PHP first, exiting. exit fi ... etc etc ... = rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
[PHP-DOC] svn co and build of PHP manual could be clearer
in order to stay on top of things, i thought i'd svn co the development stream of the PHP manual, but it seems that doing that could be more clearly explained. starting here: http://www.php.net/download-docs.php there is no mention whatsoever about doing an svn checkout of the manual -- how to do that is buried partway down in the page here: http://php.net/svn.php it really should be mentioned on that first page, no? also, once i do the checkout: $ svn checkout http://svn.php.net/repository/phpdoc/en/trunk ./phpdoc-en there's nothing in that checkout that tells me how to configure and build the manual. i look in vain for a README or Makefile or configure script. a little searching and i eventually end up here: http://doc.php.net/php where, curiously, the PHP section link at the bottom refers back to itself. how odd. eventually, i follow the link labelled Documentation Howto over there on the right, looking for build instructions, but i still don't see them. i see directions for how to edit and validate XML files, but is there a single page with instructions for how to simply generate the manual HTML? rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
[PHP-DOC] random observations on online PHP manual
(my technical editor streak coming to the fore, representing just some thoughts on reading up to but not including the language reference so far.) * it's not clear what version of PHP the online manual refers to. i would *guess* that it's the output of a fairly recent build of the doc trunk, but it wouldn't hurt to make that explicitly clear at the beginning somewhere. * not sure if this is covered further into the manual than i've read so far, but i learned quickly that on some versions of linux (in my case, fedora), a *lot* of the PHP modules and extensions have been packages as yum-installable packages. a lot of the PEAR packages as well. i'm wondering if that's worth mentioning fairly early on for readers running particular linux distros. * http://www.php.net/manual/en/intro-whatis.php Don't be afraid [of?] reading the long list of PHP's features. * http://www.php.net/manual/en/intro-whatcando.php You can make a PHP script to run it without any server or browser. - that's a really awkward sentence ... extends the feature set adding SimpleXML and XMLReader support. - is there a reason to mention XMLReader but not XMLWriter? (what *is* the state of XML support in PHP these days? must keep reading.) * very early on, i might be tempted to have a short section explaining how readers can examine the current state of PHP on their system, mostly from the command line. when i was starting out, i was thrilled to discover php -m. a short page walking readers through something like: $ php --help $ php -v $ php -m $ php -i and so on would probably not hurt, and it's something they could do with no further background, just to verify that they have a working and properly-configured PHP setup. * http://www.php.net/manual/en/configuration.file.php - it might be worth telling the reader about php --ini here, and perhaps other ini-related php CLI options. i found the above comment really useful early on. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Re: [PHP-DOC] random observations on online PHP manual
On Sat, 20 Mar 2010, Robert P. J. Day wrote: - it might be worth telling the reader about php --ini here, and perhaps other ini-related php CLI options. i found the above comment really useful early on. bah ... i meant the above command, not comment. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Re: [PHP-DOC] svn co and build of PHP manual could be clearer
On Sat, 20 Mar 2010, Philip Olson wrote: The trouble with only downloading en/ (due to the incorrect svn checkout reference), you're missing the doc-base/ directory that the HOWTO refers to. So all the scripts, the README, but most importantly the configure.php script... you had no chance! :) that's what i had immediately assumed but, as you obviously realize, i was simply working off of what i read here: http://php.net/svn.php later this weekend, i'll svn up and see what it takes to build the docs from the checkout. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Re: [PHP-DOC] svn co and build of PHP manual could be clearer
On Sat, 20 Mar 2010, Philip Olson wrote: On Mar 20, 2010, at 9:04 AM, Robert P. J. Day wrote: On Sat, 20 Mar 2010, Philip Olson wrote: The trouble with only downloading en/ (due to the incorrect svn checkout reference), you're missing the doc-base/ directory that the HOWTO refers to. So all the scripts, the README, but most importantly the configure.php script... you had no chance! :) that's what i had immediately assumed but, as you obviously realize, i was simply working off of what i read here: http://php.net/svn.php later this weekend, i'll svn up and see what it takes to build the docs from the checkout. Yeah, thanks for discovering this most unfortunate bug. And you may as well delete that checkout because it'll never contain the proper structure. Eventually svn.php will update because it's fixed in SVN, and mirrors update about every hour. Or, checking out doc-base/ next to en/ works too. will do. i assume the eventually proper instructions for checking out the manual will be something like: 1) check out generic doc-base infrastructure, followed by 2) check out subdir of language of interest or something like that. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Re: [PHP-DOC] random observations on online PHP manual
first short reply before i must dash for a bit ... On Sat, 20 Mar 2010, Philip Olson wrote: On Mar 20, 2010, at 8:00 AM, Robert P. J. Day wrote: it's not clear what version of PHP the online manual refers to. i would *guess* that it's the output of a fairly recent build of the doc trunk, but it wouldn't hurt to make that explicitly clear at the beginning somewhere. It includes the build date on the opening page although not the SVN revision it's based on. I vaguely remember someone asking to insert the SVN revision before and a little brain storming on how took place but ... maybe one day. i don't think you need to be precise, it's just not clear whether the online manual closely tracks the svn repo, or whether it simply represents the latest *official* release (5.3.2), or what. just something simple in the preface clarifying that in general would be useful -- no need to get it to the svn revision level. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
Re: [PHP-DOC] random observations on online PHP manual
On Sat, 20 Mar 2010, Philip Olson wrote: On Mar 20, 2010, at 8:00 AM, Robert P. J. Day wrote: * not sure if this is covered further into the manual than i've read so far, but i learned quickly that on some versions of linux (in my case, fedora), a *lot* of the PHP modules and extensions have been packages as yum-installable packages. a lot of the PEAR packages as well. i'm wondering if that's worth mentioning fairly early on for readers running particular linux distros. A section within install/ that details the situation with linux distributions would probably be useful, as long as it's written to not require frequent updates. There is a section specific to Debian but I don't think every distro needs one... thoughts on making it generic? i don't think it requires much, maybe something as simple as: = a number of linux distributions have already pre-built a large number of PHP, PEAR and PECL packages that are available through their standard repositories. for instance, on fedora linux (and other distros that are yum based), it's a simple matter to search for relevant packages, using one or more of: # yum search php # yum search pear # yum search pecl then install the packages you want with # yum install list of desired packages = i don't see needing any more than the above. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
[PHP-DOC] Re: [PEAR-DOC] DocBook tags: literal versus firstterm
On Thu, 25 Feb 2010, Richard Quadling wrote: ... snip ... firstterm : This element marks the first occurrence of a word or term in a given context. (TDG) That certainly sounds like the tag to be used. The example TDG has is ... article xmlns='http://docbook.org/ns/docbook' titleExample firstterm/title paraIn an firsttermObject Oriented/firstterm programming language, data and procedures (called glosstermmethods/glossterm) are bound together. /para /article So, the tag is good and it is supported as part of the Generic package which both the PEAR and PHP PhD packages extend. i can submit a patch that adjusts a number of those tagged terms. can someone explain the proper svn diff incantation to post, along with the proper subject line, etc? i'm familiar with the concept of submitting patches, having submitted quite a number of them to the linux kernel mailing list. i just need to know the proper recipe for submitting them here. if there's a web page that explains that, all i need is the link. thanks. rday -- Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Kernel Pedantry. Web page: http://crashcourse.ca Twitter: http://twitter.com/rpjday
