[PHP-DOC] #36470 [Opn]: levenshtein with 3 parameters does not work as expected
ID: 36470
Updated by: [EMAIL PROTECTED]
Reported By: chen dot daqi at gmail dot com
Status: Open
-Bug Type: Strings related
+Bug Type: Documentation problem
Operating System: Linux
PHP Version: 5.1.2
New Comment:
Reclassified as docu problem.
Previous Comments:
[2006-02-21 09:18:38] chen dot daqi at gmail dot com
Description:
Hi, levenshtein("abc", "abbc", 2) is valid according to PHP manual, but
in fact it issues a warning and return -1.
Reproduce code:
---
Expected result:
int(2)
Actual result:
--
Warning: levenshtein(): The general Levenshtein support is not there
yet in lev.php on line 2
Warning: levenshtein(): Argument string(s) too long in lev.php on line
2
int(-1)
--
Edit this bug report at http://bugs.php.net/?id=36470&edit=1
Re: [PHP-DOC] spam protection for user notes
Am 21.02.2006 um 19:57 schrieb Nuno Lopes: ... BTW, I don't agree with an 'accept' system. With that, almost zero notes will be approved each day, because no one will like to take the responsability to approve a note. Delete/reject is much simpler and provides a faster way to have good notes on-line. ... Well, after looking at http://www.phpdoc.info/notes/manage.php, I think now that approving notes is really not neccessary. The green color is imho sufficient to identify quickly the notes that need to be reviewed. :-) Sebastian
Re: [PHP-DOC] spam protection for user notes
Sebastian-H. Picklum wrote: > Ohhh. Since when do we have that? Seems that I missed the news... :-) It's been around for quite a while. 1.5 years, I'd guess. I blogged about it a few months back. S
Re: [PHP-DOC] spam protection for user notes
Ohhh. Since when do we have that? Seems that I missed the news... :-) Sebastian Am 21.02.2006 um 19:44 schrieb Sean Coates: Sebastian-H. Picklum wrote: Note weeding in the current form is really not that comfortable. An interface where you can see all newly submitted notes that have not been rejected or deleted (or verified) already would safe a lot of time. That way, every message gets reviewed. Like so? http://www.phpdoc.info/notes/manage.php (-: S
RE: [PHP-DOC] spam protection for user notes
> Sebastian-H. Picklum wrote: > > Hmm, you are completely right. But it's still not that > accessible for > > our fellow programmers who are visually impaired. > > I have 4961 messages in my PHP-Notes box that I simply > haven't had the motivation to check. > > Note weeding is a tedious and thankless task, so I'm all-for > tools that will make this easier. > > I like the CSS CAPTCHA, but it seems relatively easy to break. Yeah, I got distracted by trying a similar inline SVG captcha, as it has a lot more opportunity for obfuscation, as can define fonts/glyphs etc. The CSS could be more difficult. Looking at add-note.php, something simple like adding a hidden form field with some random code, and ensuring it's the same value on submission would aleast prevent spammers directly POST'ing to it. Jared
Re: [PHP-DOC] spam protection for user notes
> Another option (in the short-term) is to simply required a valid email
> address (most of the spam seems to come from the default
> '[EMAIL PROTECTED]' or 'php-general@lists.php.net').
Haven't checked the code recently, but I'm pretty sure a blank name
results in php-general@lists.php.net and a name with no domain ("Bob")
gets osu1 appended ("[EMAIL PROTECTED]").
S
Re: [PHP-DOC] spam protection for user notes
Another option (in the short-term) is to simply required a valid email address (most of the spam seems to come from the default '[EMAIL PROTECTED]' or 'php-general@lists.php.net'). M Nuno Lopes wrote: I don't like those annoying images either. But we must do something.. I'm tired of receiving a lot of spam notes every day. Using the same system as the bugs site seems to be the best choice.. because my attempts to stop spam (by checking IPs blacklists and by using words blacklist) didn't work for long. BTW, I don't agree with an 'accept' system. With that, almost zero notes will be approved each day, because no one will like to take the responsability to approve a note. Delete/reject is much simpler and provides a faster way to have good notes on-line. Nuno
[PHP-DOC] #36474 [Opn]: strtotime: GNU Date Input Format link changed again
ID: 36474 Updated by: [EMAIL PROTECTED] Reported By: mrgrier at yahoo dot com Status: Open Bug Type: Documentation problem Operating System: Any PHP Version: Irrelevant New Comment: Yeh I agree. Doing that shouldn't be difficult. the .re file is quite simple to read (and copy, in this case). Previous Comments: [2006-02-21 13:02:39] [EMAIL PROTECTED] We don't actually implement the things that are written there... so IMO we simply should remove the link and add some examples of our own. [2006-02-21 12:58:58] mrgrier at yahoo dot com Description: strtotime GNU Date Input Format link changed again, to: http://www.gnu.org/software/tar/manual/html_node/Date-input-formats.html Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit this bug report at http://bugs.php.net/?id=36474&edit=1
Re: [PHP-DOC] spam protection for user notes
I don't like those annoying images either. But we must do something.. I'm tired of receiving a lot of spam notes every day. Using the same system as the bugs site seems to be the best choice.. because my attempts to stop spam (by checking IPs blacklists and by using words blacklist) didn't work for long. BTW, I don't agree with an 'accept' system. With that, almost zero notes will be approved each day, because no one will like to take the responsability to approve a note. Delete/reject is much simpler and provides a faster way to have good notes on-line. Nuno
Re: [PHP-DOC] spam protection for user notes
> I would oppose a CAPTCHA, they are evil. Do you have a better solution? S
Re: [PHP-DOC] spam protection for user notes
On Tue, 21 Feb 2006, Sean Coates wrote: > If we do go to a non-handicap-friendly (pardon my use of the word > "handicap" if it's not PC this week) solution, we could always add a > note along the lines of "Note to the visually impaired: this form > contains spam protection in the form of a CAPTCHA image. I would oppose a CAPTCHA, they are evil. Derick
Re: [PHP-DOC] spam protection for user notes
> +1 to "If you experience difficulty with the CAPTCHA image, you can > submit a note by sending an email to [EMAIL PROTECTED]" > > There's no need to limit this option to the visually impaired; it's > also applicable to Mr. Joe Text Browser. :) Agreed. S
Re: [PHP-DOC] spam protection for user notes
Sebastian-H. Picklum wrote: > Note weeding in the current form is really not that comfortable. An > interface where you can see all newly submitted notes that have not been > rejected or deleted (or verified) already would safe a lot of time. That > way, every message gets reviewed. Like so? http://www.phpdoc.info/notes/manage.php (-: S
Re: [PHP-DOC] spam protection for user notes
On 2/21/06, Sean Coates <[EMAIL PROTECTED]> wrote: > Sebastian-H. Picklum wrote: > > Hmm, you are completely right. But it's still not that accessible for > > our fellow programmers who are visually impaired. > > I have 4961 messages in my PHP-Notes box that I simply haven't had the > motivation to check. > > Note weeding is a tedious and thankless task, so I'm all-for tools that > will make this easier. > > I like the CSS CAPTCHA, but it seems relatively easy to break. > > If we do go to a non-handicap-friendly (pardon my use of the word > "handicap" if it's not PC this week) solution, we could always add a > note along the lines of "Note to the visually impaired: this form > contains spam protection in the form of a CAPTCHA image. We're sorry > that this is inconvenient for you. To submit a note, please send email > to [EMAIL PROTECTED], and we would be happy to handle the note > submission for you." to the submission form. > > The volume here would be minimal. > > S > +1 to "If you experience difficulty with the CAPTCHA image, you can submit a note by sending an email to [EMAIL PROTECTED]" There's no need to limit this option to the visually impaired; it's also applicable to Mr. Joe Text Browser. :)
Re: [PHP-DOC] spam protection for user notes
Okay, posting to php-notes@ would be another solution. But on the other hand: Why don't we check the submitted notes for specific words that are only used in SPAM messages in the first place and mark them as suspicious on [EMAIL PROTECTED] So the SPAM-Protection is transparent and finding possible unwanted messages is easier. Note weeding in the current form is really not that comfortable. An interface where you can see all newly submitted notes that have not been rejected or deleted (or verified) already would safe a lot of time. That way, every message gets reviewed. Viele Grüße Sebastian Am 21.02.2006 um 19:13 schrieb Sean Coates: Sebastian-H. Picklum wrote: Hmm, you are completely right. But it's still not that accessible for our fellow programmers who are visually impaired. I have 4961 messages in my PHP-Notes box that I simply haven't had the motivation to check. Note weeding is a tedious and thankless task, so I'm all-for tools that will make this easier. I like the CSS CAPTCHA, but it seems relatively easy to break. If we do go to a non-handicap-friendly (pardon my use of the word "handicap" if it's not PC this week) solution, we could always add a note along the lines of "Note to the visually impaired: this form contains spam protection in the form of a CAPTCHA image. We're sorry that this is inconvenient for you. To submit a note, please send email to [EMAIL PROTECTED], and we would be happy to handle the note submission for you." to the submission form. The volume here would be minimal. S
Re: [PHP-DOC] spam protection for user notes
Sebastian-H. Picklum wrote: > Hmm, you are completely right. But it's still not that accessible for > our fellow programmers who are visually impaired. I have 4961 messages in my PHP-Notes box that I simply haven't had the motivation to check. Note weeding is a tedious and thankless task, so I'm all-for tools that will make this easier. I like the CSS CAPTCHA, but it seems relatively easy to break. If we do go to a non-handicap-friendly (pardon my use of the word "handicap" if it's not PC this week) solution, we could always add a note along the lines of "Note to the visually impaired: this form contains spam protection in the form of a CAPTCHA image. We're sorry that this is inconvenient for you. To submit a note, please send email to [EMAIL PROTECTED], and we would be happy to handle the note submission for you." to the submission form. The volume here would be minimal. S
Re: [PHP-DOC] Minor changes in en/reference/pdo
Thanks Kohei -- I committed your patch (and will take a look at xml_proto.php to see if it needs a corresponding tweak). Dan On 2/21/06, Kohei Yoshida <[EMAIL PROTECTED]> wrote: > Hi there, > > In working with the phpdoc xml files from CVS I've made some minor > modifications. Please see the attachment for the diff output. The two > instances of "&Description" were changed to "&Description;" because they > were chalking my XML parser. It may not matter much because they are > both within a comment block, but I'll send you the diff, nonetheless. > > Best regards, > Kohei > > > -- > Kohei Yoshida, Software Engineer > SlickEdit Inc. [ http://www.slickedit.com/ ] > > >
[PHP-DOC] cvs: phpdoc /en/reference/pdo/functions PDOStatement-closeCursor.xml PDOStatement-getColumnMeta.xml
dbs Tue Feb 21 16:45:06 2006 UTC Modified files: /phpdoc/en/reference/pdo/functions PDOStatement-closeCursor.xml PDOStatement-getColumnMeta.xml Log: Apply Kohei Yoshida's patch for correct entities inside comments. http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/pdo/functions/PDOStatement-closeCursor.xml?r1=1.5&r2=1.6&diff_format=u Index: phpdoc/en/reference/pdo/functions/PDOStatement-closeCursor.xml diff -u phpdoc/en/reference/pdo/functions/PDOStatement-closeCursor.xml:1.5 phpdoc/en/reference/pdo/functions/PDOStatement-closeCursor.xml:1.6 --- phpdoc/en/reference/pdo/functions/PDOStatement-closeCursor.xml:1.5 Sun Nov 27 06:45:14 2005 +++ phpdoc/en/reference/pdo/functions/PDOStatement-closeCursor.xml Tue Feb 21 16:45:06 2006 @@ -1,5 +1,5 @@ - + @@ -67,7 +67,7 @@ &Version; - &Description + &Description; http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/pdo/functions/PDOStatement-getColumnMeta.xml?r1=1.3&r2=1.4&diff_format=u Index: phpdoc/en/reference/pdo/functions/PDOStatement-getColumnMeta.xml diff -u phpdoc/en/reference/pdo/functions/PDOStatement-getColumnMeta.xml:1.3 phpdoc/en/reference/pdo/functions/PDOStatement-getColumnMeta.xml:1.4 --- phpdoc/en/reference/pdo/functions/PDOStatement-getColumnMeta.xml:1.3 Tue Sep 20 08:22:29 2005 +++ phpdoc/en/reference/pdo/functions/PDOStatement-getColumnMeta.xmlTue Feb 21 16:45:06 2006 @@ -1,5 +1,5 @@ - + @@ -124,7 +124,7 @@ &Version; - &Description + &Description;
Re: [PHP-DOC] Patch
Thanks Owain. Committed the patch. Dan On 2/21/06, Owain Jones <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm a coop student working at ibm and I've been assigned to update the > idb_db2 docs for the PHP manual. I added some constants definitions as > follows: > > > As of release 1.1.6, users can set DB2_ATTR_CASE as a connection attribute. > As of release 1.2.0, users can set CURSOR type as a connection attribute. > As of release 1.2.0, users can change attributes on persistent connections. > The patch data follows: > > Index: en/reference/ibm_db2/constants.xml > === > RCS file: > /repository/phpdoc/en/reference/ibm_db2/constants.xml,v > retrieving revision 1.6 > diff -u -u -r1.6 constants.xml > --- en/reference/ibm_db2/constants.xml25 Jan 2006 > 04:26:17 -1.6 > +++ en/reference/ibm_db2/constants.xml17 Feb 2006 > 16:23:36 - > @@ -169,6 +169,39 @@ > > > > + > + > +DB2_CASE_NATURAL > + (integer) > + > + > + > + Specifies that column names will be returned in their natural case. > + > + > + > + > + > +DB2_CASE_LOWER > + (integer) > + > + > + > + Specifies that column names will be returned in lower case. > + > + > + > + > + > +DB2_CASE_UPPER > + (integer) > + > + > + > + Specifies that column names will be returned in upper case. > + > + > + > > > > Index: en/reference/ibm_db2/functions/db2-connect.xml > === > RCS file: > /repository/phpdoc/en/reference/ibm_db2/functions/db2-connect.xml,v > retrieving revision 1.6 > diff -u -u -r1.6 db2-connect.xml > --- en/reference/ibm_db2/functions/db2-connect.xml > 12 Jul 2005 17:39:24 -1.6 > +++ en/reference/ibm_db2/functions/db2-connect.xml > 17 Feb 2006 16:23:36 - > @@ -132,6 +132,39 @@ > > > > + > + DB2_ATTR_CASE > + > + > + Passing the DB2_CASE_NATURAL > value specifies > + that column names are returned in natural case. > + > + > + Passing the DB2_CASE_LOWER > value specifies > + that column names are returned in lower case. > + > + > + Passing the DB2_CASE_UPPER > value specifies > + that column names are returned in upper case. > + > + > + > + > + CURSOR > + > + > + Passing the DB2_FORWARD_ONLY > value specifies a > + forward-only cursor for a statement resource. This is the > default > + cursor type and is supported on all database servers. > + > + > + Passing the DB2_SCROLLABLE > value specifies a > + scrollable cursor for a statement resource. This mode enables > + random access to rows in a result set, but currently is > supported > + only by IBM DB2 Universal Database. > + > + > + > > > > Index: en/reference/ibm_db2/functions/db2-pconnect.xml > === > RCS file: > /repository/phpdoc/en/reference/ibm_db2/functions/db2-pconnect.xml,v > retrieving revision 1.3 > diff -u -u -r1.3 db2-pconnect.xml > --- en/reference/ibm_db2/functions/db2-pconnect.xml > 12 Jul 2005 17:39:24 -1.3 > +++ en/reference/ibm_db2/functions/db2-pconnect.xml > 17 Feb 2006 16:23:36 - > @@ -32,17 +32,6 @@ > request. > > > - > - Note that you are strongly urged to only use persistent connections on > - connections with autocommit turned on. If you attempt to combine > - transactions with persistent connections, issuing > - db2_commit or > db2_rollback > - against a persistent connection will affect every persistent connection > - that is currently using the same underlying DB2 client connection. You > may > - also rapidly experience locking escalation if you do not use autocommit > for > - your persistent connections. > - > - > > >&reftitle.parameters; > @@ -92,6 +81,39 @@ > > > > + > + DB2_ATTR_CASE > + > + > + Passing the DB2_CASE_NATURAL > value specifies > + that column names are returned in natural case. > + > + > + Passing the DB2_CASE_LOWER > value specifies > + that column names are returned in lower case. > + > + > + Passing the DB2_CASE_UPPER > value specifies > + that column names are returned in upper case. > + > + > + > + > + CURSOR > + > + > + Passing the DB2_FORWARD_ONLY > value specifies a > + forward-only cursor for a statement resource. This is the > defa
[PHP-DOC] cvs: phpdoc /en/reference/ibm_db2 constants.xml /en/reference/ibm_db2/functions db2-connect.xml db2-pconnect.xml
dbs Tue Feb 21 16:42:41 2006 UTC Modified files: /phpdoc/en/reference/ibm_db2constants.xml /phpdoc/en/reference/ibm_db2/functions db2-connect.xml db2-pconnect.xml Log: As of release 1.1.6, users can set DB2_ATTR_CASE as a connection attribute. As of release 1.2.0, users can set CURSOR type as a connection attribute. As of release 1.2.0, users can change attributes on persistent connections. http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/ibm_db2/constants.xml?r1=1.6&r2=1.7&diff_format=u Index: phpdoc/en/reference/ibm_db2/constants.xml diff -u phpdoc/en/reference/ibm_db2/constants.xml:1.6 phpdoc/en/reference/ibm_db2/constants.xml:1.7 --- phpdoc/en/reference/ibm_db2/constants.xml:1.6 Wed Jan 25 04:26:17 2006 +++ phpdoc/en/reference/ibm_db2/constants.xml Tue Feb 21 16:42:41 2006 @@ -1,5 +1,5 @@ - + &reftitle.constants; @@ -169,6 +169,39 @@ + + +DB2_CASE_NATURAL + (integer) + + + + Specifies that column names will be returned in their natural case. + + + + + +DB2_CASE_LOWER + (integer) + + + + Specifies that column names will be returned in lower case. + + + + + +DB2_CASE_UPPER + (integer) + + + + Specifies that column names will be returned in upper case. + + + http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/ibm_db2/functions/db2-connect.xml?r1=1.6&r2=1.7&diff_format=u Index: phpdoc/en/reference/ibm_db2/functions/db2-connect.xml diff -u phpdoc/en/reference/ibm_db2/functions/db2-connect.xml:1.6 phpdoc/en/reference/ibm_db2/functions/db2-connect.xml:1.7 --- phpdoc/en/reference/ibm_db2/functions/db2-connect.xml:1.6 Tue Jul 12 17:39:24 2005 +++ phpdoc/en/reference/ibm_db2/functions/db2-connect.xml Tue Feb 21 16:42:41 2006 @@ -1,5 +1,5 @@ - + @@ -132,6 +132,39 @@ + + DB2_ATTR_CASE + + + Passing the DB2_CASE_NATURAL value specifies + that column names are returned in natural case. + + + Passing the DB2_CASE_LOWER value specifies + that column names are returned in lower case. + + + Passing the DB2_CASE_UPPER value specifies + that column names are returned in upper case. + + + + + CURSOR + + + Passing the DB2_FORWARD_ONLY value specifies a + forward-only cursor for a statement resource. This is the default + cursor type and is supported on all database servers. + + + Passing the DB2_SCROLLABLE value specifies a + scrollable cursor for a statement resource. This mode enables + random access to rows in a result set, but currently is supported + only by IBM DB2 Universal Database. + + + http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/ibm_db2/functions/db2-pconnect.xml?r1=1.3&r2=1.4&diff_format=u Index: phpdoc/en/reference/ibm_db2/functions/db2-pconnect.xml diff -u phpdoc/en/reference/ibm_db2/functions/db2-pconnect.xml:1.3 phpdoc/en/reference/ibm_db2/functions/db2-pconnect.xml:1.4 --- phpdoc/en/reference/ibm_db2/functions/db2-pconnect.xml:1.3 Tue Jul 12 17:39:24 2005 +++ phpdoc/en/reference/ibm_db2/functions/db2-pconnect.xml Tue Feb 21 16:42:41 2006 @@ -1,5 +1,5 @@ - + @@ -32,17 +32,6 @@ request. - - Note that you are strongly urged to only use persistent connections on - connections with autocommit turned on. If you attempt to combine - transactions with persistent connections, issuing - db2_commit or db2_rollback - against a persistent connection will affect every persistent connection - that is currently using the same underlying DB2 client connection. You may - also rapidly experience locking escalation if you do not use autocommit for - your persistent connections. - - &reftitle.parameters; @@ -92,6 +81,39 @@ + + DB2_ATTR_CASE + + + Passing the DB2_CASE_NATURAL value specifies + that column names are returned in natural case. + + + Passing the DB2_CASE_LOWER value specifies + that column names are returned in lower case. + + + Passing the DB2_CASE_UPPER value specifies + that column names are returned in upper case. + + + + + CURSOR + + + Passing the DB2_FORWARD_ONLY value specifies a + forward-only cursor for a statement resource. This is the default + cursor type and is supported on all database servers. + + + Passing the D
[PHP-DOC] Minor changes in en/reference/pdo
Hi there, In working with the phpdoc xml files from CVS I've made some minor modifications. Please see the attachment for the diff output. The two instances of "&Description" were changed to "&Description;" because they were chalking my XML parser. It may not matter much because they are both within a comment block, but I'll send you the diff, nonetheless. Best regards, Kohei -- Kohei Yoshida, Software Engineer SlickEdit Inc. [ http://www.slickedit.com/ ] Index: en/reference/pdo/functions/PDOStatement-closeCursor.xml === RCS file: /repository/phpdoc/en/reference/pdo/functions/PDOStatement-closeCursor.xml,v retrieving revision 1.5 diff -u -r1.5 PDOStatement-closeCursor.xml --- en/reference/pdo/functions/PDOStatement-closeCursor.xml 27 Nov 2005 06:45:14 - 1.5 +++ en/reference/pdo/functions/PDOStatement-closeCursor.xml 10 Feb 2006 16:50:48 - @@ -67,7 +67,7 @@ &Version; - &Description + &Description; Index: en/reference/pdo/functions/PDOStatement-getColumnMeta.xml === RCS file: /repository/phpdoc/en/reference/pdo/functions/PDOStatement-getColumnMeta.xml,v retrieving revision 1.3 diff -u -r1.3 PDOStatement-getColumnMeta.xml --- en/reference/pdo/functions/PDOStatement-getColumnMeta.xml 20 Sep 2005 08:22:29 - 1.3 +++ en/reference/pdo/functions/PDOStatement-getColumnMeta.xml 10 Feb 2006 16:50:48 - @@ -124,7 +124,7 @@ &Version; - &Description + &Description;
[PHP-DOC] cvs: phpdoc /en/reference/sdo_das_xml/functions SDO-DAS-XML-addTypes.xml SDO-DAS-XML-createDocument.xml SDO-DAS-XML-saveFile.xml SDO-DAS-XML-saveString.xml
vrana Tue Feb 21 16:23:49 2006 UTC Modified files: /phpdoc/en/reference/sdo_das_xml/functions SDO-DAS-XML-addTypes.xml SDO-DAS-XML-createDocument.xml SDO-DAS-XML-saveFile.xml SDO-DAS-XML-saveString.xml Log: Fix protos http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-addTypes.xml?r1=1.1&r2=1.2&diff_format=u Index: phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-addTypes.xml diff -u phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-addTypes.xml:1.1 phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-addTypes.xml:1.2 --- phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-addTypes.xml:1.1 Tue Feb 21 16:13:49 2006 +++ phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-addTypes.xml Tue Feb 21 16:23:49 2006 @@ -1,5 +1,5 @@ - + @@ -11,7 +11,7 @@ &reftitle.description; - SDO_DAS_XMLSDO_DAS_XML::addTypes + voidSDO_DAS_XML::addTypes stringxsd_file http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-createDocument.xml?r1=1.1&r2=1.2&diff_format=u Index: phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-createDocument.xml diff -u phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-createDocument.xml:1.1 phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-createDocument.xml:1.2 --- phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-createDocument.xml:1.1 Tue Feb 21 16:13:49 2006 +++ phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-createDocument.xml Tue Feb 21 16:23:49 2006 @@ -1,5 +1,5 @@ - + @@ -10,21 +10,10 @@ &reftitle.description; - - There are three forms for this method call. - - - SDO_DAS_XML_DocumentSDO_DAS_XML::createDocument - - - - SDO_DAS_XML_DocumentSDO_DAS_XML::createDocument - stringdocument element name - SDO_DAS_XML_DocumentSDO_DAS_XML::createDocument - stringdocument element name - stringdocument element namespace URI + stringdocument_element_name + stringdocument_element_namespace_URI &warn.experimental.func; @@ -57,7 +46,7 @@ - document element name + document_element_name @@ -68,7 +57,7 @@ - document element namespace URI + document_element_namespace_URI http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-saveFile.xml?r1=1.1&r2=1.2&diff_format=u Index: phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-saveFile.xml diff -u phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-saveFile.xml:1.1 phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-saveFile.xml:1.2 --- phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-saveFile.xml:1.1 Tue Feb 21 16:13:49 2006 +++ phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-saveFile.xml Tue Feb 21 16:23:49 2006 @@ -1,5 +1,5 @@ - + @@ -14,7 +14,7 @@ voidSDO_DAS_XML::saveFile SDO_XMLDocumentxdoc stringxml_file - integerindent + intindent &warn.experimental.func; http://cvs.php.net/viewcvs.cgi/phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-saveString.xml?r1=1.1&r2=1.2&diff_format=u Index: phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-saveString.xml diff -u phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-saveString.xml:1.1 phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-saveString.xml:1.2 --- phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-saveString.xml:1.1 Tue Feb 21 16:13:49 2006 +++ phpdoc/en/reference/sdo_das_xml/functions/SDO-DAS-XML-saveString.xml Tue Feb 21 16:23:49 2006 @@ -1,5 +1,5 @@ - + @@ -13,7 +13,7 @@ stringSDO_DAS_XML::saveString SDO_XMLDocumentxdoc - integerindent + intindent &warn.experimental.func;
[PHP-DOC] Patch
Hi, I'm a coop student working at ibm and I've been assigned to update the idb_db2 docs for the PHP manual. I added some constants definitions as follows: As of release 1.1.6, users can set DB2_ATTR_CASE as a connection attribute. As of release 1.2.0, users can set CURSOR type as a connection attribute. As of release 1.2.0, users can change attributes on persistent connections. The patch data follows: Index: en/reference/ibm_db2/constants.xml === RCS file: /repository/phpdoc/en/reference/ibm_db2/constants.xml,v retrieving revision 1.6 diff -u -u -r1.6 constants.xml --- en/reference/ibm_db2/constants.xml 25 Jan 2006 04:26:17 - 1.6 +++ en/reference/ibm_db2/constants.xml 17 Feb 2006 16:23:36 - @@ -169,6 +169,39 @@ + + + DB2_CASE_NATURAL + (integer) + + + + Specifies that column names will be returned in their natural case. + + + + + + DB2_CASE_LOWER + (integer) + + + + Specifies that column names will be returned in lower case. + + + + + + DB2_CASE_UPPER + (integer) + + + + Specifies that column names will be returned in upper case. + + + Index: en/reference/ibm_db2/functions/db2-connect.xml === RCS file: /repository/phpdoc/en/reference/ibm_db2/functions/db2-connect.xml,v retrieving revision 1.6 diff -u -u -r1.6 db2-connect.xml --- en/reference/ibm_db2/functions/db2-connect.xml 12 Jul 2005 17:39:24 - 1.6 +++ en/reference/ibm_db2/functions/db2-connect.xml 17 Feb 2006 16:23:36 - @@ -132,6 +132,39 @@ + + DB2_ATTR_CASE + + + Passing the DB2_CASE_NATURAL value specifies + that column names are returned in natural case. + + + Passing the DB2_CASE_LOWER value specifies + that column names are returned in lower case. + + + Passing the DB2_CASE_UPPER value specifies + that column names are returned in upper case. + + + + + CURSOR + + + Passing the DB2_FORWARD_ONLY value specifies a + forward-only cursor for a statement resource. This is the default + cursor type and is supported on all database servers. + + + Passing the DB2_SCROLLABLE value specifies a + scrollable cursor for a statement resource. This mode enables + random access to rows in a result set, but currently is supported + only by IBM DB2 Universal Database. + + + Index: en/reference/ibm_db2/functions/db2-pconnect.xml === RCS file: /repository/phpdoc/en/reference/ibm_db2/functions/db2-pconnect.xml,v retrieving revision 1.3 diff -u -u -r1.3 db2-pconnect.xml --- en/reference/ibm_db2/functions/db2-pconnect.xml 12 Jul 2005 17:39:24 - 1.3 +++ en/reference/ibm_db2/functions/db2-pconnect.xml 17 Feb 2006 16:23:36 - @@ -32,17 +32,6 @@ request. - - Note that you are strongly urged to only use persistent connections on - connections with autocommit turned on. If you attempt to combine - transactions with persistent connections, issuing - db2_commit or db2_rollback - against a persistent connection will affect every persistent connection - that is currently using the same underlying DB2 client connection. You may - also rapidly experience locking escalation if you do not use autocommit for - your persistent connections. - - &reftitle.parameters; @@ -92,6 +81,39 @@ + + DB2_ATTR_CASE + + + Passing the DB2_CASE_NATURAL value specifies + that column names are returned in natural case. + + + Passing the DB2_CASE_LOWER value specifies + that column names are returned in lower case. + + + Passing the DB2_CASE_UPPER value specifies + that column names are returned in upper case. + + + + + CURSOR + + + Passing the DB2_FORWARD_ONLY value specifies a + forward-only cursor for a statement resource. This is the default + cursor type and is supported on all database servers. + + + Passing the DB2_SCROLLABLE value specifies a + scrollable cursor for a statement resource. This mode enables + random access to rows in a result set, but currently is supported + only by IBM DB2 Universal Database. + + + Owain -
[PHP-DOC] #36461 [Opn->Bgs]: Constants should only be scalars
ID: 36461 Updated by: [EMAIL PROTECTED] Reported By: mgkimsal at gmail dot com -Status: Open +Status: Bogus Bug Type: Documentation problem Operating System: All PHP Version: Irrelevant New Comment: Wow, I misread your results assuming this wasn't possible. But it is! The following bug report has been reopened so marking this duplicate as bogus. http://bugs.php.net/bug.php?id=29534 Feel free to discuss there. Previous Comments: [2006-02-21 00:47:21] mgkimsal at gmail dot com The documentation I'm referring to is in define(). http://us2.php.net/define This gives the impression that you can only define a constant based on what is in the 'constant' page that you reference. Running the code I provided indicates that a resource handle can be defined into a constant, which is counter to the documentation, or unclear at best. [2006-02-20 22:38:08] [EMAIL PROTECTED] >From the manual (php.net/constants): Only scalar data (boolean, integer, float and string) can be contained in constants. What documentation are you referring to? A resource type is certainly not scalar. [2006-02-20 14:44:48] mgkimsal at gmail dot com Description: I realize this is 18 months late, but why is this bogus? It's not only a winxp problem - this happens on all platforms I've tried (well, win and linux). Nor is this only a PHP5 problem - it's a problem in the 4 series as well (haven't tested 3). Either the docs should be changed, or the code behaviour should be changed. I'm in favor of the latter. While the 'resource' might be constant - "Resource id #4" might always be "Resource id #4", the state of that resource might change (file reading problems, db connection problems, etc.). If the value (or the functional state) of something can change, that's not really 'constant', is it? Also, I'm not sure how resource ID numbers are allocated, so this situation might not happen, but in a resource-intense app, might there be a chance of using a resource, closing it, opening a new one, and getting the same 'id' #? I only found out about this recently, but it seems wrong, and certainly goes against the documentation. Reproduce code: --- Expected result: foo is not a resource Actual result: -- foo is a resource -- Edit this bug report at http://bugs.php.net/?id=36461&edit=1
[PHP-DOC] #29534 [Bgs->Opn]: Resources should be scalars
ID: 29534
Updated by: [EMAIL PROTECTED]
Reported By: tomas_matousek at hotmail dot com
-Status: Bogus
+Status: Open
Bug Type: Documentation problem
Operating System: WinXP
PHP Version: 5.0.0
New Comment:
Maybe we shouldn't, but we can. Shouldn't we document this in a similar
way to the is_scalar() docs (that this behavior may change, do not rely
upon it..." That would seem appropriate.
Previous Comments:
[2004-08-07 16:02:31] [EMAIL PROTECTED]
Andy said some time ago that we shouldn't define resources as
constants.
[2004-08-05 12:58:37] tomas_matousek at hotmail dot com
Description:
A resource can be defined as a constant:
e.g. define("my_file",fopen(...)); or STDIN, STDOUT, STDERR in CLI
mode.
In the "Constants" manual section constant values are constrained to
scalars only.
"Only scalar data (boolean, integer, float and string) can be contained
in constants."
However, a resource is not a scalar (is_scalar returns false).
Moreover, a NULL can be used as a value of a constant.
It's a mess, isn't it?
IMHO a resource should be a scalar. Such a change is acceptable since
there is a notice in the is_scalar() function description which allows
it:
"Note:
is_scalar() does not consider resource type values to be scalar as
resources are abstract datatypes which are currently based on integers.
This implementation detail should not be relied upon, as it may change."
And there should be stated in the constants section of the manual that
a NULL can be also a constant (don't forget to correct an error message
which is reported if one tries to define a constant with a value being
e.g. an array or object).
--
Edit this bug report at http://bugs.php.net/?id=29534&edit=1
Re: [PHP-DOC] spam protection for user notes
Hmm, you are completely right. But it's still not that accessible for our fellow programmers who are visually impaired. Sebastian Am 21.02.2006 um 15:27 schrieb Jared Williams: Well atm, no lynx or braille terminals can submit a bug (afaik) so not sure how much of a problem that is. Jared This CSS-obfuscation would generate problems with text-only readers (lynx or braille terminals), so I don't think it's a good idea. Viele Grüße Sebastian Am 21.02.2006 um 13:49 schrieb Jared Williams: How about this one, I've been experimenting with, uses plain HTML obfuscating the code with various css techiques. http://ren.dotgeek.org/ex/captchacss.php http://ren.dotgeek.org/ex/captchacss.phps Jared I don't think that the math-test would prevent much spam. It's very easy to automatically read and solve these equations. Would a verified note submission (e.g. the user provides his eMail- address and he gets a message where he has to click on a link to publish his note) be a better solution? Personally, I think that even that may be bypassed. Viele Grüße Sebastian Am 21.02.2006 um 12:56 schrieb Friedhelm Betz: Derick Rethans wrote: On Tue, 21 Feb 2006, Dan Scott wrote: Spammers suck. I would be in favour of implementing a basic mathematical skill-testing question a la Lukas Smith's blog at http://pooteeweet.org -- it is a protection method that is still accessible to the visually impaired, unlike classic CAPTCHA. Agreed, spammers suck, but CAPTCHAs too. Yeah, I don't like CAPTCHAs either. Mainly for the reason Dan outlined. Don't let the spammers win! :) Not at all ;-) What about: "basic mathematical skill-testing question" ? Friedhelm
RE: [PHP-DOC] spam protection for user notes
Well atm, no lynx or braille terminals can submit a bug (afaik) so not sure how much of a problem that is. Jared > This CSS-obfuscation would generate problems with text-only > readers (lynx or braille terminals), so I don't think it's a > good idea. > > > Viele Grüße > > Sebastian > > Am 21.02.2006 um 13:49 schrieb Jared Williams: > > > > > How about this one, I've been experimenting with, uses plain HTML > > obfuscating the code with various css techiques. > > > > http://ren.dotgeek.org/ex/captchacss.php > > > > http://ren.dotgeek.org/ex/captchacss.phps > > > > Jared > > > >> > >> I don't think that the math-test would prevent much spam. > >> It's very easy to automatically read and solve these equations. > >> > >> Would a verified note submission (e.g. the user provides his > >> eMail- address and he gets a message where he has to click > on a link > >> to publish his note) be a better solution? Personally, I > think that > >> even that may be bypassed. > >> > >> Viele Grüße > >> > >> Sebastian > >> > >> Am 21.02.2006 um 12:56 schrieb Friedhelm Betz: > >> > >>> Derick Rethans wrote: > On Tue, 21 Feb 2006, Dan Scott wrote: > > Spammers suck. > > > > I would be in favour of implementing a basic mathematical > > skill-testing question a la Lukas Smith's blog at > > http://pooteeweet.org -- it is a protection method that > is still > > accessible to the visually impaired, unlike classic CAPTCHA. > Agreed, spammers suck, but CAPTCHAs too. > >>> > >>> Yeah, I don't like CAPTCHAs either. Mainly for the reason Dan > >>> outlined. > >>> > Don't let the spammers win! :) > >>> Not at all ;-) > >>> > >>> What about: "basic mathematical > >>> skill-testing question" ? > >>> > >>> Friedhelm > >>> > >>> > >> > > > > > > >
Re: [PHP-DOC] spam protection for user notes
This CSS-obfuscation would generate problems with text-only readers (lynx or braille terminals), so I don't think it's a good idea. Viele Grüße Sebastian Am 21.02.2006 um 13:49 schrieb Jared Williams: How about this one, I've been experimenting with, uses plain HTML obfuscating the code with various css techiques. http://ren.dotgeek.org/ex/captchacss.php http://ren.dotgeek.org/ex/captchacss.phps Jared I don't think that the math-test would prevent much spam. It's very easy to automatically read and solve these equations. Would a verified note submission (e.g. the user provides his eMail- address and he gets a message where he has to click on a link to publish his note) be a better solution? Personally, I think that even that may be bypassed. Viele Grüße Sebastian Am 21.02.2006 um 12:56 schrieb Friedhelm Betz: Derick Rethans wrote: On Tue, 21 Feb 2006, Dan Scott wrote: Spammers suck. I would be in favour of implementing a basic mathematical skill-testing question a la Lukas Smith's blog at http://pooteeweet.org -- it is a protection method that is still accessible to the visually impaired, unlike classic CAPTCHA. Agreed, spammers suck, but CAPTCHAs too. Yeah, I don't like CAPTCHAs either. Mainly for the reason Dan outlined. Don't let the spammers win! :) Not at all ;-) What about: "basic mathematical skill-testing question" ? Friedhelm
RE: [PHP-DOC] spam protection for user notes
How about this one, I've been experimenting with, uses plain HTML obfuscating the code with various css techiques. http://ren.dotgeek.org/ex/captchacss.php http://ren.dotgeek.org/ex/captchacss.phps Jared > > I don't think that the math-test would prevent much spam. > It's very easy to automatically read and solve these equations. > > Would a verified note submission (e.g. the user provides his > eMail- address and he gets a message where he has to click on > a link to publish his note) be a better solution? Personally, > I think that even that may be bypassed. > > Viele Grüße > > Sebastian > > Am 21.02.2006 um 12:56 schrieb Friedhelm Betz: > > > Derick Rethans wrote: > >> On Tue, 21 Feb 2006, Dan Scott wrote: > >>> Spammers suck. > >>> > >>> I would be in favour of implementing a basic mathematical > >>> skill-testing question a la Lukas Smith's blog at > >>> http://pooteeweet.org -- it is a protection method that is still > >>> accessible to the visually impaired, unlike classic CAPTCHA. > >> Agreed, spammers suck, but CAPTCHAs too. > > > > Yeah, I don't like CAPTCHAs either. Mainly for the reason Dan > > outlined. > > > >> Don't let the spammers win! :) > > Not at all ;-) > > > > What about: "basic mathematical > > skill-testing question" ? > > > > Friedhelm > > > > >
Re: [PHP-DOC] spam protection for user notes
I don't think that the math-test would prevent much spam. It's very easy to automatically read and solve these equations. Would a verified note submission (e.g. the user provides his eMail- address and he gets a message where he has to click on a link to publish his note) be a better solution? Personally, I think that even that may be bypassed. Viele Grüße Sebastian Am 21.02.2006 um 12:56 schrieb Friedhelm Betz: Derick Rethans wrote: On Tue, 21 Feb 2006, Dan Scott wrote: Spammers suck. I would be in favour of implementing a basic mathematical skill-testing question a la Lukas Smith's blog at http://pooteeweet.org -- it is a protection method that is still accessible to the visually impaired, unlike classic CAPTCHA. Agreed, spammers suck, but CAPTCHAs too. Yeah, I don't like CAPTCHAs either. Mainly for the reason Dan outlined. Don't let the spammers win! :) Not at all ;-) What about: "basic mathematical skill-testing question" ? Friedhelm
[PHP-DOC] #36474 [Opn]: strtotime: GNU Date Input Format link changed again
ID: 36474 Updated by: [EMAIL PROTECTED] Reported By: mrgrier at yahoo dot com Status: Open Bug Type: Documentation problem Operating System: Any PHP Version: Irrelevant New Comment: We don't actually implement the things that are written there... so IMO we simply should remove the link and add some examples of our own. Previous Comments: [2006-02-21 12:58:58] mrgrier at yahoo dot com Description: strtotime GNU Date Input Format link changed again, to: http://www.gnu.org/software/tar/manual/html_node/Date-input-formats.html Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit this bug report at http://bugs.php.net/?id=36474&edit=1
[PHP-DOC] #36474 [NEW]: strtotime: GNU Date Input Format link changed again
From: mrgrier at yahoo dot com Operating system: Any PHP version: Irrelevant PHP Bug Type: Documentation problem Bug description: strtotime: GNU Date Input Format link changed again Description: strtotime GNU Date Input Format link changed again, to: http://www.gnu.org/software/tar/manual/html_node/Date-input-formats.html Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit bug report at http://bugs.php.net/?id=36474&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36474&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36474&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36474&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36474&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36474&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36474&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36474&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36474&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36474&r=support Expected behavior:http://bugs.php.net/fix.php?id=36474&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36474&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36474&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36474&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36474&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36474&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36474&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36474&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36474&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36474&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36474&r=mysqlcfg
Re: [PHP-DOC] spam protection for user notes
Derick Rethans wrote: On Tue, 21 Feb 2006, Dan Scott wrote: Spammers suck. I would be in favour of implementing a basic mathematical skill-testing question a la Lukas Smith's blog at http://pooteeweet.org -- it is a protection method that is still accessible to the visually impaired, unlike classic CAPTCHA. Agreed, spammers suck, but CAPTCHAs too. Yeah, I don't like CAPTCHAs either. Mainly for the reason Dan outlined. Don't let the spammers win! :) Not at all ;-) What about: "basic mathematical skill-testing question" ? Friedhelm
Re: [PHP-DOC] spam protection for user notes
On Tue, 21 Feb 2006, Dan Scott wrote: > Spammers suck. > > I would be in favour of implementing a basic mathematical > skill-testing question a la Lukas Smith's blog at > http://pooteeweet.org -- it is a protection method that is still > accessible to the visually impaired, unlike classic CAPTCHA. Agreed, spammers suck, but CAPTCHAs too. Don't let the spammers win! :) Derick
Re: [PHP-DOC] spam protection for user notes
Spammers suck. I would be in favour of implementing a basic mathematical skill-testing question a la Lukas Smith's blog at http://pooteeweet.org -- it is a protection method that is still accessible to the visually impaired, unlike classic CAPTCHA. Dan On 2/21/06, Friedhelm Betz <[EMAIL PROTECTED]> wrote: > Hi all, > > user notes are spammed in recent days/weeks. > > Should we protect the submission form in some sane way (CAPTCHA)? > > Friedhelm >
[PHP-DOC] spam protection for user notes
Hi all, user notes are spammed in recent days/weeks. Should we protect the submission form in some sane way (CAPTCHA)? Friedhelm
