Running the latest Windows CVS checkout, I get an interesting problem with
the php_error_docref output.
It seems to cut off the first letter of messages, ala:
etwork.php) [a href='http://www.php.net/function.main' Blah blah blah
blah.
Might be good to fix that.
Hi,
On Tue, Aug 13, 2002 at 05:26:17PM +0200, Marcus Börger wrote:
At 17:05 13.08.2002, Dan Kalowsky wrote:
On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
2) Can we please remove the http://www.php.net/manual/en/blahblahblah;
style of use for this? It will tend to force users
At 10:03 14.08.2002, Jan Lehnardt wrote:
Hi,
On Tue, Aug 13, 2002 at 05:26:17PM +0200, Marcus Börger wrote:
At 17:05 13.08.2002, Dan Kalowsky wrote:
On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
2) Can we please remove the
http://www.php.net/manual/en/blahblahblah;
style
Hi,
On Wed, Aug 14, 2002 at 10:09:52AM +0200, Marcus Börger wrote:
Then there is only the last argument not spoken about yet:
Externally developed extensions.
and PECL extensions respectively. For external developed extensions I suggest
putting them into PECL (at least the documentation, if
At 10:15 14.08.2002, Jan Lehnardt wrote:
Hi,
On Wed, Aug 14, 2002 at 10:09:52AM +0200, Marcus Börger wrote:
Then there is only the last argument not spoken about yet:
Externally developed extensions.
and PECL extensions respectively. For external developed extensions I suggest
putting them
Hi,
On Wed, Aug 14, 2002 at 10:25:40AM +0200, Marcus Börger wrote:
Erm - good point we cannot find pecl.function.name automatically by
docref=NULL. Either pecl must be available by function.name or by
just using name on php.net. This is also a problem for external copies
of the manual.
erm,
Then there is only the last argument not spoken about yet:
Externally developed extensions.
and PECL extensions respectively. For external developed extensions I
suggest
putting them into PECL (at least the documentation, if there are license
issues about the extension's code itself) and for
At 10:57 14.08.2002, Gabor Hojtsy wrote:
Then there is only the last argument not spoken about yet:
Externally developed extensions.
and PECL extensions respectively. For external developed extensions I
suggest
putting them into PECL (at least the documentation, if there are license
| Erm - good point we cannot find pecl.function.name automatically by
| docref=NULL. Either pecl must be available by function.name or by
| just using name on php.net. This is also a problem for external
copies
| of the manual.
PECL, PEAR and other functions won't be available as
So, you're suggesting that all external extensions have to be in PECL
in order for the error message to link to further documentation??
What about projects like APC/APD? SRM?
NameOfYourFavouriteThirdPartyBinarySCEHere?
Do they all have to be hosted on php.net??
--Wez.
On 08/14/02, Jan
Hi,
On Wed, Aug 14, 2002 at 10:41:24AM +0100, Wez Furlong wrote:
So, you're suggesting that all external extensions have to be in PECL
in order for the error message to link to further documentation??
What about projects like APC/APD? SRM?
NameOfYourFavouriteThirdPartyBinarySCEHere?
Do
On Thu, 8 Aug 2002, Wez Furlong wrote:
On 08/08/02, Marcus Börger [EMAIL PROTECTED] wrote:
First thanks to Wez for another great idea.
And it's not really my idea :-)
It's some anonymous persons idea (checking the cvs log for the
todo will reveal who!).
Derick :-)
I came to the
A few comments on this.
1) is it possible to cut down on the number of php_error_docref functions
to just one? I really don't see a reason for this many different formats.
2) Can we please remove the http://www.php.net/manual/en/blahblahblah;
style of use for this? It will tend to force users
At 16:37 13.08.2002, Dan Kalowsky wrote:
A few comments on this.
1) is it possible to cut down on the number of php_error_docref functions
to just one? I really don't see a reason for this many different formats.
There is no solution for reducing php_error_docrefn() to one function
call but we
On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
2) Can we please remove the http://www.php.net/manual/en/blahblahblah;
style of use for this? It will tend to force users into one language or
another, and not make PHP as friendly/usable to other languages.
NO! First you can simply
At 17:05 13.08.2002, Dan Kalowsky wrote:
On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
2) Can we please remove the http://www.php.net/manual/en/blahblahblah;
style of use for this? It will tend to force users into one language or
another, and not make PHP as friendly/usable to
php_error_docref(function.fopen TSRMLS_CC, E_WARNING, Spongebob Square
Pants lives in a pineapple under the sea);
To me that should be the recommended method, as it will allow the php.ini
values for language to override everything nicely, and everyone can see
the PHP manual in their desired
On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
The point is to be able to direct to external sites not on php.net! For
example
when a function is just a wrapper around a library then you can use the
absolute
form of the docref parameter (http://site) to point to the library's
On Tue, 13 Aug 2002, Dan Kalowsky wrote:
On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
The point is to be able to direct to external sites not on php.net! For
example
when a function is just a wrapper around a library then you can use the
absolute
form of the docref
At 22:04 13.08.2002, Dan Kalowsky wrote:
On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
The point is to be able to direct to external sites not on php.net! For
example
when a function is just a wrapper around a library then you can use the
absolute
form of the docref parameter
At 22:22 13.08.2002, 'Ricky' S Dhatt wrote:
On Tue, 13 Aug 2002, Dan Kalowsky wrote:
On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
The point is to be able to direct to external sites not on php.net! For
example
when a function is just a wrapper around a library then you can
It's needed because a lot of the doc pages are long, and there is not
always going to be a 1:1 mapping between the active function and a
description of the error.
For example, in the stream wrappers, when someone tries to open an
http connection for write, or tries to overwrite an existing file
At 18:44 12.08.2002, you wrote:
[snip]
I guess I should start updating ODBC to be using the php_error_docref() as
well... I'll wait for your commit for samples ;)
Dan
Here is a script that converts unified php_error() calls to
php_error_docref() calls
with docref parameter set NULL
Hi Marcus,
Just 2 points:
In your update to this patch, you have a fixme for the case where
get_active_function_name(TSRMLS_C) returns NULL. AFAICT, this will
only happen in rare circumstances and doesn't have anything to do
with the build being a TSRM build or not. So it's a bit of a
On 08/08/02, Marcus Börger [EMAIL PROTECTED] wrote:
First thanks to Wez for another great idea.
And it's not really my idea :-)
It's some anonymous persons idea (checking the cvs log for the
todo will reveal who!).
Derick :-)
--Wez.
--
PHP Development Mailing List http://www.php.net/
At 22:35 08.08.2002, Wez Furlong wrote:
Hi Marcus,
Just 2 points:
In your update to this patch, you have a fixme for the case where
get_active_function_name(TSRMLS_C) returns NULL. AFAICT, this will
only happen in rare circumstances and doesn't have anything to do
with the build being a TSRM
26 matches
Mail list logo
