[PHP-DOC] #25201 [Opn->Csd]: typo in cURL parameter documentation
ID: 25201 Updated by: [EMAIL PROTECTED] Reported By: scottm at spamcop dot net -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: Irrelevant New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-08-21 14:52:35] scottm at spamcop dot net Description: I was reading the cURL documentation and I noticed that CURL_SSL_VERIFYPEER is referenced on http://uk.php.net/manual/en/function.curl-setopt.php This should actually be CURLOPT_SSL_VERIFYPEER -- Edit this bug report at http://bugs.php.net/?id=25201&edit=1
[PHP-DOC] cvs: phpdoc /en/reference/curl/functions curl-setopt.xml
sniper Thu Aug 21 20:27:34 2003 EDT Modified files: /phpdoc/en/reference/curl/functions curl-setopt.xml Log: Fix typo Index: phpdoc/en/reference/curl/functions/curl-setopt.xml diff -u phpdoc/en/reference/curl/functions/curl-setopt.xml:1.4 phpdoc/en/reference/curl/functions/curl-setopt.xml:1.5 --- phpdoc/en/reference/curl/functions/curl-setopt.xml:1.4 Mon Jun 9 23:58:46 2003 +++ phpdoc/en/reference/curl/functions/curl-setopt.xml Thu Aug 21 20:27:34 2003 @@ -1,5 +1,5 @@ - + @@ -176,7 +176,7 @@ -CURL_SSL_VERIFYPEER: Pass a long that is set +CURLOPT_SSL_VERIFYPEER: Pass a long that is set to a zero value to stop curl from verifying the peer's certificate (curl 7.10 starting setting this option to &true; by default). Alternate certificates to verify against can be specified with the
Re: [PHP-DOC] #25191 [NEW]: Suggestion for a paragraph in the security chapter
I like this quote from the Windows distriburion of PHP on that matter: "Note, we consider installing PHP like this suicidal." Edin - Original Message - From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 21, 2003 4:36 PM Subject: [PHP-DOC] #25191 [NEW]: Suggestion for a paragraph in the security chapter > From: [EMAIL PROTECTED] > Operating system: Irrelevant > PHP version: Irrelevant > PHP Bug Type: Documentation problem > Bug description: Suggestion for a paragraph in the security chapter > > Description: > > This is a trivial issue. > > The section `security.cgi-bin.doc-root' begins like this: > > "To include active content, like scripts and executables, in the web > server document directories is sometimes consider an insecure practice." > > > I'd suggest a slightly different wording for this sentence. Something > like: > > "Including active content in the web server document directories, like > scripts and executables, is sometimes considered an insecure practice." > > > My main concern is with the word `consider', which I think should be > replaced by `considered'. My native language is not English, though, so > I'm not quite sure if this is an issue at all. > > Thanks. > > > -- > Edit bug report at http://bugs.php.net/?id=25191&edit=1 > -- > Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25191&r=trysnapshot4 > Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25191&r=trysnapshot5 > Fixed in CVS: http://bugs.php.net/fix.php?id=25191&r=fixedcvs > Fixed in release: http://bugs.php.net/fix.php?id=25191&r=alreadyfixed > Need backtrace: http://bugs.php.net/fix.php?id=25191&r=needtrace > Try newer version: http://bugs.php.net/fix.php?id=25191&r=oldversion > Not developer issue:http://bugs.php.net/fix.php?id=25191&r=support > Expected behavior: http://bugs.php.net/fix.php?id=25191&r=notwrong > Not enough info: http://bugs.php.net/fix.php?id=25191&r=notenoughinfo > Submitted twice: http://bugs.php.net/fix.php?id=25191&r=submittedtwice > register_globals: http://bugs.php.net/fix.php?id=25191&r=globals > PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25191&r=php3 > Daylight Savings: http://bugs.php.net/fix.php?id=25191&r=dst > IIS Stability: http://bugs.php.net/fix.php?id=25191&r=isapi > Install GNU Sed:http://bugs.php.net/fix.php?id=25191&r=gnused > > >
[PHP-DOC] #25201 [NEW]: typo in cURL parameter documentation
From: scottm at spamcop dot net Operating system: PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: typo in cURL parameter documentation Description: I was reading the cURL documentation and I noticed that CURL_SSL_VERIFYPEER is referenced on http://uk.php.net/manual/en/function.curl-setopt.php This should actually be CURLOPT_SSL_VERIFYPEER -- Edit bug report at http://bugs.php.net/?id=25201&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25201&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25201&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25201&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25201&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25201&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25201&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25201&r=support Expected behavior: http://bugs.php.net/fix.php?id=25201&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25201&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25201&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25201&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25201&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25201&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25201&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25201&r=gnused
[PHP-DOC] #25196 [Opn->Csd]: typo on ini_set()'s doc page
ID: 25196 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Documentation problem PHP Version: Irrelevant New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-08-21 11:21:12] [EMAIL PROTECTED] Description: can you fix this typo : hyerwave.allow_persistent on http://php.net/manual/en/function.ini-set.php thanks Andrey -- Edit this bug report at http://bugs.php.net/?id=25196&edit=1
[PHP-DOC] cvs: phpdoc /en/reference/info/functions ini-set.xml
didou Thu Aug 21 12:30:25 2003 EDT Modified files: /phpdoc/en/reference/info/functions ini-set.xml Log: closing #25196 Index: phpdoc/en/reference/info/functions/ini-set.xml diff -u phpdoc/en/reference/info/functions/ini-set.xml:1.29 phpdoc/en/reference/info/functions/ini-set.xml:1.30 --- phpdoc/en/reference/info/functions/ini-set.xml:1.29 Tue Aug 19 16:32:31 2003 +++ phpdoc/en/reference/info/functions/ini-set.xml Thu Aug 21 12:30:24 2003 @@ -1,5 +1,5 @@ - + @@ -168,7 +168,7 @@ PHP_INI_SYSTEM - hyerwave.allow_persistent + hyperwave.allow_persistent "0" PHP_INI_SYSTEM
[PHP-DOC] #25197 [Opn->Bgs]: typo on ini_set()'s doc page
ID: 25197 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. duplicated Previous Comments: [2003-08-21 11:22:41] [EMAIL PROTECTED] Description: can you fix this typo : hyerwave.allow_persistent on http://php.net/manual/en/function.ini-set.php thanks Andrey -- Edit this bug report at http://bugs.php.net/?id=25197&edit=1
[PHP-DOC] #25196 [NEW]: typo on ini_set()'s doc page
From: [EMAIL PROTECTED] Operating system: PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: typo on ini_set()'s doc page Description: can you fix this typo : hyerwave.allow_persistent on http://php.net/manual/en/function.ini-set.php thanks Andrey -- Edit bug report at http://bugs.php.net/?id=25196&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25196&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25196&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25196&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25196&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25196&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25196&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25196&r=support Expected behavior: http://bugs.php.net/fix.php?id=25196&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25196&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25196&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25196&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25196&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25196&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25196&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25196&r=gnused
[PHP-DOC] #25197 [NEW]: typo on ini_set()'s doc page
From: [EMAIL PROTECTED] Operating system: PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: typo on ini_set()'s doc page Description: can you fix this typo : hyerwave.allow_persistent on http://php.net/manual/en/function.ini-set.php thanks Andrey -- Edit bug report at http://bugs.php.net/?id=25197&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25197&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25197&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25197&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25197&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25197&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25197&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25197&r=support Expected behavior: http://bugs.php.net/fix.php?id=25197&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25197&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25197&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25197&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25197&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25197&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25197&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25197&r=gnused
[PHP-DOC] #25191 [Opn->Csd]: Suggestion for a paragraph in the security chapter
ID: 25191 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Irrelevant PHP Version: Irrelevant New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. thanks fo reporting this typo. Previous Comments: [2003-08-21 09:36:34] [EMAIL PROTECTED] Description: This is a trivial issue. The section `security.cgi-bin.doc-root' begins like this: "To include active content, like scripts and executables, in the web server document directories is sometimes consider an insecure practice." I'd suggest a slightly different wording for this sentence. Something like: "Including active content in the web server document directories, like scripts and executables, is sometimes considered an insecure practice." My main concern is with the word `consider', which I think should be replaced by `considered'. My native language is not English, though, so I'm not quite sure if this is an issue at all. Thanks. -- Edit this bug report at http://bugs.php.net/?id=25191&edit=1
[PHP-DOC] cvs: phpdoc /en/security index.xml
ali Thu Aug 21 10:41:32 2003 EDT Modified files: /phpdoc/en/security index.xml Log: fixed typo (bug #25191) Index: phpdoc/en/security/index.xml diff -u phpdoc/en/security/index.xml:1.58 phpdoc/en/security/index.xml:1.59 --- phpdoc/en/security/index.xml:1.58 Fri Jun 20 15:21:59 2003 +++ phpdoc/en/security/index.xmlThu Aug 21 10:41:32 2003 @@ -1,5 +1,5 @@ - + Security @@ -219,7 +219,7 @@ Case 3: setting doc_root or user_dir To include active content, like scripts and executables, in the - web server document directories is sometimes consider an insecure + web server document directories is sometimes considered an insecure practice. If, because of some configuration mistake, the scripts are not executed but displayed as regular HTML documents, this may result in leakage of intellectual property or security
[PHP-DOC] #25191 [NEW]: Suggestion for a paragraph in the security chapter
From: [EMAIL PROTECTED] Operating system: Irrelevant PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: Suggestion for a paragraph in the security chapter Description: This is a trivial issue. The section `security.cgi-bin.doc-root' begins like this: "To include active content, like scripts and executables, in the web server document directories is sometimes consider an insecure practice." I'd suggest a slightly different wording for this sentence. Something like: "Including active content in the web server document directories, like scripts and executables, is sometimes considered an insecure practice." My main concern is with the word `consider', which I think should be replaced by `considered'. My native language is not English, though, so I'm not quite sure if this is an issue at all. Thanks. -- Edit bug report at http://bugs.php.net/?id=25191&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25191&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25191&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25191&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25191&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25191&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25191&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25191&r=support Expected behavior: http://bugs.php.net/fix.php?id=25191&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25191&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25191&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25191&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25191&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25191&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25191&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25191&r=gnused
[PHP-DOC] #25189 [Opn->Csd]: Function lists in the manual showing the return type.
ID: 25189 Updated by: [EMAIL PROTECTED] Reported By: richard dot quadling at carval dot co dot uk -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Any PHP Version: Irrelevant New Comment: I guess Mehdi's link solve your problem :) Thus i'm setting the status to closed. -ali Previous Comments: [2003-08-21 09:30:36] richard dot quadling at carval dot co dot uk Aha! Pretty much bang on! Thanks. Richard. [2003-08-21 09:27:09] [EMAIL PROTECTED] Is that what you need ? http://cvs.php.net/co.php/phpdoc/funcsummary.txt?login=2&r=1.22 didou [2003-08-21 09:24:12] richard dot quadling at carval dot co dot uk I suppose you are right. It is just that I would like to see the function that gives the return type I want. Often the return type and parameters suggest more about what the function does than its name. Richard. [2003-08-21 09:19:47] [EMAIL PROTECTED] As it says it is the TOC which usually does not give the user detailed information about the usage of the function, but states briefly what this function does. If the function is needed for you to be used, you can just click on the link to get the doc-page of that special function which will also include the prototype-infos. In my oppinion your request would just confuse and will not lead to a more userfriendly documentation. any comments? -ali [2003-08-21 09:04:21] richard dot quadling at carval dot co dot uk Description: At the moment, you get this ... Table of Contents aspell_check_raw -- Check a word without changing its case or trying to trim it [deprecated] aspell_check -- Check a word [deprecated] aspell_new -- Load a new dictionary [deprecated] aspell_suggest -- Suggest spellings of a word [deprecated] When would be REALLY useful is the return types and parameters. E.g. Table of Contents bool aspell_check_raw ( int dictionary_link, string word) -- Check a word without changing its case or trying to trim it [deprecated] bool aspell_check ( int dictionary_link, string word) -- Check a word [deprecated] int aspell_new ( string master [, string personal]) -- Load a new dictionary [deprecated] array aspell_suggest ( int dictionary_link, string word) -- Suggest spellings of a word [deprecated] Why? When you are looking for a function that returns a type you can see what it may be called as sometimes the names are not what you expect. NOTE: I used aspell as an example as it only had a few entries. Regards, Richard Quadling. -- Edit this bug report at http://bugs.php.net/?id=25189&edit=1
[PHP-DOC] #25189 [Opn]: Function lists in the manual showing the return type.
ID: 25189 User updated by: richard dot quadling at carval dot co dot uk Reported By: richard dot quadling at carval dot co dot uk Status: Open Bug Type: Documentation problem Operating System: Any PHP Version: Irrelevant New Comment: Aha! Pretty much bang on! Thanks. Richard. Previous Comments: [2003-08-21 09:27:09] [EMAIL PROTECTED] Is that what you need ? http://cvs.php.net/co.php/phpdoc/funcsummary.txt?login=2&r=1.22 didou [2003-08-21 09:24:12] richard dot quadling at carval dot co dot uk I suppose you are right. It is just that I would like to see the function that gives the return type I want. Often the return type and parameters suggest more about what the function does than its name. Richard. [2003-08-21 09:19:47] [EMAIL PROTECTED] As it says it is the TOC which usually does not give the user detailed information about the usage of the function, but states briefly what this function does. If the function is needed for you to be used, you can just click on the link to get the doc-page of that special function which will also include the prototype-infos. In my oppinion your request would just confuse and will not lead to a more userfriendly documentation. any comments? -ali [2003-08-21 09:04:21] richard dot quadling at carval dot co dot uk Description: At the moment, you get this ... Table of Contents aspell_check_raw -- Check a word without changing its case or trying to trim it [deprecated] aspell_check -- Check a word [deprecated] aspell_new -- Load a new dictionary [deprecated] aspell_suggest -- Suggest spellings of a word [deprecated] When would be REALLY useful is the return types and parameters. E.g. Table of Contents bool aspell_check_raw ( int dictionary_link, string word) -- Check a word without changing its case or trying to trim it [deprecated] bool aspell_check ( int dictionary_link, string word) -- Check a word [deprecated] int aspell_new ( string master [, string personal]) -- Load a new dictionary [deprecated] array aspell_suggest ( int dictionary_link, string word) -- Suggest spellings of a word [deprecated] Why? When you are looking for a function that returns a type you can see what it may be called as sometimes the names are not what you expect. NOTE: I used aspell as an example as it only had a few entries. Regards, Richard Quadling. -- Edit this bug report at http://bugs.php.net/?id=25189&edit=1
[PHP-DOC] #25189 [Opn]: Function lists in the manual showing the return type.
ID: 25189 Updated by: [EMAIL PROTECTED] Reported By: richard dot quadling at carval dot co dot uk Status: Open Bug Type: Documentation problem Operating System: Any PHP Version: Irrelevant New Comment: Is that what you need ? http://cvs.php.net/co.php/phpdoc/funcsummary.txt?login=2&r=1.22 didou Previous Comments: [2003-08-21 09:24:12] richard dot quadling at carval dot co dot uk I suppose you are right. It is just that I would like to see the function that gives the return type I want. Often the return type and parameters suggest more about what the function does than its name. Richard. [2003-08-21 09:19:47] [EMAIL PROTECTED] As it says it is the TOC which usually does not give the user detailed information about the usage of the function, but states briefly what this function does. If the function is needed for you to be used, you can just click on the link to get the doc-page of that special function which will also include the prototype-infos. In my oppinion your request would just confuse and will not lead to a more userfriendly documentation. any comments? -ali [2003-08-21 09:04:21] richard dot quadling at carval dot co dot uk Description: At the moment, you get this ... Table of Contents aspell_check_raw -- Check a word without changing its case or trying to trim it [deprecated] aspell_check -- Check a word [deprecated] aspell_new -- Load a new dictionary [deprecated] aspell_suggest -- Suggest spellings of a word [deprecated] When would be REALLY useful is the return types and parameters. E.g. Table of Contents bool aspell_check_raw ( int dictionary_link, string word) -- Check a word without changing its case or trying to trim it [deprecated] bool aspell_check ( int dictionary_link, string word) -- Check a word [deprecated] int aspell_new ( string master [, string personal]) -- Load a new dictionary [deprecated] array aspell_suggest ( int dictionary_link, string word) -- Suggest spellings of a word [deprecated] Why? When you are looking for a function that returns a type you can see what it may be called as sometimes the names are not what you expect. NOTE: I used aspell as an example as it only had a few entries. Regards, Richard Quadling. -- Edit this bug report at http://bugs.php.net/?id=25189&edit=1
[PHP-DOC] #25189 [Opn]: Function lists in the manual showing the return type.
ID: 25189 User updated by: richard dot quadling at carval dot co dot uk Reported By: richard dot quadling at carval dot co dot uk Status: Open Bug Type: Documentation problem Operating System: Any PHP Version: Irrelevant New Comment: I suppose you are right. It is just that I would like to see the function that gives the return type I want. Often the return type and parameters suggest more about what the function does than its name. Richard. Previous Comments: [2003-08-21 09:19:47] [EMAIL PROTECTED] As it says it is the TOC which usually does not give the user detailed information about the usage of the function, but states briefly what this function does. If the function is needed for you to be used, you can just click on the link to get the doc-page of that special function which will also include the prototype-infos. In my oppinion your request would just confuse and will not lead to a more userfriendly documentation. any comments? -ali [2003-08-21 09:04:21] richard dot quadling at carval dot co dot uk Description: At the moment, you get this ... Table of Contents aspell_check_raw -- Check a word without changing its case or trying to trim it [deprecated] aspell_check -- Check a word [deprecated] aspell_new -- Load a new dictionary [deprecated] aspell_suggest -- Suggest spellings of a word [deprecated] When would be REALLY useful is the return types and parameters. E.g. Table of Contents bool aspell_check_raw ( int dictionary_link, string word) -- Check a word without changing its case or trying to trim it [deprecated] bool aspell_check ( int dictionary_link, string word) -- Check a word [deprecated] int aspell_new ( string master [, string personal]) -- Load a new dictionary [deprecated] array aspell_suggest ( int dictionary_link, string word) -- Suggest spellings of a word [deprecated] Why? When you are looking for a function that returns a type you can see what it may be called as sometimes the names are not what you expect. NOTE: I used aspell as an example as it only had a few entries. Regards, Richard Quadling. -- Edit this bug report at http://bugs.php.net/?id=25189&edit=1
[PHP-DOC] #25189 [Opn]: Function lists in the manual showing the return type.
ID: 25189 Updated by: [EMAIL PROTECTED] Reported By: richard dot quadling at carval dot co dot uk Status: Open Bug Type: Documentation problem Operating System: Any PHP Version: Irrelevant New Comment: As it says it is the TOC which usually does not give the user detailed information about the usage of the function, but states briefly what this function does. If the function is needed for you to be used, you can just click on the link to get the doc-page of that special function which will also include the prototype-infos. In my oppinion your request would just confuse and will not lead to a more userfriendly documentation. any comments? -ali Previous Comments: [2003-08-21 09:04:21] richard dot quadling at carval dot co dot uk Description: At the moment, you get this ... Table of Contents aspell_check_raw -- Check a word without changing its case or trying to trim it [deprecated] aspell_check -- Check a word [deprecated] aspell_new -- Load a new dictionary [deprecated] aspell_suggest -- Suggest spellings of a word [deprecated] When would be REALLY useful is the return types and parameters. E.g. Table of Contents bool aspell_check_raw ( int dictionary_link, string word) -- Check a word without changing its case or trying to trim it [deprecated] bool aspell_check ( int dictionary_link, string word) -- Check a word [deprecated] int aspell_new ( string master [, string personal]) -- Load a new dictionary [deprecated] array aspell_suggest ( int dictionary_link, string word) -- Suggest spellings of a word [deprecated] Why? When you are looking for a function that returns a type you can see what it may be called as sometimes the names are not what you expect. NOTE: I used aspell as an example as it only had a few entries. Regards, Richard Quadling. -- Edit this bug report at http://bugs.php.net/?id=25189&edit=1
[PHP-DOC] #25189 [NEW]: Function lists in the manual showing the return type.
From: richard dot quadling at carval dot co dot uk Operating system: Any PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: Function lists in the manual showing the return type. Description: At the moment, you get this ... Table of Contents aspell_check_raw -- Check a word without changing its case or trying to trim it [deprecated] aspell_check -- Check a word [deprecated] aspell_new -- Load a new dictionary [deprecated] aspell_suggest -- Suggest spellings of a word [deprecated] When would be REALLY useful is the return types and parameters. E.g. Table of Contents bool aspell_check_raw ( int dictionary_link, string word) -- Check a word without changing its case or trying to trim it [deprecated] bool aspell_check ( int dictionary_link, string word) -- Check a word [deprecated] int aspell_new ( string master [, string personal]) -- Load a new dictionary [deprecated] array aspell_suggest ( int dictionary_link, string word) -- Suggest spellings of a word [deprecated] Why? When you are looking for a function that returns a type you can see what it may be called as sometimes the names are not what you expect. NOTE: I used aspell as an example as it only had a few entries. Regards, Richard Quadling. -- Edit bug report at http://bugs.php.net/?id=25189&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25189&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25189&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25189&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25189&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25189&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25189&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25189&r=support Expected behavior: http://bugs.php.net/fix.php?id=25189&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25189&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25189&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25189&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25189&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25189&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25189&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25189&r=gnused
Re: [PHP-DOC] Notes systems
On Sunday, August 17, 2003, at 08:56 AM, Mehdi Achour wrote: It tends to vary over time. When people are very active, the notes are well maintained. Sometimes people become less active. From what I can see, I think the manual is still totally flooded with confusing, contradictory, and poorly written notes. As far as "who is allowed to manage a given page of notes", I think the bare minimum should be 1. Those who know PHP, and the note subject, well. 2. Those who have experience with writing PHP's documentation (preferably). If notes editors are also writing documentation, *most* of the good notes can be deleted as they are integrated. And what about an abusive note ? Do we need to know how work the domxml extension to delete some non-related note ? Interesting. I would say: You *must* know everything about the domxml extension to *know* if the note is unrelated. If it was abusive and unhelpful, delete. We are ok. I wasn't talking about the skills needed to moderate the notes, but this can also be discussed. I was objecting for allowing other ppl (not memebers of the PHP team) to moderate the notes as I've seen that it was dicussed. /me checks out the php team list A good 200+ people. Most of the people *know* their work. If an Oracle expert starts slamming MySQL , corrections will happen. I, personally, have not seen a great loss in the notes. Perhaps some examples would help. Once again, you're not getting what I'm saying (maybe my english is too bad, but let's try again :) ) There was a discussion talking about allowing some visitors (not from the PHP team !) to moderate the notes. IMHO, there is no need for that, we (PHP team) are enough. See what I mean ? (/me hopes so) 2) Reasons for suppression : As approached in my first mail, we see from time to time abuses in the moderation, Rather than adding to the workload for each note, how about correcting the actions of the abuser themselves? You mean posting the note again if it was deleted ? Who will take care ? If someone wanted to abuse the system: Everytime a MySQL fanatic posted a message that MySQL can do transactions... a PostgreSQL fanatic could delete it Eventually, php.net would see the cvs churn. I hope Uhm... HEY! OVER HERE! So we need [EMAIL PROTECTED] ? :) Would that be a more effective solution than adding a greater workload to a simple system? [snip] Abusing with an invalid reason is more critical then abusing with no reason at all. Having the need to supply a reason will *maybe* make the abuser think twice before deleting the note. LOL. Ok, this is cultural. One more occasion to fit our readers needs is lost here. some notes disserve to be on the users notes, without being deleted nor integrated. Can you provide some examples? I perceive the optimal manual as a manual without *any* notes. If the manual is good enough, no additional notes and explanations would ever be needed. So, if a page *has* notes, that is a sign that more effort should be applied to improving the documentation... to a point where PHP no longer requires "external help". For example, a trick on the mysql_num_rows page showing the use of COUNT() (mysql function) to get the number of records in a table instead of doing mysql_num_rows(mysql_query('select * from foo')); That's about MySql magic, not PHP. And ? It's cool to see this in a note, isn't ? Even if it's not related to PHP itself, it may help the PHP users This can not be integrated to the manual (or we'll have to introduce all the optimization stuff) but is really usefull for newbies (when I've started PHP/MySQL I was using the bad way =D) there's a lot of examples of this kind. That's not about PHP. A new note is posted : - if the note should be deleted (deleted, not rejected as described by the current howto) we do [snip] This is missing a large number of "other" reasons for deleting/rejecting notes, here are some reasons from poking around notes tonight: 12. Coding-101-notes: Notes that mention that things like "closing quotes" matter. (Uhm...) (etc.) nice shot :) Delete a few hundred a night. Fun. Real fun. ;-) hehe, you know how to fight insomnia now ;) didou
[PHP-DOC] #25186 [Bgs->Opn]: php_uname - not the build os, but the running os
ID: 25186 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type:Documentation problem PHP Version: Irrelevant New Comment: sorry, I need some coffee.. :) forget what I've said Previous Comments: [2003-08-21 05:45:52] [EMAIL PROTECTED] Please don't report bugs for the notes in the manual. See http://www.php.net/manual/en/about.notes.php you can send us a mail at [EMAIL PROTECTED] if you want us to remove some notes. cheers, didou [2003-08-21 05:42:22] daveb at optusnet dot com dot au To me it looks like: On Windows, it's always the running OS. On *nix, it's the running OS except when the call to uname() fails or when doesn't exist, then it falls back to the build OS. As for the PHP_OS constant, it seems to always be the build OS. So the documentation appears to needs work. [2003-08-21 05:26:18] [EMAIL PROTECTED] Description: Is this note correct? vbhackattack at hotmail dot com 24-Mar-2003 05:17 According to the source code for this function (/ext/standard/info.c), the description is not correct. The function returns information about the operating system PHP is _running_ on, not built on. For example, if PHP was build on Win2000 but is running on WinXP, the function should report a version number appropriate for WinXP. I have not tested this, just read the source code which calls the WinAPI function GetVersion() or the *nix function uname() at _run_ time. John -- Edit this bug report at http://bugs.php.net/?id=25186&edit=1
[PHP-DOC] #25186 [Opn->Bgs]: php_uname - not the build os, but the running os
ID: 25186 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type:Documentation problem PHP Version: Irrelevant New Comment: Please don't report bugs for the notes in the manual. See http://www.php.net/manual/en/about.notes.php you can send us a mail at [EMAIL PROTECTED] if you want us to remove some notes. cheers, didou Previous Comments: [2003-08-21 05:42:22] daveb at optusnet dot com dot au To me it looks like: On Windows, it's always the running OS. On *nix, it's the running OS except when the call to uname() fails or when doesn't exist, then it falls back to the build OS. As for the PHP_OS constant, it seems to always be the build OS. So the documentation appears to needs work. [2003-08-21 05:26:18] [EMAIL PROTECTED] Description: Is this note correct? vbhackattack at hotmail dot com 24-Mar-2003 05:17 According to the source code for this function (/ext/standard/info.c), the description is not correct. The function returns information about the operating system PHP is _running_ on, not built on. For example, if PHP was build on Win2000 but is running on WinXP, the function should report a version number appropriate for WinXP. I have not tested this, just read the source code which calls the WinAPI function GetVersion() or the *nix function uname() at _run_ time. John -- Edit this bug report at http://bugs.php.net/?id=25186&edit=1
[PHP-DOC] #25186 [Com]: php_uname - not the build os, but the running os
ID: 25186 Comment by: daveb at optusnet dot com dot au Reported By: [EMAIL PROTECTED] Status: Open Bug Type:Documentation problem PHP Version: Irrelevant New Comment: To me it looks like: On Windows, it's always the running OS. On *nix, it's the running OS except when the call to uname() fails or when doesn't exist, then it falls back to the build OS. As for the PHP_OS constant, it seems to always be the build OS. So the documentation appears to needs work. Previous Comments: [2003-08-21 05:26:18] [EMAIL PROTECTED] Description: Is this note correct? vbhackattack at hotmail dot com 24-Mar-2003 05:17 According to the source code for this function (/ext/standard/info.c), the description is not correct. The function returns information about the operating system PHP is _running_ on, not built on. For example, if PHP was build on Win2000 but is running on WinXP, the function should report a version number appropriate for WinXP. I have not tested this, just read the source code which calls the WinAPI function GetVersion() or the *nix function uname() at _run_ time. John -- Edit this bug report at http://bugs.php.net/?id=25186&edit=1
[PHP-DOC] #25186 [NEW]: php_uname - not the build os, but the running os
From: [EMAIL PROTECTED] Operating system: PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: php_uname - not the build os, but the running os Description: Is this note correct? vbhackattack at hotmail dot com 24-Mar-2003 05:17 According to the source code for this function (/ext/standard/info.c), the description is not correct. The function returns information about the operating system PHP is _running_ on, not built on. For example, if PHP was build on Win2000 but is running on WinXP, the function should report a version number appropriate for WinXP. I have not tested this, just read the source code which calls the WinAPI function GetVersion() or the *nix function uname() at _run_ time. John -- Edit bug report at http://bugs.php.net/?id=25186&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25186&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25186&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25186&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25186&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25186&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25186&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25186&r=support Expected behavior: http://bugs.php.net/fix.php?id=25186&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25186&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25186&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25186&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25186&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25186&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25186&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25186&r=gnused
[PHP-DOC] #25183 [Fbk->Csd]: scan_makefile_in.awk problem
ID: 25183 User updated by: yiwakiri at st dot rim dot or dot jp Reported By: yiwakiri at st dot rim dot or dot jp -Status: Feedback +Status: Closed Bug Type: Documentation problem Operating System: All of Unix like system PHP Version: 4.3.2 New Comment: Is this Documentesion problem, Really? Ok. Let's change a place. It is once made close. Previous Comments: [2003-08-21 00:52:32] [EMAIL PROTECTED] I think your patch does make sense. [case 1] LT_LIBRARY_SOURCES=a \ b \ c mode | sources | actual line 0| | LT_LIBRARY_SOURCES=a \ 1| a | b \ 1| a b | c 0| a b c | [case 2] LT_LIBRARY_SOURCES=a LT_LIBRARY_SOURCES_CPP=b \ c mode | sources | actual line 0| | LT_LIBRARY_SOURCES=a 0| a | LT_LIBRARY_SOURCES_CPP=b \ 1| b | c 0| b c | (In the second case both LT_LIBRARY_SOURCES.* lines should be honoured because those are different in their purpose.) Anyway, I don't think either this is the proper place for us to deal with this kind of issue at. Why not start a new thread in [EMAIL PROTECTED] [2003-08-20 23:35:39] yiwakiri at st dot rim dot or dot jp it is nonsense -- PHP_EXTENSION macro is not outdated as long as a manual is seen. If it uses only PHP_NEW_EXTENSION, you repair a manual. (http://www.php.net/manual/en/zend.configuration-macros.php) It is the problem that what is offered cannot be used. Compatibility with back will be allowed, a manual will be collected, Which is good? [2003-08-20 22:57:21] [EMAIL PROTECTED] You're doing something wrong. And this is not the support forum for 3rd party extensions/development of such. Ask this kind of questions elsewhere. [2003-08-20 22:44:44] yiwakiri at st dot rim dot or dot jp Sorry. The category was mistaken. [2003-08-20 21:00:24] yiwakiri at st dot rim dot or dot jp Description: When creating the extension module of C / C++ mixture, It seems that scan_makefile_in.awk which is not correctly changed into PHP_NEW_EXTENSION macro from PHP_EXTENSION macro e.g. Makefile.in is LTLIBRARY_SOURCES = example1.c LTLIBRARY_SOURCES_CPP = example2.cxx Makefile -- snip -- .NOEXPORT: example2.lo: /home/iwakiri/swig/class/example2.cxx $(phplibdir)/example.la: ./example.la $(LIBTOOL) --mode=install cp ./example.la $(phplibdir) The first line's makerule is lost. Please change as follows: --- php-4.3.2/scan_makefile_in.awk Thu Mar 7 23:17:47 2002 +++ scan_makefile_in.awkThu Aug 21 10:48:57 2003 @@ -5,7 +5,7 @@ mode == 0 && /^LTLIBRARY_SOURCES.*\\$/ { if (match($0, "[^=]*$")) { - sources=substr($0, RSTART, RLENGTH-1) + sources=sources substr($0, RSTART, RLENGTH-1) } mode=1 next @@ -13,7 +13,7 @@ mode == 0 && /^LTLIBRARY_SOURCES.*/ { if (match($0, "[^=]*$")) { - sources=substr($0, RSTART, RLENGTH) + sources=sources substr($0, RSTART, RLENGTH) } } -- Edit this bug report at http://bugs.php.net/?id=25183&edit=1
Re: [PHP-DOC] Notes systems
Didou tries to propose some system, where notes will be categorized "to be integrated", so they can sooner become part of the manual. How does that make them part of the manual sooner? Are doc editors required to look for those tags? Are note/doc people required to work on those categories first? Just because something is "labeled", does it change anything? The idea is that people who are not doc authors would be able to edit notes, and doc authors would look at notes marked as "to be integrated" and would integrate those. This is easier for manual authors, as they don't need to go through a pile of notes, the best ones are already selected. It is also easier to work with the notes and not switch from the notes system to phpdoc XML files while integrating some stuff. You only need to click and go form page to page, and mark notes as you see fit. Further on, people can integrate the notes as time permits. I must point out that I am not in a note maintainer role, so I can only build on the assumptions I have about note maintanance (and on the practice I had ;). The above seems to be sensible to me, but I don't know how more work would this be for note maintainers. I don't have much practice in it. Our users are mostly convinced that the user notes often contain valuable information (more often than crap). We get requests all the time to integrate them in the downloadable versions. I had created the special CHM version, and the feedback I received always pointed to the great inclusion of the user notes This may be an indication that the manual is weak at many places, yes. But it is also an indication IMHO that user notes have their own place. I don't think that this means the notes are "weak", I think it means that the manual is weak. I can absolutely agree that our manual can be enhanced in many ways, and really cannot understand guys still saying we have the best manual. IMHO this is not true [yet]. Goba