[PHP-DOC] cvs: phpdoc /en/reference/ftp/functions ftp-chmod.xml ftp-close.xml
daveThu Jul 29 01:54:45 2004 EDT
Modified files:
/phpdoc/en/reference/ftp/functions ftp-chmod.xml ftp-close.xml
Log:
- proto fixes.
http://cvs.php.net/diff.php/phpdoc/en/reference/ftp/functions/ftp-chmod.xml?r1=1.4&r2=1.5&ty=u
Index: phpdoc/en/reference/ftp/functions/ftp-chmod.xml
diff -u phpdoc/en/reference/ftp/functions/ftp-chmod.xml:1.4
phpdoc/en/reference/ftp/functions/ftp-chmod.xml:1.5
--- phpdoc/en/reference/ftp/functions/ftp-chmod.xml:1.4 Wed Jun 9 08:10:05 2004
+++ phpdoc/en/reference/ftp/functions/ftp-chmod.xml Thu Jul 29 01:54:45 2004
@@ -1,5 +1,5 @@
-
+
ftp_chmod
@@ -8,7 +8,7 @@
Description
- stringftp_chmod
+ intftp_chmod
resourceftp_stream
intmode
stringfilename
@@ -19,6 +19,9 @@
given as an octal value.
+ Returns mode on success, or &false; on failure.
+
+
ftp_chmod example
@@ -33,7 +36,7 @@
$login_result = ftp_login($conn_id, $ftp_user_name, $ftp_user_pass);
// try to chmod $file to 644
-if (ftp_chmod($conn_id, 0644, $file)) {
+if (ftp_chmod($conn_id, 0644, $file) !== false) {
echo "$file chmoded successfully to 644\n";
} else {
echo "could not chmod $file\n";
http://cvs.php.net/diff.php/phpdoc/en/reference/ftp/functions/ftp-close.xml?r1=1.5&r2=1.6&ty=u
Index: phpdoc/en/reference/ftp/functions/ftp-close.xml
diff -u phpdoc/en/reference/ftp/functions/ftp-close.xml:1.5
phpdoc/en/reference/ftp/functions/ftp-close.xml:1.6
--- phpdoc/en/reference/ftp/functions/ftp-close.xml:1.5 Fri Dec 19 09:40:54 2003
+++ phpdoc/en/reference/ftp/functions/ftp-close.xml Thu Jul 29 01:54:45 2004
@@ -1,5 +1,5 @@
-
+
@@ -9,15 +9,18 @@
Description
- voidftp_close
+ boolftp_close
resourceftp_stream
-
+
ftp_close closes ftp_stream
and releases the resource. After calling this function,
you can no longer use the FTP connection and must create a new one
with ftp_connect.
-
+
+
+ &return.success;
+
ftp_close example
Re: [PHP-DOC] PECL doc proposal
* Thus wrote Philip Olson: > > from configure.xml > --- > > &pecl.linux.php45; > &url.pecl.package;crack. > In order to use these functions, you must compile PHP with Crack support > by using the --with-crack[=DIR] option. > > > Windows users will enable php_crack.dll in order to > use these functions. > &pecl.windows.php45; > > > from language-snippets.ent > --- > extensions/ directory within your PHP > Windows binaries download. In PHP 5 it can be found in the > separate PECL download from > PHP Downloads.'> > > resides in the ext/ directory within the PHP > sources. In PHP 5 this is no longer bundled and instead can be > found in PECL here:'> I think this is an excellent aproach to the current problem, I've been strugling with this myself. The only problem I see is the name of the ID of the entity. >From my understanding is that a lot of stuff that resides currently in ext/ will be moved to PECL, so when version 5.1 comes out what will we do in that case? an entity of pecl.(windows|unix)4551 of of some sort would have to be made. And each release of php will have to create a new entity of some sort. Now after thinking about it, mabey if we can find a nice solution with the documentation's changelog (as you previously mentioned). These items could go there, and would be really nice if the function could reference that changelog somehow. Curt -- First, let me assure you that this is not one of those shady pyramid schemes you've been hearing about. No, sir. Our model is the trapezoid!
Re: [PHP-DOC] PECL doc proposal
On Thursday, July 29, 2004, 8:43:27 AM, Philip wrote: > Hello! > In documenting the PECL extension changes I came across a few > bumps and ended up with the following, please add suggestions > on how this could be improved. This is for bug #28018 and also > a PECL bug #2008 > http://pecl.php.net/bugs/bug.php?id=2008 > http://bugs.php.net/bug.php?id=28018 > Using ref.crack as an example: > from configure.xml > --- > > &pecl.linux.php45; >url="&url.pecl.package;crack">&url.pecl.package;crack. > In order to use these functions, you must compile PHP with Crack support > by using the role="configure">--with-crack[=DIR] option. > > > Windows users will enable php_crack.dll in order to > use these functions. > &pecl.windows.php45; > > from language-snippets.ent > --- > extensions/ directory within your PHP > Windows binaries download. In PHP 5 it can be found in the > separate PECL download from > PHP Downloads.'> > resides in the ext/ directory within the PHP > sources. In PHP 5 this is no longer bundled and instead can be > found in PECL here:'> > Regards, > Philip Looks good except for "this PECL extensions". Dave
[PHP-DOC] PECL doc proposal
Hello! In documenting the PECL extension changes I came across a few bumps and ended up with the following, please add suggestions on how this could be improved. This is for bug #28018 and also a PECL bug #2008 http://pecl.php.net/bugs/bug.php?id=2008 http://bugs.php.net/bug.php?id=28018 Using ref.crack as an example: from configure.xml --- &pecl.linux.php45; &url.pecl.package;crack. In order to use these functions, you must compile PHP with Crack support by using the --with-crack[=DIR] option. Windows users will enable php_crack.dll in order to use these functions. &pecl.windows.php45; from language-snippets.ent --- extensions/ directory within your PHP Windows binaries download. In PHP 5 it can be found in the separate PECL download from PHP Downloads.'> ext/ directory within the PHP sources. In PHP 5 this is no longer bundled and instead can be found in PECL here:'> Regards, Philip
[PHP-DOC] getting credits into phpcredits()
Hi, I would like to replace the current documentation team credits in phpcredits() with the following information next week, if noone complains: - list of authors currently on the frontpage - list of editors currently on the frontpage - list of currently active user note maintainers (from contributions.xml) As I itend to do this next week, it would be nice to discuss any remaining issues around these lists, so an actual, correct and community agreed list is going into the PHP source tree for upcoming PHP releases. Goba
Re: [PHP-DOC] cvs: phpdoc /en bookinfo.xml contributors.xml
Modified files: /phpdoc/en bookinfo.xml contributors.xml language-snippets.ent Log: Pushing currently active people to the frontpage, and move the past>authors to the contributors page (everything ordered alpahbetically>now). Suggest more people to the frontpage if you see fit, or suggest>the removal of someone now. Looking through the commits I don't see Tony as an author yet, http://cvs.php.net/phpdoc/en/reference/oci8/ And http://cvs.php.net/phpdoc/en/reference/memcache/ OK, so since noone else challanged Antony and it seems that he do contributed a lot to the docs, we will keep him :) Or are there any more objections? The questions is still up regarding Georg (who is only an active maintainer of the mysql(i) extension docs). Is that something which makes him not yet being qualified to be a "top author"? Goba
Re: [PHP-DOC] cvs: phpdoc /en bookinfo.xml contributors.xml
> BTW I intended to provide an extended list of past contributors along > the lines of what I proposed earlier, but since the master server is not > working, I have a hard time of paring cvs account names to realnames. > Anyone knows another place to get the realnames of people behind cvs > accounts? Here are a couple suggestions: #search username here, full names often show up http://marc.theaimsgroup.com/?l=phpdoc #maybe a few are here too http://pear.php.net/accounts.php Regards, Philip P.S. I feel... alive! ;)
Re: [PHP-DOC] cvs: phpdoc /en bookinfo.xml contributors.xml
BTW I intended to provide an extended list of past contributors along the lines of what I proposed earlier, but since the master server is not working, I have a hard time of paring cvs account names to realnames. Anyone knows another place to get the realnames of people behind cvs accounts? Goba Gabor Hojtsy írta: gobaWed Jul 28 17:22:02 2004 EDT Modified files: /phpdoc/en bookinfo.xml contributors.xml Log: Philip is active again, so credit him as such (as far as we know his past contributions, he is going to be active in the future too :) http://cvs.php.net/diff.php/phpdoc/en/bookinfo.xml?r1=1.40&r2=1.41&ty=u Index: phpdoc/en/bookinfo.xml diff -u phpdoc/en/bookinfo.xml:1.40 phpdoc/en/bookinfo.xml:1.41 --- phpdoc/en/bookinfo.xml:1.40 Wed Jul 21 06:13:50 2004 +++ phpdoc/en/bookinfo.xml Wed Jul 28 17:22:01 2004 @@ -1,5 +1,5 @@ - + &PHPManual; @@ -21,6 +21,10 @@ NunoLopes + +PhilipOlson + + GeorgRichter http://cvs.php.net/diff.php/phpdoc/en/contributors.xml?r1=1.5&r2=1.6&ty=u Index: phpdoc/en/contributors.xml diff -u phpdoc/en/contributors.xml:1.5 phpdoc/en/contributors.xml:1.6 --- phpdoc/en/contributors.xml:1.5 Wed Jul 21 12:06:07 2004 +++ phpdoc/en/contributors.xml Wed Jul 28 17:22:01 2004 @@ -1,5 +1,5 @@ - + Stig Bakken, Rasmus Lerdorf, - Philip Olson, Egon Schmid, Lars Torben Wilson, Jim Winstead&listendand;
[PHP-DOC] cvs: phpdoc /en bookinfo.xml contributors.xml
gobaWed Jul 28 17:22:02 2004 EDT Modified files: /phpdoc/en bookinfo.xml contributors.xml Log: Philip is active again, so credit him as such (as far as we know his past contributions, he is going to be active in the future too :) http://cvs.php.net/diff.php/phpdoc/en/bookinfo.xml?r1=1.40&r2=1.41&ty=u Index: phpdoc/en/bookinfo.xml diff -u phpdoc/en/bookinfo.xml:1.40 phpdoc/en/bookinfo.xml:1.41 --- phpdoc/en/bookinfo.xml:1.40 Wed Jul 21 06:13:50 2004 +++ phpdoc/en/bookinfo.xml Wed Jul 28 17:22:01 2004 @@ -1,5 +1,5 @@ - + &PHPManual; @@ -21,6 +21,10 @@ NunoLopes + +PhilipOlson + + GeorgRichter http://cvs.php.net/diff.php/phpdoc/en/contributors.xml?r1=1.5&r2=1.6&ty=u Index: phpdoc/en/contributors.xml diff -u phpdoc/en/contributors.xml:1.5 phpdoc/en/contributors.xml:1.6 --- phpdoc/en/contributors.xml:1.5 Wed Jul 21 12:06:07 2004 +++ phpdoc/en/contributors.xml Wed Jul 28 17:22:01 2004 @@ -1,5 +1,5 @@ - + Stig Bakken, Rasmus Lerdorf, - Philip Olson, Egon Schmid, Lars Torben Wilson, Jim Winstead&listendand;
Re: [PHP-DOC] a few coding standards
* Thus wrote Nuno Lopes: > > Here's how livedocs outputs it, looks a bit better huh? Not sure > > what version of livedocs this is (or how old these docs are) but > > it's the only online livedocs I could find: > > > > http://livedocs.coggeshall.org/en/function.mysqli-close.html > > > > May look better, but doesn't work well. in mysqli_close, the name of the > function isn't outputed. Seems to be a problem with how livedocs treats and together. there can't be a \n between the two: Works fine with this fix: - bool - close + boolclose http://livedocs.zirzow.dyndns.org/index.php?l=en&q=function.mysqli-close There also needs a way so you can declare it as a proper method: public function close() or other things like: public static version() protected getData() etc.. I'm not a docbook expert but mabey something like: Curt -- First, let me assure you that this is not one of those shady pyramid schemes you've been hearing about. No, sir. Our model is the trapezoid!
[PHP-DOC] #29018 [Opn->Fbk]: function arguments 'null' and staticval with n passing by reference
ID: 29018
Updated by: [EMAIL PROTECTED]
Reported By: none at space dot com
-Status: Open
+Status: Feedback
Bug Type: Documentation problem
Operating System: any
PHP Version: 4.3.6
New Comment:
Possible solution:
function foo (& $var){
if (is_null($var)){return 0};
return(1);
}
$somevar = null;
foo($somevar);
Possible workarounds:
allow_call_time_pass_reference can be set on per directory basis.
@ can be added before function call (with side-effect of not displaying
any errors of course)
There's no other solution AFAIK.
Previous Comments:
[2004-07-19 14:24:07] jsabre at jjsbr dot tv
I was wondering about this too... how can you deprecate this and not
tell the community what is going on? I found only very little info
about this issue out there. But meny people seem to truggle with it.
[2004-07-07 11:57:57] jform at helmsdeep dot org
above: sorry, typo:
function foo ($obj){
should obviously be
function myfunc ($obj){
i was copying...
[2004-07-07 11:55:42] jform at helmsdeep dot org
I agree totally! We used to be able to do the following:
myfunc(& $someobj); #and
myfunc(''); #this, if nothing passed
function foo ($obj){
if(is_null($obj)){...};
...
}
At this point we have to pre-check everything and do some massive
recoding! What is an easy solution for this or waht were you thinking
when chaning this? How do I pass 'nothing' now?
[2004-07-05 19:07:17] none at space dot com
Description:
proper reference documentation missing on how to switch from 'call-time
call-by-reference' to 'call-by-reference'.
with more and more ISP's upgrading php from versions prior the
deprecated 'call-time call-by-reference' to newer versions, more and
more people get utterly frustrated searching solutions to fix their
codes or libs for the two situations below.
especially passing 'no object' or null to a class has become critical
and there is no clear statement in the documentation of (references
explained) on what logic the guys that deprecated the the 'call-time'
functionality had in mind to compensate for that lack of
functionality.
i think it's about time you post the concept and solution of this
change somewhere prominently.
Reproduce code:
---
function foo (& $var){
if (is_null($var)){return 0};
return(1);
}
#call now
foo($somevar); #will work
foo('');#will not work (how to do this properly?)
foo(1); #will not work (obviously)
Expected result:
>1
>0
>0
--
Edit this bug report at http://bugs.php.net/?id=29018&edit=1
[PHP-DOC] #27111 [Fbk->Opn]: virtual() function does not behave as documented
ID: 27111 User updated by: e-phpbug at erowid dot org Reported By: e-phpbug at erowid dot org -Status: Feedback +Status: Open Bug Type: Documentation problem Operating System: freebsd PHP Version: 4.3.4 New Comment: Yes, excellent. I do not have access to a properly-functioning apache2+mod_php setup, so I can't test this myself, but I'd say you've hit the nail on the head. Thanks for taking another look at it! Your work on this is very much appreciated. Previous Comments: [2004-07-28 10:04:20] [EMAIL PROTECTED] Yes, I tried it. It seems that this function works as expected only with Apache 2. I tried these simple scripts: main.php: virtual.php: Apache 1: Parameters of main.php are printed Apache 2: "a=c" is printed virtual.php is not listed in Apache access log in either case. It's independent if you use PHP 4 or PHP 5. I tried it under Windows. Do you agree with this description? [2004-07-28 07:50:42] e-phpbug at erowid dot org It seems you continue to not understand the problem? Did you try it? Do you realize this exact bug has been closed improperly before? No, simply noting that it only works when compiled as an apache module does not solve the problem. The function does not work as documented no matter how PHP 4.x is compiled. I have not tried PHP5, but given your response to the problems, it seems very very unlikely its been fixed. Did you try my simple test case? Can you get the same behaviour from shtml include virtual on apache as you do from PHP? Also please check your apache log files. No additional request to apache is being generated, query parameters don't get passed and the environment is wrong. This function does not work when used to include PHP files, otherwise it works fine. The documentation should be changed to say something more like: "Note: This function does not perform like apache's include virtual shtml directive when used to call another PHP file. virtual() does not call the apache httpd, but instead runs the script internally without generating another file hit. It does not properly pass any query parameters or environment variables to the called php file." I would guess the problem is with some code above the apache API call and PHP is being "smart" by seeing its a php file and short circuiting instead of actually calling apache. Or there is a bug between apache and PHP, but its not getting to apache as a file request, its just getting executed by the PHP module internally. Whatever the cause, however, your proposed resolution, is wrong. [2004-07-27 22:33:09] [EMAIL PROTECTED] This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Copied from sources: "This function works only when PHP is compiled as an Apache module, since it uses the Apache API for doing sub requests." [2004-01-31 21:06:18] e-phpbug at erowid dot org Description: Documentation for virtual() claims that it should work like an apache sub-request like the shtml #include virtual command. It does not. Bug 26500 is reporting the same bug but appears to have been closed by someone who does not understand the issue. It is clear that it is not doing this as advertised for php scripts. What should be creating an http request is instead clearly short-circuting to a PHP include() call with the docroot pre-pended when the target is a php script. This results in any CGI PHP called through virtual being called as a sub-component of the current PHP script instead of as its own execution, with its own environment, own POST/GET variables, etc. This clearly violates the documented purpose of the call (to replicate the apache shtml functionality). Also, as a side effect of how this behaves, virtual changes the cwd in the calling script (a behaviour that should not happen with an apache subrequest). Both of these problems are solved if http://www.host.com/ is pre-pended to the string and passed to include() instead, which actually generates an http sub-request. Proposed solutions: 1) change the documentation so that it doesn't claim this is the same as apache's include-virtual directive. 2) fix the problem since this is clearly the intended behaviour for the function. Reproduce code: --- The following should have equivalent effect, given the documentation: and with stuff.php as: \n"; ?> Expected result: The shtml results in: Var: Value Actual result:
Re: [PHP-DOC] php5 and object
Please ask support questions at [EMAIL PROTECTED]
Regards,
Gabor Hojtsy
Krzysztof Gorzelak írta:
Hello,
I'm trying to make this code to work:
// start of code
abstract class Strona {
abstract public function generuj_strone();
function foo() {
generuj_strone();
}
}
class Katalog extends Strona {
public function generuj_strone() {
echo "OK";
}
}
$bar = new Katalog();
$bar->foo();
// end of code
And I get such error :
Fatal error: Cannot call abstract method Strona::generuj_strone() in
And I expect word: OK
Is it a bug or a normal behaviour ?
Thanks for help!
Krzysztof Gorzelak
[EMAIL PROTECTED]
Re: [PHP-DOC] Where did user contributed notes go?
Hi, Tha last time i've downloaded a PHP manual long ago in 2002 it had tons of user contributed notes in it. The notes were very usefull for me. Recently i've decided to update the manual, so I downloaded one and to my surprise found no notes in it. Why, where did they go? Are there still manual versions with notes in them? There is no downloadle version now with user notes (except the extended CHM), and I don't remember we had such a version in 2002, so you are probbaly wrong. The online version has no notes currently, but those will be back up. Goba
Re: [PHP-DOC] Associativity of unary operators
You'd probably better ask this on the development list (cc-ed). Goba Jakub Vrana írta: I'm not a formal languages expert but I wonder how can unary operator be associative. It also seems that ++ and -- have higher priority than the rest of unary operators listed on one line. I also don't understand why "print" is listed among operators. Do you object against this patch? RCS file: /repository/phpdoc/en/language/operators.xml,v retrieving revision 1.76 diff -u -r1.76 operators.xml --- operators.xml 27 Jul 2004 21:30:24 - 1.76 +++ operators.xml 28 Jul 2004 08:52:09 - @@ -61,8 +61,12 @@ [ -right -! ~ - ++ -- (int) (float) (string) (array) (object) @ +non-associative +++ -- + + +non-associative +! ~ - (int) (float) (string) (array) (object) @ left @@ -115,10 +119,6 @@ -right -print - - left and
Re: [PHP-DOC] a few coding standards
Hi! Just want to confirm that the following are true as I don't believe these have been made official [yet]: a) No ending period in the reftitle b) No ending period in the see also c) Only part of docs wider than 78 characters is methodsynopsis d) New examples use ' not " wherever possible (this is old since PEAR coding standards describe it but few do it, not sure why) e) All new (and eventually old) docs will use the new upcoming 'refsect style' Regarding (a), it's a little strange when a reftitle has multiple sentences, or commas, as it means only partial punctuation is used when we leave off the ending period. Should we live with that? Most are not this way so it should be fine. Also, many times these titles aren't even complete sentences. Are there reftitles with multiple sentences? Huh... Reftitle supposed to be short, isn't it? With (b) it would be nice if we didn't manually type in commas either but it seems we abandoned that idea. Goba? Adding them feels a little dirty but also simple and doable. Since we are not using a list markup for see also lists, we should add commas ourselfs. If we would use some list markup, then we could autogenerate commas (and the ending ", and" part between the last two list items). As far as (e) goes I'll write a separate email regarding a CHANGELOG refsect1 proposal (this has been discussed many times!) but other than that what do you guys think? Regarding (c), most of our docs is wrapped at 78, but maybe there are more places (additionaly to methodsynopsis), where it is fine to keep the non-wrapped lines. Goba
Re: [PHP-DOC] the tag,
Gabor Hojtsy wrote: The docweb project was largely advertised on all doc mailling lists. Livedocs is in alpha stage. It has a couple of well know bugs. So, first let's fix them, and then make it public. Is it the intention that http://docs.php.net is going to some day replace http://www.php.net/docs.php ? NO! NO! NO! The distributed and online documentation will stay on mirror sites! docs.php.net is intended to be a development machine for phpdoc related activities (revchecks, dochowto, and test server for under development stuff - now for livedocs). eh, okay - I think we cleared that in the previous comments.. -- Tom
Re: [PHP-DOC] the tag, time for a title? (livedocs integration)
Is it the intention that http://docs.php.net is going to some day replace http://www.php.net/docs.php ? No! doc.php.net is designed for developpers, documenters and translators. It isn't aimed for public. It will serve as a livedocs testbed, as well as revcheck for translators, list of undocumented functions, functions without examples, etc Okay, I just interpreted Philip's comment as the public was going to use it: "People will slowly use it this way and the more people start using it the more people will complain and more importantly the more people will fix problems and add features. If a major problem exists there we can redirect users to php.net/manual/" I assumed it would but after some thought can see why it wouldn't. It will at least show livedocs during the beta process. As far as mirrors go, the new subdomain might not work so well for that :) It will inevitably be used by the public, if we don't close it down with some password protection. There are already lot of blog posts around PHP blogs referencing livedocs setups around the net. Goba
Re: [PHP-DOC] the tag, time for a title? (livedocs integration)
Since the docs are going to be made and hosted on a linux server, I don't see the big problem with that in terms of making php.net run on livedocs For development, it might be important to let it run properly on Windows, so Windows users (like Nuno :) can help in. The docweb project was largely advertised on all doc mailling lists. Livedocs is in alpha stage. It has a couple of well know bugs. So, first let's fix them, and then make it public. Is it the intention that http://docs.php.net is going to some day replace http://www.php.net/docs.php ? NO! NO! NO! The distributed and online documentation will stay on mirror sites! docs.php.net is intended to be a development machine for phpdoc related activities (revchecks, dochowto, and test server for under development stuff - now for livedocs). Goba
Re: [PHP-DOC] the tag, time for a title? (livedocs integration)
The docweb project was largely advertised on all doc mailling lists. Livedocs is in alpha stage. It has a couple of well know bugs. So, first let's fix them, and then make it public. Ehem, the same approach holds docweb back "lets fix before making it public" :) It might not be a good approach, especially not in an open source environment, where people are waiting and eager to help... Goba
Re: [PHP-DOC] the tag, time for a title? (livedocs integration)
Livedocs needs more testers, and more people willing to put time into it. I never found enough time to help out, but I try to direct everybody who is not satisfied with the lack of insite search, lack of timely manual updates, etc. to help in livedocs development as that is clearly the way to go. We need docs.php.net online, and docweb on a reliable, working, and maintained server; and in PHP CVS. The current situation there looks a bit screwy but I've only been an observer there. I do like the idea of a core group starting it out, less noise, but is it ready for others now or is the server problem still holding things back? Maybe we got a little too aggressive with idealistic ideas and should just focus on one thing at a time, like livedocs, I don't know. Once ready for testing (now?), docs.php.net can simply be livedocs like it used to be (or a shell of docweb) and we won't "advertise" it. People will slowly use it this way and the more people start using it the more people will complain and more importantly the more people will fix problems and add features. If a major problem exists there we can redirect users to php.net/manual/ Also, it should add excitement to the docweb project, a project few know even exists right now[1]. Well, I fully agree with you here. I have a copy (which I think is the latest possible) of the docweb efforts we started, and I definitely don't want to close it down. As far as I see, the server problems hold it down. If we don't have a server to run it on, there is no place to test the codes (I am not in the mood of setting up local servers for every test :). BTW I have not committed the code to docweb because it is ugly at multiple places, and I hoped it will get polished before it gets published, but neither Mehdi nor Yannick had time to polish the code, so it might just be better to open it up finnaly regardless of how ugly it is and let people polish it :) Goba
[PHP-DOC] php5 and object
Hello,
I'm trying to make this code to work:
// start of code
abstract class Strona {
abstract public function generuj_strone();
function foo() {
generuj_strone();
}
}
class Katalog extends Strona {
public function generuj_strone() {
echo "OK";
}
}
$bar = new Katalog();
$bar->foo();
// end of code
And I get such error :
Fatal error: Cannot call abstract method Strona::generuj_strone() in
And I expect word: OK
Is it a bug or a normal behaviour ?
Thanks for help!
Krzysztof Gorzelak
[EMAIL PROTECTED]
[PHP-DOC] cvs: phpdoc /en/reference/tidy/functions tidy-get-config.xml
nlopess Wed Jul 28 12:43:09 2004 EDT
Modified files:
/phpdoc/en/reference/tidy/functions tidy-get-config.xml
Log:
fix example
http://cvs.php.net/diff.php/phpdoc/en/reference/tidy/functions/tidy-get-config.xml?r1=1.4&r2=1.5&ty=u
Index: phpdoc/en/reference/tidy/functions/tidy-get-config.xml
diff -u phpdoc/en/reference/tidy/functions/tidy-get-config.xml:1.4
phpdoc/en/reference/tidy/functions/tidy-get-config.xml:1.5
--- phpdoc/en/reference/tidy/functions/tidy-get-config.xml:1.4 Sat Jul 3 11:47:18
2004
+++ phpdoc/en/reference/tidy/functions/tidy-get-config.xml Wed Jul 28 12:43:09
2004
@@ -1,5 +1,5 @@
-
+
tidy_get_config
@@ -35,7 +35,7 @@
$html = 'test';
$config = array('indent' => TRUE,
'output-xhtml' => TRUE,
-'wrap', 200);
+'wrap' => 200);
$tidy = tidy_parse_string($html, $config);
[PHP-DOC] cvs: phpdoc /en/reference/tidy/functions tidy-parse-string.xml
nlopess Wed Jul 28 12:36:59 2004 EDT
Modified files:
/phpdoc/en/reference/tidy/functions tidy-parse-string.xml
Log:
fix example
http://cvs.php.net/diff.php/phpdoc/en/reference/tidy/functions/tidy-parse-string.xml?r1=1.5&r2=1.6&ty=u
Index: phpdoc/en/reference/tidy/functions/tidy-parse-string.xml
diff -u phpdoc/en/reference/tidy/functions/tidy-parse-string.xml:1.5
phpdoc/en/reference/tidy/functions/tidy-parse-string.xml:1.6
--- phpdoc/en/reference/tidy/functions/tidy-parse-string.xml:1.5Sun Jul 4
06:06:18 2004
+++ phpdoc/en/reference/tidy/functions/tidy-parse-string.xmlWed Jul 28 12:36:59
2004
@@ -1,5 +1,5 @@
-
+
tidy_parse_string
@@ -51,7 +51,7 @@
$buffer = ob_get_clean();
$config = array('indent' => TRUE,
'output-xhtml' => TRUE,
-'wrap', 200);
+'wrap' => 200);
$tidy = tidy_parse_string($buffer, $config, 'UTF8');
Re: [PHP-DOC] a few coding standards
> Here's how livedocs outputs it, looks a bit better huh? Not sure > what version of livedocs this is (or how old these docs are) but > it's the only online livedocs I could find: > > http://livedocs.coggeshall.org/en/function.mysqli-close.html > May look better, but doesn't work well. in mysqli_close, the name of the function isn't outputed.
Re: [PHP-DOC] a few coding standards
Philip Olson wrote: Personally I think http://www.php.net/manual/en/function.mysqli-close.php is one of the most confusing manual pages I have seen to date, MySQLi docs are a bit confusing... consider the mysqli close: Here's how livedocs outputs it, looks a bit better huh? Not sure what version of livedocs this is (or how old these docs are) but it's the only online livedocs I could find: http://livedocs.coggeshall.org/en/function.mysqli-close.html The dir class also looks a lot better here: http://livedocs.coggeshall.org/en/class.dir.html Oh yes, much better... All the more reason to bling livedocs // Tom
Re: [PHP-DOC] a few coding standards
> > Personally I think > > http://www.php.net/manual/en/function.mysqli-close.php is one of the > > most confusing manual pages I have seen to date, > > http://www.php.net/manual/en/class.dir.php is also high on that list > > > > Indentation of pseudo-objects would help a great deal. > > The dsssl cheets aren't well costumised (if they are) for . > Livedocs doesn't deal with OO yet. > > > Anyway, mysqli-close is confusing :) > > MySQLi docs are a bit confusing... consider the mysqli close: > > mysqli_close > (PHP 5) > mysqli_close > (no version information, might be only in CVS) > mysqli->close -- Closes a previously opened database connection > Description I don't know where we're at on this OOP generation stuff but it's not something I know much about. Procedural all the way baby! But seriously I believe people are working on it or at least it's a known issue but really DSSSL has cob webs and I doubt that will change (unless you are somebody you knows has a large broom). Here's how livedocs outputs it, looks a bit better huh? Not sure what version of livedocs this is (or how old these docs are) but it's the only online livedocs I could find: http://livedocs.coggeshall.org/en/function.mysqli-close.html The dir class also looks a lot better here: http://livedocs.coggeshall.org/en/class.dir.html Regards, Philip
Re: [PHP-DOC] Proposal: CHANGELOG
> > > This would be great and it's a perfect time to implement because > > > when people update old docs to the new refsect1 style we would > > > also implement these changelog entries! Woohoo!!! > > > > What is the new refsext1 style? The credits tag?... > > Each manual page is split up in sections, see language-defs.ent > for a list of entities and the exif/mysqli docs for examples. > Some of the mysqli docs list examples after the see also so > we'd want to change that unless everyone feels that a change in > order is needed. I don't! I committed a new doc skeleton to the > HOWTO as well. I was fairly certain this was agreed upon but > don't remember any official call for votes. Oh, I remember of seeing a discussion about the structure used in mysqli docs (which is like PEAR). I think we shouldn't do a mass change of the structure or translators kill us! We could implement it from time to time in new extensions or in re-written pages. > Now as to the CHANGELOG, I am guessing nobody will implement it > in DSSSL (I know I won't) so focusing on livedocs may end up > happening. Livedocs or bust, 2004! Or 2005, 2006, 2007,. I don't mind focusing on livedocs, because I have some free time now. But I would like to have the oficial website to test it to receive some feedback. I'll send some patches to Ilia to correct some bugs I've noted, and I'll try to implement the tag correctly. Nuno
Re: [PHP-DOC] a few coding standards
> Personally I think > http://www.php.net/manual/en/function.mysqli-close.php is one of the > most confusing manual pages I have seen to date, > http://www.php.net/manual/en/class.dir.php is also high on that list > > Indentation of pseudo-objects would help a great deal. The dsssl cheets aren't well costumised (if they are) for . Livedocs doesn't deal with OO yet. > Anyway, mysqli-close is confusing :) MySQLi docs are a bit confusing... consider the mysqli close: mysqli_close (PHP 5) mysqli_close (no version information, might be only in CVS) mysqli->close -- Closes a previously opened database connection Description Uhm, strange!
Re: [PHP-DOC] Proposal: CHANGELOG
> > A partial proposal: CHANGELOG refsect1 > > > > What it will contain: > > 1) Parameter changes (new, modified, ...) > > 2) Function changes (new features, new behaviors, ...) > > 3) PHP Version info for each change > > > > From TODO: > > new roles: seealso, newparameter, and changedparameter. > > Of course this is a good idea, but I don't know how hard is the > implemetation. > With this we could have costumized manuals for each php version (with > livedocs). We'll have to be careful here because we don't want person A reading person B's version of the manual and getting confused. I was thinking of only differentiated CSS stylesheets but maybe you mean something like that. Just as long as different manual builds aren't floating around. > My only concern is how to implement all this... My docbook knowledge isn't > good, as well as XSLT, dsssl, etc... Do anyone have enough time to implement > this at 100%? > I don't have many ideas for you (yet). I'm gonna think on the subject later. The lack of a DSSSL and XSLT guru has plagued our work for years so perhaps the use of livedocs will change all of that. If not implemented in DSSSL we'd have to wait until livedocs becomes official. Of course both would be ideal :) > > This would be great and it's a perfect time to implement because > > when people update old docs to the new refsect1 style we would > > also implement these changelog entries! Woohoo!!! > > What is the new refsext1 style? The credits tag?... Each manual page is split up in sections, see language-defs.ent for a list of entities and the exif/mysqli docs for examples. Some of the mysqli docs list examples after the see also so we'd want to change that unless everyone feels that a change in order is needed. I don't! I committed a new doc skeleton to the HOWTO as well. I was fairly certain this was agreed upon but don't remember any official call for votes. Now as to the CHANGELOG, I am guessing nobody will implement it in DSSSL (I know I won't) so focusing on livedocs may end up happening. Livedocs or bust, 2004! Regards, Philip
Re: [PHP-DOC] a few coding standards
Philip Olson wrote:
For the exotic entries listed in that post perhaps we can
simply surround those with and format accordingly.
And here's an example using the new format:
http://www.php.net/manual/en/function.mysqli-close.php
Is it possible to do indentation in:
---
class mysqli {
bool close ( void )
}
---
to
---
class mysqli {
bool close ( void )
}
---
Personally I think
http://www.php.net/manual/en/function.mysqli-close.php is one of the
most confusing manual pages I have seen to date,
http://www.php.net/manual/en/class.dir.php is also high on that list
Indentation of pseudo-objects would help a great deal.
Anyway, mysqli-close is confusing :)
--
Tom
Re: [PHP-DOC] a few coding standards
> > >b) No ending period in the see also > > > > Why not? > > "See also echo and print." > > > The ending period makes sense to me! > > This also make sense to me. Unlike the refpurpose, the "see also" > paragraph is exactly that; a paragraph in the body of the text, and > should end in a period like any other sentence. > > Consistency between these sorts of things may not be as important as > content, but it does make for a more refined and professional manual. I am referring to the new style where see also is its own refsect1 as 'See Also' is in a now, not a . Because of this it's no longer a paragraph or even a sentence but rather a simple list of functions/items. I can even see us not using commas. I think this one reason why Goba proposed not using punctuation at all long ago and letting stylesheets dictate the format. Here's a post (it uses old format but the gist holds true) http://marc.theaimsgroup.com/?l=phpdoc&m=105604569204232 For the exotic entries listed in that post perhaps we can simply surround those with and format accordingly. And here's an example using the new format: http://www.php.net/manual/en/function.mysqli-close.php It doesn't look bad but the use of commas and periods is leftover from the old style. If we stick with commas as the seperator that's fine but other options do exist. Regards, Philip
[PHP-DOC] #29428 [Opn->Bgs]: Error or missing overview of unset() function
ID: 29428 Updated by: [EMAIL PROTECTED] Reported By: kingoleg at mail dot ru -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: All PHP Version: Irrelevant New Comment: It's described pretty well, there's even example on this. Assigning null is slightly different from unsetting (e.g. variable stays in parent array with null value). Previous Comments: [2004-07-28 14:07:32] kingoleg at mail dot ru Description: In http://ua2.php.net/unset nothing said about how work unset() on local variables (PASSED BY REFERENCE or NOT). unset() always "destroy" variables in local area. See code 1. May be would be good to write, that for variable PASSED BY REFERENCE we can use operation = null to unset variable. See code 2. Reproduce code: --- Expected result: For code 1. One of tree: 1. 'ok' 2. 'not ok' 3. variable $foo is null (not setted) For code 2. NULL NULL Actual result: -- 'not ok' NULL NULL -- Edit this bug report at http://bugs.php.net/?id=29428&edit=1
[PHP-DOC] #29420 [Opn->Csd]: Can't find "dbm" package in PECL
ID: 29420 Updated by: [EMAIL PROTECTED] Reported By: dada at bbs dot giga dot net dot tw -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: FreeBSD PHP Version: 5.0.0 New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Previous Comments: [2004-07-28 12:17:28] [EMAIL PROTECTED] i couldn't find any note regarding this extension beeing moved to PECL. I would just remove the note, too. [2004-07-28 10:26:13] [EMAIL PROTECTED] DBM functions are deprecated by DBA. I suppose it's not available anywhere ATM (it's even not in CVS). Maybe just removing the note about moving to PECL will be enough to document this. [2004-07-28 06:57:18] dada at bbs dot giga dot net dot tw Description: In manual of "dbm" section, "Note: This extension has been removed as of PHP 5 and moved to the PECL repository" But I can not find dbm package in PECL repository -- Edit this bug report at http://bugs.php.net/?id=29420&edit=1
[PHP-DOC] cvs: phpdoc /en/reference/dbm reference.xml
vrana Wed Jul 28 09:34:18 2004 EDT Modified files: /phpdoc/en/reference/dbmreference.xml Log: Wasn't move anywhere (bug #29420) http://cvs.php.net/diff.php/phpdoc/en/reference/dbm/reference.xml?r1=1.9&r2=1.10&ty=u Index: phpdoc/en/reference/dbm/reference.xml diff -u phpdoc/en/reference/dbm/reference.xml:1.9 phpdoc/en/reference/dbm/reference.xml:1.10 --- phpdoc/en/reference/dbm/reference.xml:1.9 Sun Feb 8 06:28:11 2004 +++ phpdoc/en/reference/dbm/reference.xml Wed Jul 28 09:34:17 2004 @@ -1,5 +1,5 @@ - + DBM Functions [deprecated] DBM @@ -22,7 +22,6 @@ instead. -¬e.pecl-php5;
Re: [PHP-DOC] Re: a few coding standards
On Wed, 28 Jul 2004 21:56:53 +1000 "Aidan Lister" <[EMAIL PROTECTED]> wrote: > Hi Philip, > > I'm new, so this has probably been discussed a million times. > > Do we have to leave all the crap at the bottom of every file? How many > people use vim? > Is there a better way to do it? > > A pretty rough estimate, but I'd say those comments account for > atleast 1/3rd of the size of the xml sources? I use vim. Btw, there are only 3 lines with Vim options and all they start with vi*. Others are (X)emacs options, so the question should sound like "How many people use emacs and why they don't use vim instead?", turning the discussion it to yet another pretty flamewar =) --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] || [EMAIL PROTECTED]
[PHP-DOC] Re: Where did user contributed notes go?
Anatoliy Samara wrote: Hello phpdoc, Tha last time i've downloaded a PHP manual long ago in 2002 it had tons of user contributed notes in it. The notes were very usefull for me. Recently i've decided to update the manual, so I downloaded one and to my surprise found no notes in it. Why, where did they go? Are there still manual versions with notes in them? http://bugs.php.net/bug.php?id=29321 The master server has crashed (yes, crashed) and therefore no comments can be found in the manual. // Tom
Re: [PHP-DOC] Where did user contributed notes go?
Anatoliy Samara wrote: > Are there still manual versions with notes in them? You can download Extended CHM from http://www.php.net/docs-echm.php Jakub Vrana
Re: [PHP-DOC] Where did user contributed notes go?
Hello, There is a problem with the server that has the notes. We are now working to have that server working ASAP. Please download the next manual build, where we expect to have the problem solved. Sorry for the inconvenient, Nuno Lopes - Original Message - From: "Anatoliy Samara" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 28, 2004 1:05 PM Subject: [PHP-DOC] Where did user contributed notes go? > Hello phpdoc, > > Tha last time i've downloaded a PHP manual long ago in 2002 it had > tons of user contributed notes in it. The notes were very usefull > for me. Recently i've decided to update the manual, so I downloaded > one and to my surprise found no notes in it. > > Why, where did they go? Are there still manual versions with notes > in them? > > Thanx in advance, > Anatoliy
[PHP-DOC] Where did user contributed notes go?
Hello phpdoc, Tha last time i've downloaded a PHP manual long ago in 2002 it had tons of user contributed notes in it. The notes were very usefull for me. Recently i've decided to update the manual, so I downloaded one and to my surprise found no notes in it. Why, where did they go? Are there still manual versions with notes in them? Thanx in advance, Anatoliy
Re: [PHP-DOC] Re: a few coding standards
> Hi Philip, > > I'm new, so this has probably been discussed a million times. > > Do we have to leave all the crap at the bottom of every file? How many > people use vim? > Is there a better way to do it? > > A pretty rough estimate, but I'd say those comments account for atleast > 1/3rd of the size of the xml sources? I use VIm :)
[PHP-DOC] #29428 [NEW]: Error or missing overview of unset() function
From: kingoleg at mail dot ru Operating system: All PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: Error or missing overview of unset() function Description: In http://ua2.php.net/unset nothing said about how work unset() on local variables (PASSED BY REFERENCE or NOT). unset() always "destroy" variables in local area. See code 1. May be would be good to write, that for variable PASSED BY REFERENCE we can use operation = null to unset variable. See code 2. Reproduce code: --- Expected result: For code 1. One of tree: 1. 'ok' 2. 'not ok' 3. variable $foo is null (not setted) For code 2. NULL NULL Actual result: -- 'not ok' NULL NULL -- Edit bug report at http://bugs.php.net/?id=29428&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29428&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29428&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29428&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29428&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29428&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29428&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29428&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29428&r=support Expected behavior: http://bugs.php.net/fix.php?id=29428&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29428&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29428&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29428&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29428&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29428&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29428&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29428&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29428&r=float
[PHP-DOC] Re: a few coding standards
Hi Philip, I'm new, so this has probably been discussed a million times. Do we have to leave all the crap at the bottom of every file? How many people use vim? Is there a better way to do it? A pretty rough estimate, but I'd say those comments account for atleast 1/3rd of the size of the xml sources? "Philip Olson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hello all! > > Just want to confirm that the following are true as I don't > believe these have been made official [yet]: > > a) No ending period in the reftitle > b) No ending period in the see also > c) Only part of docs wider than 78 characters is >methodsynopsis > d) New examples use ' not " wherever possible (this is >old since PEAR coding standards describe it but few >do it, not sure why) > e) All new (and eventually old) docs will use the new >upcoming 'refsect style' > > Regarding (a), it's a little strange when a reftitle has > multiple sentences, or commas, as it means only partial > punctuation is used when we leave off the ending period. > Should we live with that? Most are not this way so it > should be fine. Also, many times these titles aren't > even complete sentences. > > With (b) it would be nice if we didn't manually type in > commas either but it seems we abandoned that idea. Goba? > Adding them feels a little dirty but also simple and > doable. > > As far as (e) goes I'll write a separate email regarding > a CHANGELOG refsect1 proposal (this has been discussed > many times!) but other than that what do you guys think? > > Regards, > Philip
Re: [PHP-DOC] Proposal: CHANGELOG
> A partial proposal: CHANGELOG refsect1 > > What it will contain: > 1) Parameter changes (new, modified, ...) > 2) Function changes (new features, new behaviors, ...) > 3) PHP Version info for each change > > From TODO: > new roles: seealso, newparameter, and changedparameter. Of course this is a good idea, but I don't know how hard is the implemetation. With this we could have costumized manuals for each php version (with livedocs). My only concern is how to implement all this... My docbook knowledge isn't good, as well as XSLT, dsssl, etc... Do anyone have enough time to implement this at 100%? I don't have many ideas for you (yet). I'm gonna think on the subject later. > This would be great and it's a perfect time to implement because > when people update old docs to the new refsect1 style we would > also implement these changelog entries! Woohoo!!! What is the new refsext1 style? The credits tag?... Nuno
Re: [PHP-DOC] a few coding standards
On Wednesday, July 28, 2004, 9:11:44 PM, Nuno wrote: >> Hello all! >> >> Just want to confirm that the following are true as I don't >> believe these have been made official [yet]: >> >> a) No ending period in the reftitle > agree here Obviously I agree, after that commit I did fixing the few functions that didn't conform. :) >> b) No ending period in the see also > Why not? > "See also echo and print." > The ending period makes sense to me! This also make sense to me. Unlike the refpurpose, the "see also" paragraph is exactly that; a paragraph in the body of the text, and should end in a period like any other sentence. Consistency between these sorts of things may not be as important as content, but it does make for a more refined and professional manual. > Nuno Dave
Re: [PHP-DOC] a few coding standards
> Hello all! > > Just want to confirm that the following are true as I don't > believe these have been made official [yet]: > > a) No ending period in the reftitle agree here > b) No ending period in the see also Why not? "See also echo and print." The ending period makes sense to me! > c) Only part of docs wider than 78 characters is >methodsynopsis This is already agreeded... At least with the VI comments, you can't write longer lines > d) New examples use ' not " wherever possible (this is >old since PEAR coding standards describe it but few >do it, not sure why) We already refer that examples should follow the PEAR coding standards. > e) All new (and eventually old) docs will use the new >upcoming 'refsect style' What is this upcoming style? Can you explain me, please? Maybe I wans't here when you've discussed that. > Regarding (a), it's a little strange when a reftitle has > multiple sentences, or commas, as it means only partial > punctuation is used when we leave off the ending period. > Should we live with that? Most are not this way so it > should be fine. Also, many times these titles aren't > even complete sentences. Reftitles should be short! Just a smal descriptive phrase about the function. So, they shouldn't have any ponctuation, IHMO. Nuno
Re: [PHP-DOC] Typo Report
Hello Steven, This error was already corrected in CVS. The correct version will avaliable in the mirrors in the next manual build, which can take up to two weeks. Thanks for your report, Nuno Lopes - Original Message - > Dear PHP Documentation Team, > > I'd like to report what seems to be a typo. > To be found here: > > PHP Manual > Classes and Objects > Visibility > > > 2nd Paragraph: > > "Class members must be defined with public, private, or private." > > (Maybe: "Class members must be defined with public, protected or private."?) > > > I hope this has been helpfull. > > Kind regards, > Steven van Hekelen
Re: [PHP-DOC] Typo Report
[EMAIL PROTECTED] wrote: > I'd like to report what seems to be a typo. > To be found here: > PHP Manual > Classes and Objects > Visibility > 2nd Paragraph: > "Class members must be defined with public, private, or private." > (Maybe: "Class members must be defined with public, protected or private."?) This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Jakub Vrana
[PHP-DOC] #29420 [Opn]: Can't find "dbm" package in PECL
ID: 29420 Updated by: [EMAIL PROTECTED] Reported By: dada at bbs dot giga dot net dot tw Status: Open Bug Type: Documentation problem Operating System: FreeBSD PHP Version: 5.0.0 New Comment: i couldn't find any note regarding this extension beeing moved to PECL. I would just remove the note, too. Previous Comments: [2004-07-28 10:26:13] [EMAIL PROTECTED] DBM functions are deprecated by DBA. I suppose it's not available anywhere ATM (it's even not in CVS). Maybe just removing the note about moving to PECL will be enough to document this. [2004-07-28 06:57:18] dada at bbs dot giga dot net dot tw Description: In manual of "dbm" section, "Note: This extension has been removed as of PHP 5 and moved to the PECL repository" But I can not find dbm package in PECL repository -- Edit this bug report at http://bugs.php.net/?id=29420&edit=1
[PHP-DOC] Typo Report
Dear PHP Documentation Team, I'd like to report what seems to be a typo. To be found here: PHP Manual > Classes and Objects > Visibility 2nd Paragraph: "Class members must be defined with public, private, or private." (Maybe: "Class members must be defined with public, protected or private."?) I hope this has been helpfull. Kind regards, Steven van Hekelen
[PHP-DOC] Associativity of unary operators
I'm not a formal languages expert but I wonder how can unary operator be associative. It also seems that ++ and -- have higher priority than the rest of unary operators listed on one line. I also don't understand why "print" is listed among operators. Do you object against this patch? RCS file: /repository/phpdoc/en/language/operators.xml,v retrieving revision 1.76 diff -u -r1.76 operators.xml --- operators.xml 27 Jul 2004 21:30:24 - 1.76 +++ operators.xml 28 Jul 2004 08:52:09 - @@ -61,8 +61,12 @@ [ -right -! ~ - ++ -- (int) (float) (string) (array) (object) @ +non-associative +++ -- + + +non-associative +! ~ - (int) (float) (string) (array) (object) @ left @@ -115,10 +119,6 @@ -right -print - - left and -- Jakub Vrana
Re: [PHP-DOC] what generates the ini_set() docs?
Philip Olson wrote: > Can someone enlighten me on what generates the ini_set() docs > these days, and why it's not genPHP_INI_ENTRY.php? It's generated by Nuno's script (with my addition for linking to documentation of individual directives) nowadays. He wants to join this script with genPHP_INI_ENTRY.php and mk_ini_set_table.sh soon. http://testes.aborla.net/ini-update.php Jakub Vrana
[PHP-DOC] #28018 [Opn]: Document PECL extensions, especially for Windows users
ID: 28018 Updated by: [EMAIL PROTECTED] Reported By: hendrik dot schmieder at jedox dot com Status: Open Bug Type: Documentation problem Operating System: Windows PHP Version: 5CVS-2004-04-16 (dev) -Assigned To: +Assigned To: philip New Comment: Also a brief note should exist in php.ini (above the list of dlls) mentioning that some of these are PECL extensions, a separate download. It's also worth mentioning that all of this is only as of PHP 5. Assigning to self! Previous Comments: [2004-07-28 10:31:34] [EMAIL PROTECTED] PECL extensions such as ZIP are located in the PECL download, this is linked to on the main download page as "Collection of PECL modules for PHP 5.0.0". php_zip.dll exists in there as do all the other PECL files...there are a lot. Making this a documentation problem. EVERY extension that exists inside this Windows PECL download should be noted in the docs. For example the ZIP configure.xml should mention it. Also, the Windows extensions.xml should make reference to all of these too (or at least make some reference to it). To move beyond the PHP manual, downloads.php should let users know what PECL extensions are as many seem to be confused by this. install.txt should also mention it. [2004-07-28 09:29:53] ydhainaut at ifrance dot com i have the same problem : php.ini (V 5.0) is refering to php_zip.dll but no file in directory ext. so function "zip_open" doesnt work. i tried copy old version (v 4.36) of php_zip.dll in the directory ext and uncomment the significant line in php.ini but .. uhh.. doesn't work is there actually a solution ? best regards - Yves-Marie [2004-04-19 09:23:18] hendrik dot schmieder at jedox dot com Hello, is this statement about all files in group a and group b or only about the files in group b ? with best regards Hendrik Schmieder [2004-04-16 15:15:25] [EMAIL PROTECTED] Those extensions don't exist anymore. [2004-04-16 03:59:57] hendrik dot schmieder at jedox dot com Description: Hello, i have downloaded the Snapshot from Apr 16, 2004 06:30 GMT. But there are some files missing in this snapshot: Group a: gds32.dll iconv.dll libmcrypt.dll php_db.dll php_hyperwave.dll php_iisfunc.dll php_interbase.dll php_printer.dll Group b: php_crack.dll php_db.dll php_domxml.dll php_pspell.dll php_w32api.dll php_yaz.dll php_zip.dll There are no php5 versions for the files in group b. with best regards Hendrik Schmieder -- Edit this bug report at http://bugs.php.net/?id=28018&edit=1
[PHP-DOC] #28018 [Bgs->Opn]: Document PECL extensions, especially for Windows users
ID: 28018 Updated by: [EMAIL PROTECTED] -Summary: Missing files Reported By: hendrik dot schmieder at jedox dot com -Status: Bogus +Status: Open -Bug Type: *General Issues +Bug Type: Documentation problem Operating System: Windows PHP Version: 5CVS-2004-04-16 (dev) New Comment: PECL extensions such as ZIP are located in the PECL download, this is linked to on the main download page as "Collection of PECL modules for PHP 5.0.0". php_zip.dll exists in there as do all the other PECL files...there are a lot. Making this a documentation problem. EVERY extension that exists inside this Windows PECL download should be noted in the docs. For example the ZIP configure.xml should mention it. Also, the Windows extensions.xml should make reference to all of these too (or at least make some reference to it). To move beyond the PHP manual, downloads.php should let users know what PECL extensions are as many seem to be confused by this. install.txt should also mention it. Previous Comments: [2004-07-28 09:29:53] ydhainaut at ifrance dot com i have the same problem : php.ini (V 5.0) is refering to php_zip.dll but no file in directory ext. so function "zip_open" doesnt work. i tried copy old version (v 4.36) of php_zip.dll in the directory ext and uncomment the significant line in php.ini but .. uhh.. doesn't work is there actually a solution ? best regards - Yves-Marie [2004-04-19 09:23:18] hendrik dot schmieder at jedox dot com Hello, is this statement about all files in group a and group b or only about the files in group b ? with best regards Hendrik Schmieder [2004-04-16 15:15:25] [EMAIL PROTECTED] Those extensions don't exist anymore. [2004-04-16 03:59:57] hendrik dot schmieder at jedox dot com Description: Hello, i have downloaded the Snapshot from Apr 16, 2004 06:30 GMT. But there are some files missing in this snapshot: Group a: gds32.dll iconv.dll libmcrypt.dll php_db.dll php_hyperwave.dll php_iisfunc.dll php_interbase.dll php_printer.dll Group b: php_crack.dll php_db.dll php_domxml.dll php_pspell.dll php_w32api.dll php_yaz.dll php_zip.dll There are no php5 versions for the files in group b. with best regards Hendrik Schmieder -- Edit this bug report at http://bugs.php.net/?id=28018&edit=1
[PHP-DOC] #29420 [Opn]: Can't find "dbm" package in PECL
ID: 29420 Updated by: [EMAIL PROTECTED] Reported By: dada at bbs dot giga dot net dot tw Status: Open Bug Type: Documentation problem Operating System: FreeBSD PHP Version: 5.0.0 New Comment: DBM functions are deprecated by DBA. I suppose it's not available anywhere ATM (it's even not in CVS). Maybe just removing the note about moving to PECL will be enough to document this. Previous Comments: [2004-07-28 06:57:18] dada at bbs dot giga dot net dot tw Description: In manual of "dbm" section, "Note: This extension has been removed as of PHP 5 and moved to the PECL repository" But I can not find dbm package in PECL repository -- Edit this bug report at http://bugs.php.net/?id=29420&edit=1
[PHP-DOC] #27111 [Opn->Fbk]: virtual() function does not behave as documented
ID: 27111 Updated by: [EMAIL PROTECTED] Reported By: e-phpbug at erowid dot org -Status: Open +Status: Feedback Bug Type: Documentation problem Operating System: freebsd PHP Version: 4.3.4 New Comment: Yes, I tried it. It seems that this function works as expected only with Apache 2. I tried these simple scripts: main.php: virtual.php: Apache 1: Parameters of main.php are printed Apache 2: "a=c" is printed virtual.php is not listed in Apache access log in either case. It's independent if you use PHP 4 or PHP 5. I tried it under Windows. Do you agree with this description? Previous Comments: [2004-07-28 07:50:42] e-phpbug at erowid dot org It seems you continue to not understand the problem? Did you try it? Do you realize this exact bug has been closed improperly before? No, simply noting that it only works when compiled as an apache module does not solve the problem. The function does not work as documented no matter how PHP 4.x is compiled. I have not tried PHP5, but given your response to the problems, it seems very very unlikely its been fixed. Did you try my simple test case? Can you get the same behaviour from shtml include virtual on apache as you do from PHP? Also please check your apache log files. No additional request to apache is being generated, query parameters don't get passed and the environment is wrong. This function does not work when used to include PHP files, otherwise it works fine. The documentation should be changed to say something more like: "Note: This function does not perform like apache's include virtual shtml directive when used to call another PHP file. virtual() does not call the apache httpd, but instead runs the script internally without generating another file hit. It does not properly pass any query parameters or environment variables to the called php file." I would guess the problem is with some code above the apache API call and PHP is being "smart" by seeing its a php file and short circuiting instead of actually calling apache. Or there is a bug between apache and PHP, but its not getting to apache as a file request, its just getting executed by the PHP module internally. Whatever the cause, however, your proposed resolution, is wrong. [2004-07-27 22:33:09] [EMAIL PROTECTED] This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Copied from sources: "This function works only when PHP is compiled as an Apache module, since it uses the Apache API for doing sub requests." [2004-01-31 21:06:18] e-phpbug at erowid dot org Description: Documentation for virtual() claims that it should work like an apache sub-request like the shtml #include virtual command. It does not. Bug 26500 is reporting the same bug but appears to have been closed by someone who does not understand the issue. It is clear that it is not doing this as advertised for php scripts. What should be creating an http request is instead clearly short-circuting to a PHP include() call with the docroot pre-pended when the target is a php script. This results in any CGI PHP called through virtual being called as a sub-component of the current PHP script instead of as its own execution, with its own environment, own POST/GET variables, etc. This clearly violates the documented purpose of the call (to replicate the apache shtml functionality). Also, as a side effect of how this behaves, virtual changes the cwd in the calling script (a behaviour that should not happen with an apache subrequest). Both of these problems are solved if http://www.host.com/ is pre-pended to the string and passed to include() instead, which actually generates an http sub-request. Proposed solutions: 1) change the documentation so that it doesn't claim this is the same as apache's include-virtual directive. 2) fix the problem since this is clearly the intended behaviour for the function. Reproduce code: --- The following should have equivalent effect, given the documentation: and with stuff.php as: \n"; ?> Expected result: The shtml results in: Var: Value Actual result: -- the php results in: PHP warnings (if you E_ALL set) Var: -- Edit this bug report at http://bugs.php.net/?id=27111&edit=1
