[PHP-DOC] Re: [PHP-CVS] cvs: php-src /ext/standard array.c
Where do I edit the doc stuff again? Kalle Sommer Nielsen wrote: 2008/12/12 Andrei Zmievski : andrei Fri Dec 12 19:19:04 2008 UTC Modified files: /php-src/ext/standard array.c Log: Add sort flags parameter to array_unique(). http://cvs.php.net/viewvc.cgi/php-src/ext/standard/array.c?r1=1.467&r2=1.468&diff_format=u Guess it should have [DOC], cc'ed to phpdoc@ =)
[PHP-DOC] Re: [php-icu] APIs published
Probably after, so there's something to go against. -Andrei On Aug 1, 2007, at 9:19 AM, Vadim Savchuk wrote: Andrei Zmievski wrote: Anyone with access to phpdoc module can publish it. But it's probably best to contact phpdoc@ mailing list (and maybe Philip Olson) and let me them know you want to commit it. Ok. Should that be done after we import the sources into PECL, or doesn't matter? -- Vadim
[PHP-DOC] Re: [php-icu] APIs published
Anyone with access to phpdoc module can publish it. But it's probably best to contact phpdoc@ mailing list (and maybe Philip Olson) and let me them know you want to commit it. -Andrei On Jul 27, 2007, at 1:06 PM, Vadim Savchuk wrote: Stanislav Malyshev wrote: No, not yet. I'm quite busy right now, and probably will be till the end of the week, but I think everything but formatter unit tests and choosing right prefix for formatter (so far it's either formatter_ or numfmt_) is ready. Once we have decision on prefix I think we can check it in, but I'll be unable to do it until Monday, so if we want it earlier you can do it too. I've committed a few simple unit tests covering NumberFormatter API. They are not comprehensive nor nice, I just needed them when porting intl to PHP6. By the way, intl-php6 is finished now, and as far as I can see there's no need to create a separate CVS branch for it. Or there is? After unification of unit tests between intl's PHP5 and PHP6 svn branches I'm going to merge them together. That will be done by Monday, and intl will be ready for PECL. And what about intl's documentation (docbook) ? Who's going to publish t? -- Vadim
[PHP-DOC] Re: list of ref.unicode functions
Fair enough. I will propose a question to the list. My current idea is that the Unicode-related functions should be documented separately from the i18n functions. Your list ( http://philipolson.gotdns.org/unicode-file-list.txt ) doesn't seem complete, though: where is unicode-encode.xml ? In any case, from that list, everything starting with collator* or locale* should be in i18n section and the rest - in Unicode section. We also need a top-level section where we give intro to Unicode, how it works in PHP, new string types, operators, etc. -Andrei On Feb 6, 2007, at 11:42 AM, Philip Olson wrote: We could do a split on the unicode/i18n border. I think i18n will mainly be done in a new ext/icu extension. Everything that's in ext/unicode or in the core, should be documented together. The exception might be the collator, but we can talk about that. Just a fyi, before I do anything to ref.unicode you will need to either draw a clear line, by function, or you propose the question to the list with thoughts on the matter. In other words, I have no idea what to do so plan to do nothing at this point. The script produces 86 functions for ref.unicode. I think to move forward either you or Sara will need to be active on the doc mailing list (and/or #php.doc) at least for awhile. I don't mean to sound demanding, but rather, just want to be honest and tell you where I'm at. I look forward to helping make this happen! Regards, Philip
Re: [PHP-DOC] Starting on Unicode docs
Perhaps you could provide an example or two on "how to document a unicode change" as currently I for one would not know where to begin. Like the best way to go about finding [1] and documenting a unicode related change. And an estimate on about how many functions will eventually require documentation changes for this. 50, 200, 500, 1000, ...? The only reliable way is to read the source code, of course. :) But seriously, it might be tough for someone to pinpoint what Unicode-related changes have been done to a function. As an example, the notes for strtoupper() and strtolower() could say something like: These functions perform full case-mapping according to the Unicode standard [1]. Consequently, the length of the string may not be the same after the operation: it may become shorter or longer. [1] http://www.unicode.org/versions/Unicode4.0.0/ch05.pdf#G21180 As for how many functions will require documentation changes, it's hard to say, as we've only upgraded about 200 right now. I would say that about half of the string funcs may require some notes. Also, the doc team is sort of on vacation currently but once Livedocs [3] is online I have a feeling we'll make a concerted effort to attract additional help on all fronts. Makes sense. -Andrei
Re: [PHP-DOC] Starting on Unicode docs
Ah sure! Some protos may need changes, and some functions may need tweaking, of course. But all this will need to be made manually and thus will take a long time.. I think we can start by describing the general behaviour of the extension on the reference.xml page and then, as time permits, touch the function pages. It's not just the unicode extension that needs to be documented. There are plenty of changes affecting the whole language. -Andrei
Re: [PHP-DOC] Starting on Unicode docs
Yes, that's a good idea. :) Most of the functionality in the core language will not be changing so the documentation effort can start immediately. I would offer to document some things myself, but honestly, I think that my time is best spent finishing up core stuff, doing Unicode upgrades of core functions, and nagging other developers to upgrade their extensions. But I'm perfectly willing to provide answer about Unicode features to those who wish to start this documentation effort. -Andrei On Jul 19, 2006, at 2:52 PM, Philip Olson wrote: Ah yes, this makes sense and his last post did clarify that (hindsight is 20/20!). Sounds like a good idea to document all these types of changes so to the original question on when: ASAP! :-) Regards, Philip
Re: [PHP-DOC] Starting on Unicode docs
Fine, but what I was saying is that the behavior of number of functions will change, slightly or more than slightly, depending on unicode semantics mode being on or on the type of data passed to them. Those changes need to be documented. -Andrei On Jul 19, 2006, at 2:17 PM, Nuno Lopes wrote: I have already started documenting the Unicode stuff about one year ago (http://php.net/unicode). Most is already out-of-date, but it is a start point. What we were discussing is if we should change every page to mention that it is unicode-safe/aware/compatible/whatever. We were all against that because changing every single file would be a pain for us and mainly for the translators. All functions will be converted by the time PHP 6 is released, so there is no really interest in marking every single function as such. What we can do (and should) is to add some information to the reference.xml file about how the extension handles unicode data (for example, the xml extensions use utf8 internally because of libxml, etc..)
Re: [PHP-DOC] Starting on Unicode docs
I think this information could be useful since people will most likely want to use online manual even before PHP 6.0 final is out. Making them go to a separate site to look up which function is Unicode-safe or not is not very user-friendly. -Andrei Since all appropriate functions will be unicode compatible in PHP 6.0.0 this seems like information overload and not something that should be mentioned in every functions documentation. Perhaps have a list offsite, maybe on docweb, for alpha/beta testers.
Re: [PHP-DOC] Starting on Unicode docs
I think what we discussed last time was this: unicode - for parameters that are -required- to be Unicode strings binary - for parameters that are -required- to be binary strings string - for parameters that can be either type -Andrei On Jul 19, 2006, at 10:41 AM, Sean Coates wrote: Another thing that you and I have discussed, but I've never passed on to the list is the new proto markup for traditional strings vs. unicode strings vs. binary strings. Anyone got thoughts on this?
[PHP-DOC] Starting on Unicode docs
Hey guys, I just wanted to shoot a quick email to the list to see when we could start work on docs for Unicode upgrades (PHP 6). The main thing, IMO, is having a way to mark functions as Unicode compatible and also have a section (per-function) for any Unicode-related notes. Any other thoughts on this? -Andrei
[PHP-DOC] cvs: phpdoc /en/reference/pcre/functions preg-grep.xml preg-match-all.xml preg-match.xml
andrei Tue Jan 6 04:14:39 2004 EDT Modified files: /phpdoc/en/reference/pcre/functions preg-grep.xml preg-match-all.xml preg-match.xml Log: Document new flags, parameters. Index: phpdoc/en/reference/pcre/functions/preg-grep.xml diff -u phpdoc/en/reference/pcre/functions/preg-grep.xml:1.4 phpdoc/en/reference/pcre/functions/preg-grep.xml:1.5 --- phpdoc/en/reference/pcre/functions/preg-grep.xml:1.4Mon Dec 15 11:52:49 2003 +++ phpdoc/en/reference/pcre/functions/preg-grep.xmlTue Jan 6 04:14:39 2004 @@ -1,5 +1,5 @@ - + @@ -14,6 +14,7 @@ arraypreg_grep stringpattern arrayinput + intflags @@ -21,6 +22,25 @@ the elements of the input array that match the given pattern. + + + flags can be the following flag: + + + PREG_GREP_INVERT + + + If this flag is passed, preg_grep returns the + elements of the input array that do not match + the given pattern. + This flag is available since PHP 4.2.0. + + + + + The flags parameter is available since + PHP 4.3.0. + Since PHP 4.0.4, the results returned by preg_grep Index: phpdoc/en/reference/pcre/functions/preg-match-all.xml diff -u phpdoc/en/reference/pcre/functions/preg-match-all.xml:1.10 phpdoc/en/reference/pcre/functions/preg-match-all.xml:1.11 --- phpdoc/en/reference/pcre/functions/preg-match-all.xml:1.10 Fri Dec 19 10:49:44 2003 +++ phpdoc/en/reference/pcre/functions/preg-match-all.xml Tue Jan 6 04:14:39 2004 @@ -1,5 +1,5 @@ - + @@ -14,6 +14,7 @@ stringsubject arraymatches intflags + intoffset Searches subject for all matches to the regular @@ -111,7 +112,7 @@ PREG_OFFSET_CAPTURE - If this flag is set, for every occurring match the appendant string + If this flag is passed, for every occurring match the appendant string offset will also be returned. Note that this changes the return value in an array where every element is an array consisting of the matched string at offset 0 and it's string offset @@ -126,6 +127,17 @@ If no order flag is given, PREG_PATTERN_ORDER is assumed. + + + Normally, the search starts from the beginning of the subject string. The + optional parameter offset can be used to specify + the alternate place from which to start the search. It is equivalent to + passing substr($subject, $offset) to + preg_match in place of the subject string. + The offset parameter is available since + PHP 4.3.3. + + Returns the number of full pattern matches (which might be zero), or &false; if an error occurred. Index: phpdoc/en/reference/pcre/functions/preg-match.xml diff -u phpdoc/en/reference/pcre/functions/preg-match.xml:1.10 phpdoc/en/reference/pcre/functions/preg-match.xml:1.11 --- phpdoc/en/reference/pcre/functions/preg-match.xml:1.10 Fri Dec 19 10:49:44 2003 +++ phpdoc/en/reference/pcre/functions/preg-match.xml Tue Jan 6 04:14:39 2004 @@ -1,5 +1,5 @@ - + @@ -14,6 +14,7 @@ stringsubject arraymatches intflags + intoffset Searches subject for a match to the regular @@ -33,7 +34,7 @@ PREG_OFFSET_CAPTURE - If this flag is set, for every occurring match the appendant string + If this flag is passed, for every occurring match the appendant string offset will also be returned. Note that this changes the return value in an array where every element is an array consisting of the matched string at offset 0 and it's string offset into @@ -44,7 +45,17 @@ The flags parameter is available since - PHP 4.3.0 . + PHP 4.3.0. + + + + Normally, the search starts from the beginning of the subject string. The + optional parameter offset can be used to specify + the alternate place from which to start the search. It is equivalent to + passing substr($subject, $offset) to + preg_match in place of the subject string. + The offset parameter is available since + PHP 4.3.3.
[PHP-DOC] ext/tokenizer
I've removed EXPERIMENTAL status from ext/tokenizer. Anyone feel like documenting it? What's up there is woefully inadequate and just plain outdated. -Andrei http://www.gravitonic.com/ * I wish life had an UNDO function. * -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DOC] Smarty docs
On Wed, 27 Mar 2002, Gabor Hojtsy wrote: > Well, I can't give you any estimates on when this > central build system will be implemented, if ever... > So IMHO it would be the only one choice *meanwhile* > to duplicate the system... That's what I'm asking, can someone help me set up the build system and stylesheets so that documentation is rendered in website format? -Andrei Hacker: Any person who derives joy from discovering ways to circumvent limitations.
Re: [PHP-DOC] Smarty docs
On Wed, 27 Mar 2002, Hartmut Holzgraefe wrote: > >Sounds good to me, but I have neither the know-how nor the cycles to > >implement something like that. > > > >-Andrei > >* Entropy isn't what it used to be. * > > > > > > i'm afraid i've already voluntered for this Okay, but meanwhile am I supposed to recreate the build system for smarty-doc? -Andrei * Black holes are where God divided by zero. *
Re: [PHP-DOC] Smarty docs
On Wed, 27 Mar 2002, Gabor Hojtsy wrote: > As I said at the doc meeting, IMHO a "phpdoc-build" cvs repository > would be the best, with build scripts for all the cvs.php.net doc > projects, so we do not need to have 10 copies of the same build > system forked in various moments... That would make the updates, > and bugfixes extremely easy. And then there should not ne 10 people > working on 10 different build systems, but a few working on one. > The others can then work on documentation ;) Sounds good to me, but I have neither the know-how nor the cycles to implement something like that. -Andrei * Entropy isn't what it used to be. *
[PHP-DOC] Smarty docs
Hello, Soon Smarty (http://www.phpinsider.com/php/code/Smarty/) will be moving to smarty.php.net domain and I hope to set it up in the same way as PHP and PHP-GTK, that is, have a separate CVS module for documentation. We already have documentation in DocBook SGML format. If there is anyone on this list who wouldn't mind getting the docs to usual PHP specs (XML, build system, separate stylesheets for Web and simple HTML, etc), we would really appreciate the help. Please copy me on the replies, since I do not usually subscribe to this list. -Andrei * There is no knowledge that is not power. -- Ralph Waldo Emerson *
Re: [PHP-DOC] docs request
Yeah, looks good. You might want to give an example of using preserve_keys
option.
At 10:04 PM 11/10/01 +0100, Gabor Hojtsy wrote:
> > No. array_chunk() will split the input array into several sub-arrays
> > depending on the chunk length you specify. Try using
>array_chunk(array('a',
> > 'b', 'c', 'd', 'e'), 2).
>
>OK, I have added the docs, as:
>
>
>
> array_chunk
> Split an array into chunks
>
>
> Description
>
>
> array array_chunk
> array input
> int size
> bool
>preserve_keys
>
>
>
> array_chunk splits the array into
> several arrays with size values
> in them. You may also have an array with less values
> at the end. You get the arrays as members of a
> multidimensional array indexed with numbers starting
> from zero.
>
>
> By setting the optional preserve_keys
> parameter to &true;, you can force PHP to preserve the original
> keys from the input array. If you specify &false; new number
> indicies will be used in each resulting array with
> indices starting from zero. The default is &false;.
>
>
>
> array_chunk example
>
>$input_array = array('a', 'b', 'c', 'd', 'e');
>$output_array = array_chunk($input_array, 2);
>/*
> the structure of $output_array will be:
> array(
> array('a', 'b'),
> array('c', 'd'),
> array('e')
> )
>*/
>
>
>
>
>
>
>Hope it is correct :)
>
>Goba
-Andrei
Re: [PHP-DOC] docs request
At 07:02 PM 11/10/01 +0100, Hojtsy Gabor wrote:
>Isn't
>
> array_chunk($array, 2, TRUE);
>
>the same as
>
> array_slice($array, 0, 2);
>
>OK, it is not completely the same, as you
>cannot choose "do not preserve keys" while
>using array_slice(). Wouldn't it be better to
>extend array_slice() with another parameter,
>or something like that...
>
>These functions seem to me nearly the same
>(except of key preservation).
No. array_chunk() will split the input array into several sub-arrays
depending on the chunk length you specify. Try using array_chunk(array('a',
'b', 'c', 'd', 'e'), 2).
-Andrei
[PHP-DOC] docs request
It'd be nice if someone could document the new array_chunk() function I added and maybe overload extension as well. I currently don't have spare cycles to do it, but they are useful. -Andrei "Later in this talk, I intend to define the universe and give three examples." -- Larry Wall
Re: [PHP-DOC] cvs: phpdoc /en bookinfo.xml preface.xml /en/features connection-handling.xml cookies.xml error-handling.xml file-upload.xml http-auth.xml images.xml persistent-connections.xml remote-files.xml safe-mode.xml
On Mon, 13 Aug 2001, Jeroen van Wolffelaar wrote: > With xml, they are all colored blue... with me, that is, and that's not > vim60 apparantly. I don't know which version sysop installed... I'll ask > them to upgrade. Type :version. > I notice that the emacs comment is also mode-sgml, and not xml. > > > So, you are right, it should be xml from a meaning viewpoint. But the point > of that line is ease-for-the-user. For vim < 6, syntax=sgml works, and > syntax=xml doesn't. > > I noticed in the source of PHP a differentiation between vim6+ and vim<6, is > that appropriate here? Sure. > By the way, one question: How is the sgml rendering with vim600? Also okay, > or really bad? Is xml better than sgml there? I haven't tried sgml too much. XML works great for me, especially with indenting. -Andrei * Who is Ray and why would we want to selectively trace him? *
Re: [PHP-DOC] cvs: phpdoc /en bookinfo.xml preface.xml /en/features connection-handling.xml cookies.xml error-handling.xml file-upload.xml http-auth.xml images.xml persistent-connections.xml remote-files.xml safe-mode.xml
On Mon, 13 Aug 2001, Jeroen van Wolffelaar wrote: > True, it _is_ xml, but xml is very general, and that syntax doesn't > recognise the tags. sgml is a specify form of XML, the one used here... I > don't recall what it stands for, but it's in onde of the README's. You got it reversed, XML is a specific form of SGML. > Try it out with vim, if you say syntax=sgml, tags like 'para', 'simpara', > etc are colored yellow, but if they are not recognised, red. They are all colored fine for me.. I use vim60 though. The point is that we _are_ using XML Docbook files, not SGML, so the syntax should be set appropriately. -Andrei The 3 great virtues of a programmer: Laziness, Impatience, and Hubris. --Larry Wall
Re: [PHP-DOC] cvs: phpdoc /en bookinfo.xml preface.xml /en/features connection-handling.xml cookies.xml error-handling.xml file-upload.xml http-auth.xml images.xml persistent-connections.xml remote-files.xml safe-mode.xml
On Mon, 13 Aug 2001, Jeroen van Wolffelaar wrote: > jeroenMon Aug 13 14:56:32 2001 EDT > > Modified files: > /phpdoc/enbookinfo.xml preface.xml > /phpdoc/en/features connection-handling.xml cookies.xml > error-handling.xml file-upload.xml > http-auth.xml images.xml > persistent-connections.xml remote-files.xml > safe-mode.xml > Log: > Standardized comment at the end of XML-files (includes vi-line too now) > > > Index: phpdoc/en/bookinfo.xml > diff -u phpdoc/en/bookinfo.xml:1.13 phpdoc/en/bookinfo.xml:1.14 > --- phpdoc/en/bookinfo.xml:1.13 Sun Aug 5 06:51:43 2001 > +++ phpdoc/en/bookinfo.xmlMon Aug 13 14:56:21 2001 > @@ -1,4 +1,4 @@ > - > + > > > > @@ -93,4 +93,5 @@ > sgml-local-catalogs:nil > sgml-local-ecat-files:nil > End: > +vi: et:ts=1:sw=1:textwidth=78:syntax=sgml Shouldn't it be syntax=xml? -Andrei Any sufficiently advanced Operating System is indistinguishable from Linux. - Jim Dennis
Re: [PHP-DOC] Filtering out translations?
On Tue, 17 Jul 2001, Hartmut Holzgraefe wrote: > looks like another argument for splitting up the phpdoc repository > into a base module containing infrastructure and english original > and one seperate module for each translation language ... That's not going to help you if all the commits for those modules still come to php-doc. You'd need separate mailing lists as well, but I don't think it's a good idea.. -Andrei "I still find each day too short for all the thoughts I want to think, all the walks I want to take, all the books I want to read, and all the friends I want to see." -John Burroughs
Re: [PHP-DOC] knock knock
Yeah? On Tue, 19 Jun 2001, Damien Seguy wrote: > anyone home yet > -Andrei * We reason deeply, when we forcibly feel. *
[PHP-DOC] Re: [PHP-DEV] Re: [PHP-DOC] Fwd: Re: [PHP-DEV] Using $HTTP_SESSION_VARS with register_globals On
On Tue, 22 May 2001, Hojtsy Gabor wrote: > Aha. This caused some really bad 'bugs' in the new PHP release... > I didn't know why it was bad... Please revert to the same method > as $HTTP_*_VARS use... Excuse me? I'm quite confused by your message. Do you mean that $HTTP_SESSION_VARS['foo'] and $foo should not be references to the same value? -Andrei * Life may be expensive, but it includes an annual free trip around the sun. *
Re: [PHP-DOC] phpdoc CVS and translations
Your reply seems targeted at Hartmut instead of me. On Thu, 10 May 2001, [EMAIL PROTECTED] wrote: > On Thu, May 10, 2001 at 09:37:14AM -0500, Andrei Zmievski wrote: > > On Thu, 10 May 2001, Hartmut Holzgraefe wrote: > > > i know that this is possible, but it is very unconvenient IMHO > > > > > > first, "cvs co -l phpdoc" would not be enough, as you'll need the > > > dbxml-, images- and perhaps howto-subdirectories, too > > > > So? cvs upd -d howto dbxml should do quite nicely. > > I'm against a split into different languages. 23 MB could be handled even > with my old 14.4 kB modem. Look at the size for phpweb. > > > > and not using the -d option is leading to problems whenever a new > > > subdirectory is added to the toplevel or 'en'-directory > > > > Since en/ is your main working directory you can just run cvs upd -d > > from there when you want to update or put "upd -d" in your .cvsrc file. > > All the years I have used "cvs -z9 update -dP" and had no problems. With > branching and so on I have problems. > > > > ok, right now this does not happen that often, but i'm also thinking > > > about > > > an improved translation infrastructure that would pull in english > > > versions at the function level instead of the extension level as we > > > have it now (we have a lot of translations that are not that up to date > > > right now, but usually this hurts due to missing functions that were > > > added after the translation and not so much due to the translated > > > parts being outdated) > > > > Having each function in a separate file? Ack.. > > I have discussed this with Hartmut. This is a nice idea, but there is > actually now way to split the manual into subdirectories (extensions) and > then each function in a separate file. > > > > so after all i'd prefere to have the translations as seperate modules > > > in CVS > > > > > > nothing would change for those of us only working on the original > > > > > > translators would have to check out the original first as usual with > > > > > > cvs co phpdoc > > > > > > and would have to additionaly get their translation language(s) of > > > choice > > > > > > cd phpdoc > > > cvs co -d de phpdoc-de > > > > > > for example > > > (similar to what you have to do with Zend and TSRM in the php4 source) > > > > > > this is a little additional inconvenience on the initial checkout but > > > after that you don't have to worry about your cvs settings anymore > > > > I suppose if there is a really big desire for this from more than one > > person, than we could setup aliases in CVSROOT/modules for phpdoc: > > > > phpdoc -a !de !it !nl phpdoc > > phpdoc-de -d de phpdoc/de > > > > Or something like that. > > I can live with the current situation. If not I'll remove some unecessary > functions to keep the manual small. rtfm() for example :) > > -Egon > > -- > LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/ > All known books about PHP and related books: http://php.net/books.php > Concert Band of the University of Hohenheim: http://www.concert-band.de/ > First and second bestselling book in German: http://www.php-buch.de/ -Andrei * Change is the only constant. *
Re: [PHP-DOC] phpdoc CVS and translations
On Thu, 10 May 2001, Hartmut Holzgraefe wrote: > do you have a better idea on how to solve the 'missing functions' > problem in translation? Write a little tool in PHP that uses XML parser to gather all documented functions in en/functions/imap.xml and de/functions/imap.xml, compares them, and gives you the result. -Andrei "You choose to do the bad things in your life; the good ones come and drag you along with them." - Michael Marshall Smith
Re: [PHP-DOC] phpdoc CVS and translations
On Thu, 10 May 2001, Hartmut Holzgraefe wrote: > i know that this is possible, but it is very unconvenient IMHO > > first, "cvs co -l phpdoc" would not be enough, as you'll need the > dbxml-, images- and perhaps howto-subdirectories, too So? cvs upd -d howto dbxml should do quite nicely. > and not using the -d option is leading to problems whenever a new > subdirectory is added to the toplevel or 'en'-directory Since en/ is your main working directory you can just run cvs upd -d from there when you want to update or put "upd -d" in your .cvsrc file. > ok, right now this does not happen that often, but i'm also thinking > about > an improved translation infrastructure that would pull in english > versions at the function level instead of the extension level as we > have it now (we have a lot of translations that are not that up to date > right now, but usually this hurts due to missing functions that were > added after the translation and not so much due to the translated > parts being outdated) Having each function in a separate file? Ack.. > so after all i'd prefere to have the translations as seperate modules > in CVS > > nothing would change for those of us only working on the original > > translators would have to check out the original first as usual with > > cvs co phpdoc > > and would have to additionaly get their translation language(s) of > choice > > cd phpdoc > cvs co -d de phpdoc-de > > for example > (similar to what you have to do with Zend and TSRM in the php4 source) > > this is a little additional inconvenience on the initial checkout but > after that you don't have to worry about your cvs settings anymore I suppose if there is a really big desire for this from more than one person, than we could setup aliases in CVSROOT/modules for phpdoc: phpdoc -a !de !it !nl phpdoc phpdoc-de -d de phpdoc/de Or something like that. -Andrei The main reason Santa is so jolly is because he knows where all the bad girls live. -- George Carlin
Re: [PHP-DOC] phpdoc CVS and translations
On Thu, 10 May 2001, Hartmut Holzgraefe wrote: > > with a total of ~23MB (and a potential total of currently 10x4.4MB) > in the translation subdirectories i'd suggest we try to find a way > to have each translation in a seperate CVS module > > the avarage translator will be working on one language only so > he should just have to checkout the original manual (infrastructure > and 'en' files) and the module for his native language, giving > his line and disk a break (and cvs.php.net's line too) > > any comments or suggestions? Yes, they can just check out a certain subdirectory of phpdoc along with the top one and keep it that way. cvs co -l phpdoc cvs co phpdoc/en Then they only have to use cvs upd without -d option to update only files existing in their local working copy. -Andrei * We are not a clone. *
Re: [PHP-DOC] bool/boolean and int/integer
On Thu, 10 May 2001, Damien Seguy wrote: > Hi, > > I noticed that docs are using sometimes bool, sometimes boolean to > describe boolean values. Save for integer and int. > > It seems that most frequent occurences are "int" and "bool". Is that > a general rule? I suggest we could harmonize all of this, with only > one expression. > > What do you think? bool sounds fine to me. -Andrei "I think it would be a good idea." -- Mahatma Gandhi, when asked what he thought of Western civilization...
[PHP-DOC] cvs: phpdoc /en/functions pcre.xml
andrei Mon Apr 30 18:04:06 2001 EDT Modified files: /phpdoc/en/functionspcre.xml Log: Wrong modifier name. Index: phpdoc/en/functions/pcre.xml diff -u phpdoc/en/functions/pcre.xml:1.48 phpdoc/en/functions/pcre.xml:1.49 --- phpdoc/en/functions/pcre.xml:1.48 Tue Mar 13 04:59:20 2001 +++ phpdoc/en/functions/pcre.xmlMon Apr 30 18:04:06 2001 @@ -712,7 +712,7 @@ matches only at the start of the string, while the "end of line" metacharacter ($) matches only at the end of the string, or before a terminating newline (unless - E modifier is set). This is the same as + D modifier is set). This is the same as Perl.
Re: [PHP-DOC] cvs: phpdoc /en/functions rtfm.xml
On Fri, 27 Apr 2001, Hojtsy Gabor wrote: > Hartmut please inform Egon about this feature. > He deleted all the rtfm files last day: > > | eschmid Thu Apr 26 20:51:37 2001 EDT > | > | Removed files: > |/phpdoc/en/functions rtfm.xml > |/phpdoc/de/functions rtfm.xml > |/phpdoc/nl/functions rtfm.xml > | Log: > | No comment. > > It seemd he seen it as a bad joke... So do I, for that matter. -Andrei "Tomorrow the sun will rise. And who knows what the tide will bring?" - Tom Hanks, in "Cast Away"
Re: [PHP-DOC] PHP easter Egg
On Mon, 23 Apr 2001, Damien Seguy wrote: > Hi, > > Here are some PHP easter Egg. > Should we document those? > add this to any PHP 4 script : > > ?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 > ?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 > ?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 > > This will bring some easter egg picture right from PHP > > Any suggestion? What's the point of Easter Egg if it's documented. I do wish these were a bit easier to access. :) -Andrei * It said 'Winmodem' on the box, but I still feel like I lost. *
Re: [PHP-DOC] command line arguments
On Sat, 14 Apr 2001, Roel Vanhout wrote: > Hi all, > > I was wondering if it is possible to get command line arguments when > using php as a standalone executable. Something getopt()'ish would be > great, but that's probably too much to ask :-) Check Console/Getopt.php class in PEAR. -Andrei Magic 8-ball is much more powerful than we thought. I mean, back in the 70's it was predicting the nature of software in the 90's -- "Outlook not so good".
Re: [PHP-DOC] cvs: phpdoc /en/functions classobj.xml
On Tue, 27 Mar 2001, Daniel Beckham wrote: > danbeck Tue Mar 27 10:07:37 2001 EDT > > Modified files: > /phpdoc/en/functions classobj.xml > Log: > added note as per Andrei > > Index: phpdoc/en/functions/classobj.xml > diff -u phpdoc/en/functions/classobj.xml:1.16 phpdoc/en/functions/classobj.xml:1.17 > --- phpdoc/en/functions/classobj.xml:1.16 Tue Mar 27 09:33:36 2001 > +++ phpdoc/en/functions/classobj.xml Tue Mar 27 10:07:37 2001 > @@ -345,6 +345,17 @@ > This function returns an array of method names defined for the > class specified by class_name. > > + > + > + As of PHP 4.0.5, you can specify the class itself instead of I would say 'class instance' or 'object'. -Andrei * Non-volatile, random-access, analog memory store... a book. *
Re: [PHP-DOC] cvs: phpdoc /en/functions classobj.xml
On Tue, 27 Mar 2001, Daniel Beckham wrote: > Ah, ok.. weird though. Why have two functions that do essentially the same > exact thing? That's just the way it happened. -Andrei "The only true currency in this bankrupt world is what we share with each other when we're uncool." -- Lester Bangs, from the film 'Almost Famous'
Re: [PHP-DOC] cvs: phpdoc /en/functions classobj.xml
On Tue, 27 Mar 2001, Daniel Beckham wrote: > Cool, can this be used with get_class_vars() also? If not, it would be a > logical change to go along with get_class_methods(). There is already get_object_vars(). But get_parent_class() got the same change yesterday. -Andrei * What were the first 15 billion years of the universe like for you? *
Re: [PHP-DOC] cvs: phpdoc /en/functions classobj.xml
On Tue, 27 Mar 2001, Daniel Beckham wrote: > +$my_class = new myclass(); > + > +$class_methods = get_class_methods(get_class($my_class)); Since yesterday, you can also do get_class_methods($my_class) directly. -Andrei "The human brain is a wonderful thing. It starts working the moment you are born, and never stops until you stand up to speak in public. " -- Sir George Jessel
[PHP-DOC] cvs: phpdoc /en/functions pcre.xml
andrei Mon Mar 12 21:24:40 2001 EDT Modified files: /phpdoc/en/functionspcre.xml Log: Removed docs for /F modifier, added docs for preg_replace_callback(). Index: phpdoc/en/functions/pcre.xml diff -u phpdoc/en/functions/pcre.xml:1.46 phpdoc/en/functions/pcre.xml:1.47 --- phpdoc/en/functions/pcre.xml:1.46 Thu Mar 8 02:47:17 2001 +++ phpdoc/en/functions/pcre.xmlMon Mar 12 21:24:39 2001 @@ -373,13 +373,6 @@ the line containing preg_replace. -/F modifier means that the -replacement is taken to be a function name. This -function will be called and passed an array of matched elements in the -subject string. The function should return the replacement string. This -modifier was added in PHP 4.0.4. - - Replacing several values @@ -457,6 +450,38 @@ + + +preg_replace_callback +Perform a regular expression search and replace using a +callback + + +Description + + + mixed preg_replace + mixed pattern + mixed callback + mixed subject + int + limit + + + + + The behavior of this function is almost identical to + preg_replace, except for the fact that instead of + replacement parameter, once should specify a + callback that will be called and passed an array of + matched elements in the subject string. The callback should return the + replacement string. This function was added in PHP 4.0.5. + + + See also preg_replace. + + + + preg_split @@ -739,30 +764,11 @@ If this modifier is set, preg_replace does normal substitution of backreferences in the replacement string, evaluates it as PHP code, and uses the - result for replacing the search string. This modifier cannot - be used along with /F modifier. + result for replacing the search string. Only preg_replace uses this modifier; it is ignored by other PCRE functions. - - - - - F - - - If this modifier is set, preg_replace - treats the replacement parameter as a function name that - should be called to provide the replacement string. The - function is passed an array of matched elements in the - subject string. This modifier cannot be used along with - /e modifier. - - - Only preg_replace uses this modifier; - it is ignored by other PCRE functions. This modifier was - added in PHP 4.0.4.
Re: [PHP-DOC] Still locked?
At 05:20 PM 2/24/01 -0700, Ron Chmara wrote: >[16:16:57] waiting for nobody's lock in /repository/phpdoc/en/chapters > >It's now been a week or three I've cleared the lock. -Andrei
[PHP-DOC] cvs: phpdoc / global.ent
andrei Wed Feb 21 06:23:48 2001 EDT Modified files: /phpdoc global.ent Log: Forgot to commit url.pcre addition. Index: phpdoc/global.ent diff -u phpdoc/global.ent:1.76 phpdoc/global.ent:1.77 --- phpdoc/global.ent:1.76 Wed Feb 7 03:56:28 2001 +++ phpdoc/global.ent Wed Feb 21 06:23:47 2001 @@ -1,6 +1,6 @@
[PHP-DOC] cvs: phpdoc /en/functions pcre.xml
andrei Tue Feb 20 14:04:44 2001 EDT Modified files: /phpdoc/en/functionspcre.xml Log: Let people know the person behind the actual library. Index: phpdoc/en/functions/pcre.xml diff -u phpdoc/en/functions/pcre.xml:1.40 phpdoc/en/functions/pcre.xml:1.41 --- phpdoc/en/functions/pcre.xml:1.40 Mon Feb 19 11:38:18 2001 +++ phpdoc/en/functions/pcre.xmlTue Feb 20 14:04:44 2001 @@ -54,7 +54,12 @@ The Perl-compatible regular expression functions are available in PHP 4 and in PHP 3.0.9 and up. - + + +Regular expression support is provided by the PCRE library package, which is +open source software, written by Philip Hazel, and copyright by the University +of Cambridge, England. It is available at &url.pcre;. +
[PHP-DOC] cvs: phpdoc /en/functions array.xml
andrei Tue Feb 20 06:23:56 2001 EDT Modified files: /phpdoc/en/functionsarray.xml Log: Rename to array_search(). Index: phpdoc/en/functions/array.xml diff -u phpdoc/en/functions/array.xml:1.57 phpdoc/en/functions/array.xml:1.58 --- phpdoc/en/functions/array.xml:1.57 Tue Feb 20 00:13:49 2001 +++ phpdoc/en/functions/array.xml Tue Feb 20 06:23:56 2001 @@ -1821,14 +1821,14 @@ - See also search_array. + See also array_search. - + -search_array +array_search Searches the array for a given value and returns the corresponding key if successful @@ -1837,7 +1837,7 @@ Description - mixed search_array + mixed array_search mixed needle array haystack bool strict @@ -1850,7 +1850,7 @@ If the third parameter strict is set to - TRUE then the search_array + TRUE then the array_search will also check the types of the needle in the haystack.
[PHP-DOC] cvs: phpdoc /en/functions pcre.xml
andrei Mon Feb 19 11:38:18 2001 EDT
Modified files:
/phpdoc/en/functionspcre.xml
Log:
Document preg_split() limit parameter and new flag.
Index: phpdoc/en/functions/pcre.xml
diff -u phpdoc/en/functions/pcre.xml:1.39 phpdoc/en/functions/pcre.xml:1.40
--- phpdoc/en/functions/pcre.xml:1.39 Thu Feb 8 02:27:59 2001
+++ phpdoc/en/functions/pcre.xmlMon Feb 19 11:38:18 2001
@@ -483,13 +483,35 @@
- If limit is specified, then only substrings
- up to limit are returned.
+If limit is specified, then only substrings up to
+limit are returned, and if
+limit is -1, it actually means "no limit", which is
+useful for specifying the flags.
- If flags is PREG_SPLIT_NO_EMPTY then only
- non-empty pieces will be returned by preg_split.
+flags can be any combination of the following flags
+(combined with bitwise | operator):
+
+
+ PREG_SPLIT_NO_EMPTY
+
+
+If this flag is set, only non-empty pieces will be returned by
+preg_split.
+
+
+
+
+ PREG_SPLIT_DELIM_CAPTURE
+
+
+If this flag is set, parenthesized expression in the delimiter pattern
+will be captured and returned as well. This flag was added for 4.0.5.
+
+
+
+
@@ -508,7 +530,7 @@
$str = 'string';
-$chars = preg_split('//', $str, 0, PREG_SPLIT_NO_EMPTY);
+$chars = preg_split('//', $str, -1, PREG_SPLIT_NO_EMPTY);
print_r($chars);
[PHP-DOC] cvs: phpdoc /en/functions pcre.xml
andrei Tue Jan 30 19:16:24 2001 EDT Modified files: /phpdoc/en/functionspcre.xml Log: Note about preg_grep(). Index: phpdoc/en/functions/pcre.xml diff -u phpdoc/en/functions/pcre.xml:1.37 phpdoc/en/functions/pcre.xml:1.38 --- phpdoc/en/functions/pcre.xml:1.37 Tue Jan 30 00:56:36 2001 +++ phpdoc/en/functions/pcre.xmlTue Jan 30 19:16:23 2001 @@ -605,6 +605,12 @@ the given pattern. + Since PHP 4.0.4, the results returned by preg_grep + are indexed using the keys from the input array. If this behavior is + undesirable, use array_values on the array returned by + preg_grep to reindex the values. + + preg_grep example
[PHP-DOC] cvs: phpdoc /en/functions pcre.xml
andrei Mon Jan 22 14:27:42 2001 EDT
Modified files:
/phpdoc/en/functionspcre.xml
Log:
Docs for /F modifier and matching delimeters.
Index: phpdoc/en/functions/pcre.xml
diff -u phpdoc/en/functions/pcre.xml:1.34 phpdoc/en/functions/pcre.xml:1.35
--- phpdoc/en/functions/pcre.xml:1.34 Wed Nov 15 07:01:03 2000
+++ phpdoc/en/functions/pcre.xmlMon Jan 22 14:27:41 2001
@@ -6,10 +6,11 @@
The syntax for patterns used in these functions closely resembles
Perl. The expression should be enclosed in the delimiters, a
-forward slash (/), for example. Any character can be used for
+forward slash (/), for example. Any character can be used for
delimiter as long as it's not alphanumeric or backslash (\). If
the delimiter character has to be used in the expression itself,
-it needs to be escaped by backslash.
+it needs to be escaped by backslash. Since PHP 4.0.4, you can also use
+Perl-style (), {}, [], and <> matching delimiters.
The ending delimiter may be followed by various modifiers that
@@ -23,6 +24,7 @@
/<\/\w+>/
|(\d{3})-\d+|Sm
/^(?i)php[34]/
+ {^\s+(\s+)?$}
@@ -363,6 +365,13 @@
the line containing preg_replace.
+/F modifier means that the
+replacement is taken to be a function name. This
+function will be called and passed an array of matched elements in the
+subject string. The function should return the replacement string. This
+modifier was added in PHP 4.0.4.
+
+
Replacing several values
@@ -694,11 +703,29 @@
If this modifier is set, preg_replace
does normal substitution of backreferences in the
replacement string, evaluates it as PHP code, and uses the
- result for replacing the search string.
+ result for replacing the search string. This modifier cannot be used along
+ with /F modifier.
Only preg_replace uses this modifier;
it is ignored by other PCRE functions.
+
+
+
+
+ F
+
+
+ If this modifier is set, preg_replace
+ treats the replacement parameter as a function name that should be called
+ to provide the replacement string. The function is passed an array of
+ matched elements in the subject string. This modifier cannot be used along
+ with /e modifier.
+
+
+ Only preg_replace uses this modifier;
+ it is ignored by other PCRE functions. This modifier was added in PHP
+ 4.0.4.
[PHP-DOC] cvs: phpdoc /en/functions strings.xml
andrei Mon Jan 22 13:48:59 2001 EDT
Modified files:
/phpdoc/en/functionsstrings.xml
Log:
Docs for str_replace() improvements.
Index: phpdoc/en/functions/strings.xml
diff -u phpdoc/en/functions/strings.xml:1.70 phpdoc/en/functions/strings.xml:1.71
--- phpdoc/en/functions/strings.xml:1.70Sat Jan 20 11:15:05 2001
+++ phpdoc/en/functions/strings.xml Mon Jan 22 13:48:59 2001
@@ -2944,28 +2944,49 @@
str_replace
- Replace all occurrences of needle in haystack with str
+ Replace all occurrences of the search string in subject with the replacement
+string
Description
- string str_replace
- string needle
- string str
- string haystack
+ mixed str_replace
+ mixed search
+ mixed replace
+ mixed subject
- This function replaces all occurences of
- needle in haystack
- with the given str. If you don't need
- fancy replacing rules, you should always use this function
- instead of ereg_replace.
+ This function replaces all occurences of search in
+ subject with the given
+ replace value. If you don't need fancy replacing
+ rules, you should always use this function instead of
+ ereg_replace or
+ preg_replace.
+ In PHP 4.0.5 and later, every parameter to
+ str_replace can be an array.
+
+
+ If subject is an array, then the search and replace
+ is performed on every entry of subject, and the
+ return value is an array as well.
+
+
+ If search and replace are
+ arrays, then str_replace takes a value from each
+ array and uses them to do search and replace on
+ subject. If replace has
+ fewer values than search, then an empty string is
+ used for the rest of replacement values. If search
+ is an array and replace is a string; then this
+ replacement string is used for every value of
+ search. The converse would not make sense, though.
+
+
- Str_replace example
+ str_replace example
$bodytag = str_replace ("%body%", "black", "");
@@ -2976,13 +2997,13 @@
- Str_replace was added in PHP 3.0.6, but was
+ str_replace was added in PHP 3.0.6, but was
buggy up until PHP 3.0.8.
- See also ereg_replace and
- strtr.
+ See also ereg_replace,
+ preg_replace, and strtr.
[PHP-DOC] cvs: phpdoc /en/functions array.xml
andrei Mon Jan 22 09:44:34 2001 EDT Modified files: /phpdoc/en/functionsarray.xml Log: Add docs about new functionality of extract(). Index: phpdoc/en/functions/array.xml diff -u phpdoc/en/functions/array.xml:1.49 phpdoc/en/functions/array.xml:1.50 --- phpdoc/en/functions/array.xml:1.49 Mon Jan 8 13:20:31 2001 +++ phpdoc/en/functions/array.xml Mon Jan 22 09:44:34 2001 @@ -1640,46 +1640,57 @@ - Extract checks for colissions with existing - variables. The way collisions are treated is determined by - extract_type. It can be one of the + extract checks each key to see whether if constitutes + a valid variable name and also for collisions with existing variables in + the symbol table. The way invalid/numeric keys and collisions are treated + is determined by extract_type. It can be one of the following values: EXTR_OVERWRITE - -If there is a collision, overwrite the existing variable. - + + If there is a collision, overwrite the existing variable. + EXTR_SKIP - -If there is a collision, don't overwrite the existing -variable. - + + If there is a collision, don't overwrite the existing + variable. + EXTR_PREFIX_SAME - -If there is a collision, prefix the new variable with -prefix. - +If there is a collision, prefix the variable name with +prefix. + EXTR_PREFIX_ALL - -Prefix all variables with prefix. - + + Prefix all variable names with prefix. Since PHP + 4.0.5 this includes numeric ones as well. + + + EXTR_PREFIX_INVALID + + + Only prefix invalid/numeric variable names with + prefix. This flag has been added in PHP 4.0.5. + + + + If extract_type is not specified, it is @@ -1687,13 +1698,13 @@ Note that prefix is only required if - extract_type is EXTR_PREFIX_SAME or - EXTR_PREFIX_ALL. + extract_type is EXTR_PREFIX_SAME, EXTR_PREFIX_ALL, + or EXTR_PREFIX_INVALID. If the prefixed result is not a valid variable + name, it is not imported into the symbol table. - Extract checks each key to see if it - constitues a valid variable name, and if it does only then does - it proceed to import it. + extract returns the number of variables successfully + imported into the symbol table. A possible use for extract is to import into symbol table
[PHP-DOC] cvs: phpdoc /en/functions datetime.xml
andrei Wed Jan 17 13:10:57 2001 EDT Modified files: /phpdoc/en/functionsdatetime.xml Log: Document the standardization of offset sign. Index: phpdoc/en/functions/datetime.xml diff -u phpdoc/en/functions/datetime.xml:1.27 phpdoc/en/functions/datetime.xml:1.28 --- phpdoc/en/functions/datetime.xml:1.27 Fri Jan 12 22:54:45 2001 +++ phpdoc/en/functions/datetime.xmlWed Jan 17 13:10:57 2001 @@ -218,7 +218,9 @@ -Z - timezone offset in seconds (i.e. "-43200" to "43200") + Z - timezone offset in seconds (i.e. "-43200" to "43200"). The offset + for timezones west of UTC is always negative, and for those east of + UTC is always positive.
Re: [PHP-DOC] Structuring PCRE.xml
On Mon, 15 Jan 2001, Damien Seguy wrote: > Hi, > > As I was reading the pcre.xml part of the doc, I thought it might be more > convenient to break it into smaller pieces. is not really > the best tags for such a piece of doc. > > I was thinking to break it into refentries, one by major entries : > > > > > > > > > > > > > > > > > > Of course, there's still some rereading to catch all those , > , and and examples too. > > Does it sounds ok to anyone? > Anyone already started the job? > > If it sounds ok, I'll give a try on French manual before actually > messing up the en tree. You might want to update it from the pcre.txt file that is located in ext/pcre/pcrelib - that's the latest docs for the bundled version. -Andrei
