Re: [PHP-DOC] Notes systems

2003-08-21 Thread Ronald Chmara
On Tuesday, August 19, 2003, at 08:45  AM, Mehdi Achour wrote:
Ronald Chmara wrote:
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.

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 mumble starts slamming MySQL mumble, corrections will happen.

I, personally, have not seen a great loss in the notes. Perhaps some 
examples would help.

 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!

Would that be a more effective solution than adding a greater 
workload to a simple system?
   A smart note, which maybe deserve to be integrated to the manual 
lost, without any
   understable reason :
 note  was deleted from  by [EMAIL PROTECTED]
   Why ? did  read it all ? does he just want to show that 
he's taking care ?
There are a lot of valid reasons for deleting notes... ;-) If one 
cannot *trust* in someone else's  competency to manage the notes, 
adding a bunch of categories that they check off will not fix that 
problem. Rather than abusing without a reason, they can simply 
abuse *with* a reason, valid or otherwise.
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.

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. ;-)

-Bop
Ronald Chmara
Ronin Professional Consulting LLC
678-530-9542
They have computers, and they may have other weapons of mass 
destruction .  --Janet Reno



Re: [PHP-DOC] Notes systems

2003-08-21 Thread Gabor Hojtsy
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



[PHP-DOC] #25183 [Fbk-Csd]: scan_makefile_in.awk problem

2003-08-21 Thread yiwakiri at st dot rim dot or dot jp
 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=25183edit=1



[PHP-DOC] #25186 [NEW]: php_uname - not the build os, but the running os

2003-08-21 Thread [EMAIL PROTECTED]
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=25186edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25186r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25186r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25186r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25186r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25186r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25186r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25186r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25186r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25186r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25186r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25186r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25186r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25186r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=25186r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25186r=gnused



[PHP-DOC] #25186 [Com]: php_uname - not the build os, but the running os

2003-08-21 Thread daveb at optusnet dot com dot au
 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 sys/utsname.h 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=25186edit=1



[PHP-DOC] #25186 [Opn-Bgs]: php_uname - not the build os, but the running os

2003-08-21 Thread didou
 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 sys/utsname.h 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=25186edit=1



[PHP-DOC] #25186 [Bgs-Opn]: php_uname - not the build os, but the running os

2003-08-21 Thread didou
 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 sys/utsname.h 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=25186edit=1



Re: [PHP-DOC] Notes systems

2003-08-21 Thread Mehdi Achour
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 mumble starts slamming MySQL mumble, 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] #25189 [NEW]: Function lists in the manual showing the return type.

2003-08-21 Thread richard dot quadling at carval dot co dot uk
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=25189edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25189r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25189r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25189r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25189r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25189r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25189r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25189r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25189r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25189r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25189r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25189r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25189r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25189r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=25189r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25189r=gnused



[PHP-DOC] #25189 [Opn]: Function lists in the manual showing the return type.

2003-08-21 Thread ali
 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=25189edit=1



[PHP-DOC] #25189 [Opn]: Function lists in the manual showing the return type.

2003-08-21 Thread richard dot quadling at carval dot co dot uk
 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=25189edit=1



[PHP-DOC] #25189 [Opn]: Function lists in the manual showing the return type.

2003-08-21 Thread didou
 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=2r=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=25189edit=1



[PHP-DOC] #25189 [Opn]: Function lists in the manual showing the return type.

2003-08-21 Thread richard dot quadling at carval dot co dot uk
 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=2r=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=25189edit=1



[PHP-DOC] #25189 [Opn-Csd]: Function lists in the manual showing the return type.

2003-08-21 Thread ali
 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=2r=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=25189edit=1



[PHP-DOC] #25191 [NEW]: Suggestion for a paragraph in the security chapter

2003-08-21 Thread [EMAIL PROTECTED]
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=25191edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25191r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25191r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25191r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25191r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25191r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25191r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25191r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25191r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25191r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25191r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25191r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25191r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25191r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=25191r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25191r=gnused



[PHP-DOC] cvs: phpdoc /en/security index.xml

2003-08-21 Thread ali
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 @@
 ?xml version=1.0 encoding=iso-8859-1?
-!-- $Revision: 1.58 $ --
+!-- $Revision: 1.59 $ --
  chapter id=security.index
   titleSecurity/title
 
@@ -219,7 +219,7 @@
 titleCase 3: setting doc_root or user_dir/title
 simpara
  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 [Opn-Csd]: Suggestion for a paragraph in the security chapter

2003-08-21 Thread ali
 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=25191edit=1



[PHP-DOC] #25197 [NEW]: typo on ini_set()'s doc page

2003-08-21 Thread [EMAIL PROTECTED]
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=25197edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25197r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25197r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25197r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25197r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25197r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25197r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25197r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25197r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25197r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25197r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25197r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25197r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25197r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=25197r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25197r=gnused



[PHP-DOC] #25196 [NEW]: typo on ini_set()'s doc page

2003-08-21 Thread [EMAIL PROTECTED]
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=25196edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25196r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25196r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25196r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25196r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25196r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25196r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25196r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25196r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25196r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25196r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25196r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25196r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25196r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=25196r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25196r=gnused



[PHP-DOC] #25197 [Opn-Bgs]: typo on ini_set()'s doc page

2003-08-21 Thread didou
 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=25197edit=1



[PHP-DOC] cvs: phpdoc /en/reference/info/functions ini-set.xml

2003-08-21 Thread Mehdi Achour
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 @@
 ?xml version=1.0 encoding=iso-8859-1?
-!-- $Revision: 1.29 $ --
+!-- $Revision: 1.30 $ --
 !-- splitted from ./en/functions/info.xml, last change in rev 1.23 --
   refentry id=function.ini-set
refnamediv
@@ -168,7 +168,7 @@
entryPHP_INI_SYSTEM/entry
   /row
   row
-   entryhyerwave.allow_persistent/entry
+   entryhyperwave.allow_persistent/entry
entry0/entry
entryPHP_INI_SYSTEM/entry
   /row




[PHP-DOC] #25196 [Opn-Csd]: typo on ini_set()'s doc page

2003-08-21 Thread didou
 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=25196edit=1



[PHP-DOC] #25201 [NEW]: typo in cURL parameter documentation

2003-08-21 Thread scottm at spamcop dot net
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=25201edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=25201r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=25201r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=25201r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=25201r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25201r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=25201r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25201r=support
Expected behavior:  http://bugs.php.net/fix.php?id=25201r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25201r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25201r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=25201r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25201r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=25201r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=25201r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25201r=gnused



Re: [PHP-DOC] #25191 [NEW]: Suggestion for a paragraph in the security chapter

2003-08-21 Thread Edin Kadribasic
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=25191edit=1
 --
 Try a CVS snapshot (php4):
http://bugs.php.net/fix.php?id=25191r=trysnapshot4
 Try a CVS snapshot (php5):
http://bugs.php.net/fix.php?id=25191r=trysnapshot5
 Fixed in CVS:
http://bugs.php.net/fix.php?id=25191r=fixedcvs
 Fixed in release:
http://bugs.php.net/fix.php?id=25191r=alreadyfixed
 Need backtrace:
http://bugs.php.net/fix.php?id=25191r=needtrace
 Try newer version:
http://bugs.php.net/fix.php?id=25191r=oldversion
 Not developer issue:http://bugs.php.net/fix.php?id=25191r=support
 Expected behavior:
http://bugs.php.net/fix.php?id=25191r=notwrong
 Not enough info:
http://bugs.php.net/fix.php?id=25191r=notenoughinfo
 Submitted twice:
http://bugs.php.net/fix.php?id=25191r=submittedtwice
 register_globals:   http://bugs.php.net/fix.php?id=25191r=globals
 PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25191r=php3
 Daylight Savings:   http://bugs.php.net/fix.php?id=25191r=dst
 IIS Stability:  http://bugs.php.net/fix.php?id=25191r=isapi
 Install GNU Sed:http://bugs.php.net/fix.php?id=25191r=gnused






[PHP-DOC] cvs: phpdoc /en/reference/curl/functions curl-setopt.xml

2003-08-21 Thread Jani Taskinen
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 @@
 ?xml version=1.0 encoding=iso-8859-1?
-!-- $Revision: 1.4 $ --
+!-- $Revision: 1.5 $ --
 !-- splitted from ./en/functions/curl.xml, last change in rev 1.1 --
   refentry id=function.curl-setopt
refnamediv
@@ -176,7 +176,7 @@
   /listitem
   listitem
simpara
-parameterCURL_SSL_VERIFYPEER/parameter: Pass a long that is set
+parameterCURLOPT_SSL_VERIFYPEER/parameter: 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




[PHP-DOC] #25201 [Opn-Csd]: typo in cURL parameter documentation

2003-08-21 Thread sniper
 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=25201edit=1