[PHP-DEV] add SMTP authentication to php.mail() function

[John M. Calvert]

Hello, I'm interested to add SMTP authentication to the php.mail() function.
Is this something that the PHP dev community would endorse? I'm told that as
a newbie contributor I wouldn't have direct access to the CVS, that I'd have
to post my diffs to this list or get an existing developer to sponsor my
changes. I already did the digging around and know what needs to happen: a
small number of lines of code in /win32/sendmail.c SendText() to add the
necessary SMTP AUTH commands. Maybe this has come up before and been
rejected. Let me know. I did a search in the list archives but didn't turn
anything up.

Here is some background:

I'm developing a website that will be hosted on a linux box (LAMP), however
my work machine is MS Windows 2000. The website includes a submission page
which e-mails some HTTP form posted data back to me. For simplicity I'm
simply using the php.mail() function. However, when I'm developing on
Windows 2000, if I want to test the mail submission, I don't have an SMTP
relay running locally and my ISP requires authentication for outgoing SMTP.
So for now the php.mail() fails and I fake it until the php pages are
uploaded to the server. I know I could switch to another means of sending
mail (PHP class for SMTP, etc) but I thought it would be cool to hack PHP to
add this minor feature. I would plan to add two new php.ini settings
SMTP_usr and SMTP_pwd.

Looking forward to your comments.

John M. Calvert, M.Sc., MCSD

1310521 Ontario Inc.
49 Belmont Ave.
Ottawa ON K1S 0V2
(613) 730-9851
http://members.rogers.com/john-m-calvert/

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Moderate PHP-DEV

[John Coggeshall]

We'll see who reads this, any responses are welcome.

I see a few different issues here:

1) People who want answers for a php-general message post it to the
development forum. This is clearly because they do not understand the
difference, as I doubt anyone wants to waste their own time posting a
message to a forum that refuses to answer the question. 

2) Those who know exactly what this forum is for, and for whatever
reason the core team doesn't want or otherwise consider their
contributions to the discussion. Something like Catchable parse errors,
maybe? :)

I agree with the opinion that more clearly defining what exactly this
list is for will solve issue #1, however #2 is what I think is the real
problem here (isn't it?) I don't see the point in pulling punches when
it comes to why the core developers want to moderate the list.. 

I don't claim to have the end-all answer to this problem, but I know
that many people who sign on this list probably fall into one of the
following:

A) They are simplying following along in discussions because they need
to or are curious what is in store for the future

B) They are truly interested in contributing real things, but aren't as
experienced with the internals of PHP/Zend as the core team so their
suggestions / code is insufficient to meet the stanards set by the core
team. 

C) The core team or other signficiant contributors.

This might not be a complete list, but things like this never are. In
any case, moderating this list would end up completely alientating
everyone but those who are "significant developers". How does one become
a significant developer at that point? People who are learning will
always ask questions that can be considered stupid by someone more
experienced... Unless someone who is experienced is around to answer
them and respond to this "noise", how will anyone learn?

Maybe I'm completely off-track here, but it's just a thought where I
could take a moment to make fun of my own idea. :)

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Error_log

[John Coggeshall]

Is there any reason we are still supporting PHP3 for error_log?
Specifically that TCP/IP stuff. I was looking at error_log and I was
wondering if anyone had a good objection to me submitting a patch for it
to:

define constants ERRORLOG_SYSLOG, ERRORLOG_EMAIL, ERRORLOG_FILE ..
It's really ugly having hard-coded ints

Getting rid of message_type = 2 (TCP/IP logging) since it doesn't
work anymore, make it the same as 3 (write to file) and throw a notice
if type 3 is used (but still work). 

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Doing something with an each opcode as zend_execute() handles it

[John Coggeshall]

>Such as overriding the opcode handlers for each opcode? I 
>suppose I could change what the handlers are initialized to in 
>zend_init_opcodes_handler() so that my new handler does the 
>serialization and then calls the regular handler. Does that make sense?


Yep

Int my_do_fetch_r_handler(ZEND_OPCODE_HANDLER_ARGS) {
fprintf(stderr, "we hooked fetch_r\n");
return
zend_do_fetch_r_handler(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU);

}

Is all you'd need.

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Doing something with an each opcode as zend_execute() handles it

[John Coggeshall]

Look at zend_init_opcodes_handlers() and the zend_opcode_handler array..


John


>-Original Message-
>From: George Schlossnagle [mailto:[EMAIL PROTECTED] 
>Sent: Wednesday, March 05, 2003 6:10 PM
>To: David Sklar
>Cc: Sterling Hughes; [EMAIL PROTECTED]
>Subject: Re: [PHP-DEV] Doing something with an each opcode as 
>zend_execute() handles it
>
>
>> Essentially, I want to be able to produce a sort of serialized 
>> representation of the opcodes, but as they are executed, not all in 
>> one big chunk after they are compiled.
>>
>> This isn't for any actually useful production code, just some 
>> debugging/messing around/exploring engine internals.
>>
>
>There's no good way to do this as a zend_extension in ZE1 (that I know 
>of).  You need to patch the engine (which is trivial).
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Question about zend_compile

[John Coggeshall]

I'm playing around with the compiler/executor and I was wondering if
someone could answer a question.. 

Is there any reasonable way to essentially push/pop the function table?
What I'd like to do is get a function_table hash for only a single file
(pesudo code below):

PUSH_FUNCTION_TABLE(CG(function_table))
Op_array = zend_compile_file(fh, ZEND_REQUIRE);

/* retrieve information from the function_table 
about the functions in the fh handle only*/

POP_FUNCTION_TABLE(CG(function_table))

Specifically, I'd like to get the zend_function structures for the
user-defined functions declared inside of myfile.php... Basically my
problem is I have a userspace get_func_info($filename) function which
works great when retrieving information from the function table after
zend_compile_file(), but I end up having more functions than I wanted
since every user-defined function regardless of file (including the file
I'm in) is in the hash... i.e.

Myscript.php


It seems to me that this is exactly the sort of thing I would want to
use namespaces for, is there a elequent way to create a new namespace
from within my C function temporarily between when my function is called
and returns?

Suggestions? 

John



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Modifying PHP variables in C

[John Lim]

Hi Moriyoshi
Thanks for the advice!

"Moriyoshi Koizumi" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> You should use zval_ptr_dtor() to dispose the old value. Note the old
> value won't actually be freed as long as any reference to the variable is
> alive.
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Modifying PHP variables in C

[John Lim]

Hi,

I'm porting some PHP code to C, and was hoping that someone can help me.

I have 2 variables $oldarray  and $newarray that both hold arrays and want
to set

  $oldarray = $newarray;

I suppose i have to dispose of $oldarray before i set it to $newarray. I'm
not sure what is the best way, so i did this.

zval **oldarray,*newarray;

zval_add_ref(&newarray);
convert_to_null_ex(oldarray);
*oldarray = newarray;

Would this work? Secondly is there a better way. Thanks again.

John Lim



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: new construct

[John Coggeshall]

I was asking myself -- I had assumed that __construct() would be
searched for first. I was /am under the impression __construct() is a
special function that the engine wouldn't allow you to use  in PHP5 in
any other context than its intended purpose. 

I don't know what Zeev plans on doing with this, but perhaps an option
would be to issue a notice or warning if both A::A() and __construct()
exist in a single class A and call __construct() in those cases... 

Just a thought.

John
 
>Perhaps i may be mistaken, but it seems logical to search for 
>the old-style constructor first in order to be backwards 
>compatible with old-style scripts.  Putting __construct in old 
>style classes would yield a classname of  '__construct', an 
>ugly and unlikely name for a class.  Seeing as A::A() would be 
>much nicer, i can see the logic behind parsing the old-style 
>first, rather than the new-style.
>
>That's just my two cents, feel free to correct me otherwise..
>
>~ Andrew Heebner
>
>>
>> >__construct is the new method of defining a constructor, but the 
>> >'bug' you suspect is not a bug.  The parser will search for a 
>> >function of the same name in the class as the constructor for 
>> >backwards compatibility with Older scripts, etc...
>>
>> But shouldn't __construct() be searched for and used prior to the 
>> old-style constructor? Intuitively it seems it should.
>>
>> John
>>
>
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: new construct

[John Coggeshall]

>__construct is the new method of defining a constructor, but 
>the 'bug' you suspect is not a bug.  The parser will search 
>for a function of the same name in the class as the 
>constructor for backwards compatibility with Older scripts, etc...

But shouldn't __construct() be searched for and used prior to the
old-style constructor? Intuitively it seems it should.

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Weird PHP5 APXS libtools errors

[John Coggeshall]

 
>   $ export SED=sed
>   $ ./configure ...
>
>Somehow, the variable SED is not set.

I was just looking at the MakeFile trying to figure this out and I was
thinking it must be something like that. It works now -- thanks... But
why would SED suddenly stop being defined? Did I break something
unintentially (meaning SED should always be defined?) or is PHP failing
to define it for some reason?

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Weird PHP5 APXS libtools errors

[John Coggeshall]

>Does a snapshot from snaps.php.net compile without running ./buildconf?

Yep it does, actually... 

I'll investigate further into it when I get some sleep :)

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Weird PHP5 APXS libtools errors

[John Coggeshall]

>>upgrade your libtool to 1.4.3, it is required now.

[user@localhost php5]# ./buildconf
using default Zend directory
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.4-p5 (ok)
buildconf: libtool version 1.4.3 (ok)

And just to be sure..

[user@localhost php5]# libtool --version
ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54)

Any other thoughts? If there's anything else you need to know, 
let me know.

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Weird PHP5 APXS libtools errors

[John Coggeshall]

>From HEAD:

./configure works fine (no options)... Make, everything.

But...
./configure --with-apxs=/usr/local/apache/bin/apxs

Causes some weirdness on Make...
[user@localhost]# make
/bin/sh libtool --preserve-dup-deps --mode=compile gcc
-I/home/php/php5/ext/mysql/libmysql -Iext/mysql/
-I/home/php/php5/ext/mysql/ -DPHP_ATOM_INC -I/home/php/php5/include
-I/home/php/php5/main -I/home/php/php5 -I/home/php/php5/Zend
-I/home/php/php5/ext/xml/expat  -DLINUX=22 -DUSE_HSREGEX -DUSE_EXPAT
-I/home/php/php5/TSRM  -g -O2  -prefer-pic -c
/home/php/php5/ext/mysql/php_mysql.c -o ext/mysql/php_mysql.lo
libtool: s%^.*/%%: No such file or directory
libtool: -e: command not found
libtool: -e: command not found
libtool: -e: command not found
libtool: -e: command not found
libtool: -e: command not found
(more of these)

I'm not familiar enough with the build environment as a whole, but I've
been building HEAD for quite some time now and I'm not sure why now it'd
just choke like thisAny suggestions welcome.

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: jmacklin

[John T. Macklin]

PHP Development Contributions

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Segfault with ZE2

[John Coggeshall]

I'll file a bug report on this, but I wasn't sure if it would get
noticed and figured those involved might be interested... As of the CVS
from last Monday (as well as head) ZE2 is segfaulting... Here's the bt..

#0  0x081114b4 in zend_register_functions (scope=0x0,
functions=0x4001a260,
function_table=0x0, type=1) at
/home/php/php4-ze2/Zend/zend_API.c:1099
#1  0x08111704 in zend_register_module (module=0x400237a0)
at /home/php/php4-ze2/Zend/zend_API.c:1172
#2  0x080941a5 in php_dl (file=0x8183ee8, type=1,
return_value=0xb860)
at /home/php/php4-ze2/ext/standard/dl.c:242
#3  0x080ee128 in php_load_function_extension_cb (arg=0x8183ee8)
at /home/php/php4-ze2/main/php_ini.c:247
#4  0x08108a35 in zend_llist_apply (l=0x8175c3c,
func=0x80ee114 )
at /home/php/php4-ze2/Zend/zend_llist.c:190
#5  0x080ee5aa in php_ini_delayed_modules_startup ()
at /home/php/php4-ze2/main/php_ini.c:499
#6  0x080eb0bc in php_module_startup (sf=0x8174ac0,
additional_modules=0x0,
num_additional_modules=0) at /home/php/php4-ze2/main/main.c:1284
#7  0x08132530 in main (argc=1, argv=0xbaf4)
at /home/php/php4-ze2/sapi/cli/php_cli.c:480
#8  0x400c8306 in __libc_start_main (main=0x8132420 , argc=1,
ubp_av=0xbaf4, init=0x8063128 <_init>, fini=0x8133140 <_fini>,
rtld_fini=0x4000d2dc <_dl_fini>, stack_end=0xbaec)
at ../sysdeps/generic/libc-start.c:129

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] RfC: version names

[John Coggeshall]

>That can be done, but that means 12 commits "a day" for a 
>single file. I 
>dont think that's a good idea. 

Is there some way we can harness CVS keyword subsitutuion in a case like
this?

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: str_ireplace vs. stri_replace

[John Coggeshall]

If your using an undocumented parameter, and that undocumented parameter
changes what's the problem? The documentation doesn't say a word about a
mystery undocumented parameter... I don't think we should be too
concerned with someone using something they arguably shouldn't be.

John


>-Original Message-
>From: Sara Golemon [mailto:[EMAIL PROTECTED]] 
>Sent: Thursday, January 30, 2003 5:39 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
>
>
>> > +1 from me too, stri_replace sound like a function some users may 
>> > +have
>> >
>> > implemented them selves and we could end up breaking their code by 
>> > introducing it.
>>
>> exactly :).
>>
>Only one complaint.
>
>Previously (including in 4.3.0) there already WAS a fourth 
>(undocumented) parameter to str_replace.  A boolean value 
>which would allow the user to use an alternate search and 
>replace method.  True, this was undocumented, and was probably 
>only included for developer debugging (Sascha? Can you enlighten us?).
>
>This alternate method has been removed (by virtue of being 
>deprecated) and should produce wrong param count errors for 
>users who include that fourth parameter currently (how many 
>would even know of this?) so that they can fix their code.
>
>If we introduce a *new* fourth parametere (also boolean) which 
>checks for case_sensitivity, this could potentially cause 
>problems for users who were using this undocumented parameter. 
> Leaving the fourth and adding a fifth would get even more 
>confusing if the appearance is that the fourth parameter was 
>just added *and* served no purpose.
>
>So, we could relegate those VERY few who might've used that 
>fourth parameter already to the "read the changelog or suffer" 
>bucket, ornot.
>
>-Pollita
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Java support....

[John Wells]

Guys,

Sorry to post this to the dev list, but general yielded no results.  Lot's
of noise on there and something about foo vs. bar ;-).

I'm considering using the integrated Java support within PHP to make
method calls to a java reporting tool (jasper reports) from within PHP.

Yet, the manual suggests the ability to call methods on java objects is
experimental at best.

Was wondering if anyone here is using this feature in a production
environment (or at all, for that matter), and if so how if you've had any
problems.

Alternatively, I could use the SAPI module, but I'm worried that this may
be a performance hit to my app (disclaimer: haven't tested or even tried
yet).  Is it possible to have most of your PHP app run under mod_php and
the Java-related portion run contained in a Tomcat servlet?

Finally, which option would you recommend?

I appreciate any input you're able to provide.

John




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?

[John Coggeshall]

The reason I ask is that Shane Caraveo and I were working on the thread
saftey issue, but we couldn't talk about it because we weren't invited
to the PHP5-DEV list


>-Original Message-
>From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] 
>Sent: Thursday, January 23, 2003 5:51 AM
>To: Piotr Sobolewski
>Cc: [EMAIL PROTECTED]
>Subject: Re: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?
>
>
>> I would like to know in advance when PHP 5 will be released.
>
>So would we.  We have no idea.  Sometime in the next 4-18 
>months.  How's 
>that?
>
>> Can I find a sort of "roadmap" somewhere?
>
>We are well past the roadmap and into the TODO stage now.  Our trusted 
>secretary, Sebastian, has been maintaining it:
>
>http://www.sebastian-bergmann.de/TODO-PHP5.txt
>
>> Where should I look at regularly to know if it is going
>> to be released soon?
>
>This list is fine.
>
>> Can somebody tell me approximately when it will happen? 3 months? 
>> Year?
>
>Nope, and if someone does tell you it is pure speculation and 
>you can add 
>or subtract 6 months to/from the answer you get.
>
>-Rasmus
>
>
>-- 
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?

[John Coggeshall]

I am working on some reader-friendly docs to answer this question, but
for now you can read the ZEND_CHANGES file in the PHP CVS

John


>-Original Message-
>From: Piotr Sobolewski [mailto:[EMAIL PROTECTED]] 
>Sent: Thursday, January 23, 2003 5:41 AM
>To: [EMAIL PROTECTED]
>Subject: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?
>
>
>Hi,
>
>I would like to know in advance when PHP 5 will be released.
>
>Can I find a sort of "roadmap" somewhere? 
>
>Where should I look at regularly to know if it is going
>to be released soon?
>
>Can somebody tell me approximately when it will happen? 3 months? Year?
>
>-- 
>Piotr Sobolewski
>[EMAIL PROTECTED]
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] foreach nastiness with references (bug #21702)

[John Coggeshall]

Ah, I understand now... This perhaps in a documentation problem then
after all, as there is no way to change this behavior cleanly that I can
see... What about making a copy of the array and all of the references
associated with that array instead of just using the real array?

Just a thought. 

John


>What I meant by this is
>
>1) Each time before entering a foreach loop, php first tries 
>to make a copy of
>   the array being iterated.
>
>2) In case the array variable is either referenceing another 
>variable or
>   referenced by another variable, no copy is made here and 
>the original
>   array is used instead. Because of this behaviour, the 
>original's internal
>   array pointer increases in the loop eventually.
>
>And once a variable is referenced by another, both are treated 
>as "reference" from then on. For example,
>
>  $test = array();
>  $test['a'] = 'a';
>  $test['b'] = &$test['a'];
>
>  debug_zval_dump($test);
>?>
>
>This script produces following output:
>
>array(2) refcount(2){
>  ["a"]=>
>  &string(1) "a" refcount(2)
>  ["b"]=>
>  &string(1) "a" refcount(2)
>}
>
>Moriyoshi
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] foreach nastiness with references (bug #21702)

[John Coggeshall]

To answer part of your question:

>One more thing: whether this bug is fixed or not, the 
>documentation must 
>be clarified! I don't know about you, but I simply don't 
>understand what 
>it's supposed to say. Quoting: "Note:  Also note that foreach operates 

What the documentation means is that 

$val) {
$val = "newval";
} 
?>

Will not change every element in the $foo array to "newval". However,
although $foo cannot be modified by modifying $key and $val the internal
array pointer WILL increment as if you were actually working on that
array directly.. So in order to restore the internal array pointer back
to the start of the array you'd need a call to reset($foo) first. 

Side note: You can still modify the values within $foo by:

$val) {
$foo[$key] = "newval";
}
?>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Overloading object methods

[John Coggeshall]

>I'm asking how to call parent::method() from zend engine (C), 
>not from php. 
>Are questions regarding the C zend_engine API welcome?

Ah. My appologies then -- I misunderstood your question. Yes, questions
regarding development _of_ PHP/Zend Engine are welcome here :) At first
(and second) read it sounded as if you were asking about how to code
something _using_ PHP. 

I haven't played with objects much in the API, so I don't know the
answer to your question off the top of my head. I'm sure there's someone
here who does however :) 

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Overloading object methods

[John Coggeshall]

This list is for the development _of_ PHP not _with_ PHP, please direct
future questions there

However, I don't understand the question you are asking... If you have
this:

Class A {

function foo() {

echo "I am function foo";
}
}

Class B extends A {

function foo() {
echo "I am the child function foo";
parent::foo();
}
}

$a = new B;
$a->foo();

It will output:

I am the child function foo
I am function foo

http://www.php.net/manual/en/keyword.parent.php

John


>-Original Message-
>From: Stefano Corsi [mailto:[EMAIL PROTECTED]] 
>Sent: Thursday, January 09, 2003 5:28 AM
>To: [EMAIL PROTECTED]
>Subject: [PHP-DEV] Overloading object methods
>
>
>Does someone know how to call a parent's object method? Not contructor 
>(because that is easy) but a method with the same name.
>
>For example, if I have a method that is called pippo() and at 
>the end of the 
>method i want to call parent::pippo(), how could I do?
>
>I tried with call_user_function using  
>
>&(this_object->ce->parent->function_table)
>
>as the function table, but I don't know how to pass the 
>underlyig object.
>
>Thanks,
>   Stefano
>
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Designing for PHP4 with PHP5 in mind...

[John Wells]

So code should be backwards compatible?  Very nice.

Any good links you could throw my way describing proposed changes?

Thanks guys.

John

Sterling Hughes said:
>> On Monday, January 6, 2003, at 09:48  PM, Brian Moon wrote:
>>
>> >From what I understand, all OO code will have to be modified for
>> PHP5. Constructors for example and no longer named the same as the
>> class  name.
>> >That alone means every class must be changed.  I don't recall anyone
>> saying
>> >it would be BC either, but I could be wrong.
>>
>> You're wrong.
>>
>> Of course, I could be too.
>>
> but you're not.  so its ok...
>
> :)
>
> -Sterling
>
>>
>> --
>> PHP Development Mailing List <http://www.php.net/>
>> To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Designing for PHP4 with PHP5 in mind...

[John Wells]

I'm preparing for a project in which I'll be porting and redesigning a
large, ugly Visual Basic/Sql Server app to a PHP/Mysql or Postgresql based
web application.

I'd like to code in a way that will be at the same time easily ported to
PHP5 and that will take advantage of PHP5's new object handling
efficiencies.  I've read varying reports of whether syntax will be
different.

Is there anything I should watch for, add, or specifically avoid while
coding this application to make the transition as easy as possible?

Thanks!
John








-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Generic expressions interpolation in strings

[John Coggeshall]

In order for such a feature to exist the your statement would have to be
(ignoring the ++ operator for now):

$foo = "The count is: {$count = $count + 1}";

Which means that you'd actually have to evaluate everything inside of {
} as PHP code.. Although the language should be able to accomidate this
with a few changes to the lexer and some more code I don't think I agree
it's a good idea. Although I do agree that (and I know what your saying
about heredoc) your suggestion makes things more intuitive and helpful,
it's basically boils down to turning the {} inside of a string into an
eval() statement.. And that I don't agree with:


EOF;

Which would end up executing a system call... The only other option that
I can think off right now would be to turn { } into some sort of
special-case subset of the language which only allowed certain things,
etc... And that is really much more of a headache that it's worth.

John
 

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
>Sent: Sunday, January 05, 2003 1:45 PM
>To: [EMAIL PROTECTED]
>Subject: [PHP-DEV] Generic expressions interpolation in strings
>
>
>I already opened a bug (#21433) about this Feature Request, 
>but I realized it is better to discuss here about it.
>
>
>I'm relatively new to PHP. Previously I used to program a lot 
>in Perl. What I really lack in PHP is Perl's ability to 
>interpolate any expression inside a string. For example:
>
>Perl: "Next value is @{[ $value + 1 ]}!"
>PHP:  "Next value is " . $value + 1 . "!"
>
>In this simple case it's not a great problem, but it becomes 
>more awkward when using the heredoc operator. In this cases 
>I'm often forced to use temporary variables:
>
>$tempvar = $value + 1;
>print <<< END
>Here it is the next value
>$tempvar
>Other text...
>END;
>
>
>I propose to extend the Variable Parsing syntax to evaluate 
>ANY expression instead of variables only. I propose the 
>following syntax:
>
>print <<< END
>Here it is the next value
>{$= $value + 1 }
>Other text...
>END;
>
>Using "{=" would be more readable but it would cause too many 
>backward compatibility problems...
>
>
>What do you think of this?
>
>
>Thanks.
>-- 
>___
>__
>   |-  [EMAIL PROTECTED]
>   |ederico Giannici  http://www.neomedia.it
>___
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] ZE2, Win32, and PHP5

[John Coggeshall]

Is anyone already building Win32 ZE2/PHP executables? I'm planning on
moving all of my development machines over to the ZE2 engine, but I
don't have MSVC handy for my Windows box.

On that note -- Someone before mentioned that we should start building
the source exclusively using ZE2 (for development) in preparation for
PHP5... I seem to think that perhaps is a good idea, and was wondering
if anyone else wanted to throw in their opinion on it.

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP in 2003 (leading to PHP 5)

[John Coggeshall]

I tend to agree that completely separating PHP from the modules does
cause a problem when it comes to support modules, etc. However, IMHO I
feel that as the numbers of modules written for PHP increases there
becomes a greater and greater need to separate modules from the core of
PHP.

When it comes to bug reporting/fixing, perhaps it's feasible to
completely separate bug reporting for each module from PHP itself? For
example, if each module is maintained completely separately from PHP
with it's own version # then there should also be a separate bug
reporting system for bugs found with that module. 

Also, on that note, is there any hard and fast standard in place for
modules/extensions and the minnimum PHP version those modules support?
I.e. is there anything that is designed to prevent me from trying to
load a module in PHP 4.0 when it won't work with any version of PHP less
than 4.2? I mean more than it throwing an error at compile-time of
course.

When I look at PECL, I envision a system where modules are completely
separated from the PHP core. Each module and their maintainer(s)
(whomever they are) deal with their own bugs for that module, modules
have minnimum PHP core versions for which they work with, etc. We could
make this easier by providing a source-forge type of cookie-cutter bug
tracking system for each module, and perhaps by making the modules
themselves clearly independent of PHP. I'd like to see a system for
modules where what modules PHP uses is not defined at compile-time at
all by a ./configure statement. Rather, what modules are being used are
defined in some sort of configuration file (where the configuration
parameters for those modules are also located) and the modules are
loaded dynamically. I should be able to go download the GD module and
stick it in a subdirectory of /usr/local/lib/php and then edit my
modules.conf (or something) file:


   Allow_jpeg=true
   Allow_tiff=false


These are all just thoughts I have.. Feedback is more than welcome. I
think a system such as this would accomplish a number of (in my mind)
benfitial things:

1) Faster and easier installations of PHP
By removing all of those compile-time ./configure options it will make
PHP much easier to compile and install. Problems with a single module at
compile-time won't stop a user from getting PHP running, and if there is
a problem when the module is dynamically loaded it will be easier to
figure out what's going wrong.

2) More accurate and managable module maintaing
If modules are completely separated from PHP itself, then the status of
a particular module, the people who are maintaining it, news about the
modules, etc. will be easily found. 

There are more, but it's late and I'm going to get to sleep :) Like I
said, feedback is more than welcome and I'd love to work with whomever
is interested to move PHP in this direction. 

Cheers,

John


>-Original Message-
>From: Dan Hardiker [mailto:[EMAIL PROTECTED]] 
>Sent: Thursday, January 02, 2003 3:59 AM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject: Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)
>
>
>> [...]
>> different distribution packages can be
>> built when php releases occure, such as 'php core' which 
>would contain 
>> the 'most important' stable extensions, 'php stable' which would 
>> contain  all stable extensions, and 'php bleeding' which could be a 
>> package with  the latest development snapshot at time of release.
>>
>> With this also extensions now can take on a life of their own, 
>> releasing  at different times than php, and visaverse.  I think this 
>> would make releasing new versions of php much more manageable.
>
>>From my past experiance, Ive found this sort of idea to be great - if 
>>the
>modules are retrieved else where, otherwise you end up with a 
>support nightmare.
>
>Currently in the bug tracker we only need to ask what version 
>of PHP they have and we automatically know what version all 
>the of the modules are as they come bundled. If all the 
>modules are updateable independantly of the PHP release having 
>"PHP x.x.x" installed is no longer enough release information, 
>we (via the end user) would also have to gather the version 
>number for each module - ouch.
>
>Not to mention the painful testing! [eg:] I have 4 
>installations running 4 different versions of PHP for 
>regression testing and bug fixing. If I relied on 3 different 
>modules and wanted to check 2 versions of each, I would need 4 
>* 3 * 2 (24) installations - just to test.
>
>Im not against the concept of modules, but Id encourage the 
>idea to be well thought out (especially the impact) as well as 
>encouraging them to be thought more of "plug-ins" which are 
>independant and 

RE: [PHP-DEV] CVS Account Request: hitcho

[John Coggeshall]

Perhaps we should try to get documentation for those functions which
don't have anything before we worry about trying to go through and add
more examples for those that do?

John


>-Original Message-
>From: Tularis [mailto:[EMAIL PROTECTED]] 
>Sent: Tuesday, December 31, 2002 5:20 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [PHP-DEV] CVS Account Request: hitcho
>
>
>Philip Olson wrote:
>>>>>Setup a common thread of examples across all PHP
>>>>>documentation as 80% of all questions about PHP on 
>>>>>lists could be answered with common examples across 
>>>>>all functions in the documentation.
>> 
>> 
>> On Tue, 31 Dec 2002, Georg Richter wrote:
>> 
>>>On Tuesday 31 December 2002 22:39, Philip Olson wrote:
>>>
>>>
>>>>80% of all questions about PHP on the lists could be answered if 
>>>>people read the manual in the first place. Wait, make that 95% :)
>>>>
>>>
>>>Philip, we need more examples (and also correct ones). Hitcho is 
>>>absolutely
>>>right here. Were also discussed this during the last doc 
>meeting in march 
>>>2002.
>> 
>> 
>>   Are more useful examples needed?  Yes.  Can the manual be
>>   improved?  Yes.  Will new better examples in the manual
>>   solve 80% of all problems?  No.  Do I want people like
>>   Hitcho to work on the manual?  Hell yeah!  Are my comments
>>   meant to be rude?  No.  Should people read the manual?  Yes.
>>   Do people who post to the lists currently read the manual?  
>>   Mostly No.  Should they?  Yes.  Should they also do searches
>>   with google/archives before asking?  Yes.
>> 
>> Regards,
>> Philip
>> 
>> 
>**first wants to point out it's easier to put a reply ABOVE the quoted 
>text**
>
>I have to admit I think you're right in a lot of points philip, he 
>should indeed be allowed to help with the phpdocs. Though, the results 
>of him adding more examples would result IMHO in the following 
>2 things:
>
>1 - Inexperienced ppl would be overwhelemed by the amount of examples, 
>and compex ways to 'use' something. Thus making their scripts more 
>complex than they need to be, and finally resulting back here in the 
>lists asking for help.
>2 - Most (more) experienced ppl would benefit a bit from the 
>examples by 
>seeing how you 'could do it', but then again, more ppl would start 
>coding 'the same way', by that I mean to say that there are 
>more ways to 
>code something There *ALWAYS* are more ways.
>
>These things might seem a bit far off, but they are true IMHO. 
>Nevertheless, I would appreciate more documentation examples, and it 
>sure is something I will be adding in the next few days off I have ;)
>
>- Tularis
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Yet another happy new year :)

[John Coggeshall]

With 4.3.0 out the door, I just wanted to take a moment and join the
chourus and say Happy new year as well. Peace and happiness to all, and
I'll be sure to throw one back for the success of PHP as well ;)

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Update: Quoting behaviour exposed

[John Coggeshall]

Nah. Can we please put down the swords and start talking about PHP5?  

>-Original Message-
>From: Sascha Schumann [mailto:[EMAIL PROTECTED]] 
>Sent: Sunday, December 29, 2002 12:47 PM
>To: Zeev Suraski
>Cc: Sebastian Bergmann; [EMAIL PROTECTED]
>Subject: Re: [PHP-DEV] Update: Quoting behaviour exposed
>
>
>> As much as it is amusing, tihiye besheket vetafsik lehishtamesh 
>> beLatinit.
>
>If that language had interested me, I would have made my
>Hebraicum in addition to the Latinum.
>
>[snip off-topic]
>
>If it has not been clear to you or anyone else -- this has
>all been about drawing attention to the issues of proper
>quoting.  If only one person starts to embrace some of the
>available guidelines, it has been well worth it.
>
>- Sascha
>
>-- 
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Sessions, session_register()

[John Coggeshall]

>The problem stems from the fact that some users have been
>(ab)using session_register when register_globals is off.
>session_register is only supposed to be used for the
>register_globals=on case.

Those functions need to be updated in the manual then to reflect this
change. If I say  PHP >= 4.3.0 only allows session_register(),
session_is_registered(), and session_unregister() if register_globals is
enabled will that suffice?

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Sessions, session_register()

[John Coggeshall]

>php_error(E_WARNING, "Your script possibly relies on a 
>session side-effect which existed until PHP 4.2.3. Please be 
>advised that the session extension does not consider global 
>variables as a source of data, unless register_globals is 
>enabled. You can disable this functionality and this warning 
>by setting session.bug_compat_42 or session.bug_compat_warn.");

I saw this when I was digging through the source -- but that doesn't
really answer my question... Which is the side effect of which? Are
users supposed to use $_SESSION, or the functions? Or should both be
able to be used interchangeably?

John


>Andrey
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Sessions, session_register()

[John Coggeshall]

>Where did you find that recommendation?

http://www.php.net/manual/en/function.session-register.php

Read the note :) I thought it was kind of strange myself... If this is
changed in 4.3 I will update the docs to reflect this, but I wanted to
see what everyone had to say about it first.

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Sessions, session_register()

[John Coggeshall]

Can someone enlighten me as to why session_register() and $_SESSION
shouldn't be used togeather? It seems to me the session_register()
function(s) should just be working with $_SESSION anyway... Are they
doing something different? Is this desired behavior if it is doing
something different?

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php-cgi vs php-cli naming issue

[John Coggeshall]

>I see that renaming the CGI to php-cgi might break things indeed, and 
>that's never a good idea. But so is changing the name of the CLI (php) 
>to something else. It also breaks things, not only for me, but 
>also for 
>countless others using the CLI with the name 'php'. We also need to 
>think about these users as well. This leaves my opinion that i'm -1 on 
>renaming the CLI to something else, and i'm a -0 (yes this 
>changed :) on 
>renaming the CGI. This leaves the (IMO) only possible solution: 
>integrate them back into one binary and adding some magic 
>which triggers 
>CLI or CGI mode (perhaps to check for some environment variable).

I'm a bit nervous about the checking of an environment variable thing.
Is that platform/server independent?

John


>Derick
>-- 
>
>---
>--
> Derick Rethans 
>http://derickrethans.nl/ 
> PHP Magazine - PHP Magazine for 
>Professionals   http://php-mag.net/
>---
>--
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] downgrade undefined function from fatal error

[John Coggeshall]

There is absolutely no reason why you cannot simply include your
functions in your scripts. If you are really lazy, you can even
auto_prepend an include file.

John


>-Original Message-
>From: Dave [Hawk-Systems] [mailto:[EMAIL PROTECTED]] 
>Sent: Friday, December 13, 2002 8:56 AM
>To: [EMAIL PROTECTED]
>Subject: [PHP-DEV] downgrade undefined function from fatal error
>
>
>reviewed and did a couple of searches on this prior to signing 
>up to this particular list...
>
>Is this a reasonable consideration for changes to PHP's 
>handling of undefined functions?
>
>Currently, calling a previously undefined function generates 
>an E_ERROR, and halts the script as a cirtical failure meaning 
>we can't handle the error as we do others (this is clearly documented).
>
>What I am not clear on is why an undefined function should 
>necessarily be a fatal error with no change to code the script 
>to handle the error.  For example
>
>function eh($type, $msg, $file, $line, $context){
>   # code to parse $msg for 
>/undefined\040function:\040(.*)\(\)/,$match
>   # check specified directory for the function:
>   # include the file if exists (./functions/$match[1].php)
>   # try to resume
>   # if we can't find it, halt with die()
>}
>
>error_reporting(0);
>set_error_handler("eh");
>
>undefined_function();
>?>
>
>This would seem much more intuitive, and allow collection of 
>massive amounts of sharable and accessible functions to be 
>contained in shared directories, and not have to worry about 
>identifying them all at the head of all pages, or including 
>functionsthat would not be required.
>
>Currently as a workaround we are using the following logic;
>
>function func($f_name){
>   if(!function_exists($f_name)){
>   # function doesn't exists, needs to be included
>   require('/path/to/functions/'.$f_name.'.php');
>   }else{
>   # function already exists, no action required
>   }
>   return $f_name;
>}
>
>$database=call_user_func(func('DatabaseConnect'),'var1','var2');
>?>
>
>But this results in code that isn't quite as intuitive.
>
>Thoughts? Comments? "You are nuts"?
>
>Dave
>
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[John Coggeshall]

Esp. when some of us would love to see PHP5 start taking form :)

John


>-Original Message-
>From: Leon Atkinson [mailto:[EMAIL PROTECTED]] 
>Sent: Tuesday, December 10, 2002 2:55 PM
>To: Edin Kadribasic
>Cc: [EMAIL PROTECTED]
>Subject: Re: [PHP-DEV] php.exe - php-cgi.exe
>
>
>> P.S. I wish people were following this list more closely so that we 
>> don't
>> have to discuss same issues over and over again.
>
>But it's fun to argue over the same things every six months! :P
>
>Leon
>
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[John Coggeshall]

>Please mention the name change at least in the NEWS file and 
>maybe php-cli could even output a readable error when beeing 
>called as cgi.

As I already said, we should put this in the message created at the end
of ./configure, in the release notes, in the news file, on the website,
and perhaps send a mass e-mail to everyone whom has ever worked with PHP
;)

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[John Coggeshall]

>
>Maybe phpsh would be a good idea for the name of the CLI? It wouldn't 
>confuse ppl as much as php-cli
>

Why when I look at "phpsh" I think "Sushi"...

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[John Coggeshall]

As much as I understand the point of view that renaming the CGI version
of PHP from php(.exe) to php-cgi(.exe) so that we don't have to type
'php-cli' perhaps isn't such a good idea, I am completely against
changing it now. Changing it the first time is obviously causing
problems, changing it again will really muddle the waters... (Okay, if
you downloaded PHP between the months of XXX and , it's this...
Otherwise, it's that... Unless...)

Regards,

John


>-Original Message-
>From: Melvyn Sopacua [mailto:[EMAIL PROTECTED]] 
>Sent: Sunday, December 08, 2002 6:28 PM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]; 'Christoph Grottolo'; [EMAIL PROTECTED]
>Subject: RE: [PHP-DEV] php.exe - php-cgi.exe
>
>
>On Sun, 8 Dec 2002, Marcus Börger wrote:
>
>MBr>>> Just because you only need to type the name of the CGI 
>sapi once: 
>MBr>>> In other word one single time until we decide the name changes. 
>MBr>>> But you will use a command line interface hopefully 
>very often. I 
>MBr>>> for one do and i am not going to type php-cli.exe because it is 
>MBr>>> way much to long.
>
>Sorry Marcus, but - even though I think these names are better 
>- the same could be said for a cli: ln -s php-cli php or even: 
>alias php /usr/local/bin/php-cli
>
>For windows - you could move php-cli.exe to 
>C:\WINNT\system32\php.exe and it's preferred in the path (or 
>set %PATH%).
>
>But - changing the name for the CGI, breaks server environments...
>
>I think on windows, the two executables, should be named the 
>php.exe and the cgi stored in the standard php4 dir and the 
>cli version in bin/. This way you have the best of both worlds 
>- it won't break CGI - and a simple PATH adjustment takes care 
>of the cli problem.
>
>For unices, we could provide a --with-cgi-name configure 
>option and default to php, with --disable-cli.
>
>Just my 2c
>-- 
>With kind regards,
>
>Melvyn Sopacua
>
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[John Coggeshall]

I believe the issue here is that PHP won't display the proper HTTP
headers in the CLI version:

C:\> Php.exe test.php

X-Powered-By: PHP/4.2.2
Content-type: text/html

Testing 1 2 3
C:\>
C:\> Php-cli.exe test.php
Testing 1 2 3
C:\>

>-Original Message-
>From: Philip Olson [mailto:[EMAIL PROTECTED]] 
>Sent: Sunday, December 08, 2002 11:07 AM
>To: Alexander Wagner
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
>'Christoph Grottolo'; [EMAIL PROTECTED]
>Subject: Re: [PHP-DEV] php.exe - php-cgi.exe
>
>
>
>Can someone provide a history of this and the problems
>one will see when trying to run php.exe as a cgi (i.e.
>follows one of the many install texts out there).
>
>This is _sorta_ documented but not really, only the
>apache2 docs make any mention of it thus far.
>
>Regards,
>Philip
>
>
>On Sun, 8 Dec 2002, Alexander Wagner wrote:
>
>> On Sunday 08 December 2002 01:02, John Coggeshall wrote:
>> > I think a big ole' message at the end of ./configure will 
>> > drastically reduce the number of problems.
>> 
>> With php.exe? *g*
>> 
>> > Also, perhaps a check could be put in the
>> > CLI version of PHP that would throw an error message if it 
>is being 
>> > used as a CGI...
>> 
>> A _meaningful_ error-message in the right place would be the right 
>> thing (tm).
>> Too many people don't read release-notes.
>> 
>> regards
>> Wagner
>> 
>> --
>> codito ergo sum
>> 
>> --
>> PHP Development Mailing List <http://www.php.net/>
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[John Coggeshall]

>Yes that could happen...maybe we should have another *big* 
>message for the configure part and a *huge* message in the 
>release notes and news entries.

This is no different than when register_globals suddenly got turned off.
I think a big ole' message at the end of ./configure will drastically
reduce the number of problems. Also, perhaps a check could be put in the
CLI version of PHP that would throw an error message if it is being used
as a CGI...

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] FR: echo line

[John Coggeshall]

-1, no way...

>-Original Message-
>From: Jari Vuoksenranta [mailto:[EMAIL PROTECTED]] 
>Sent: Saturday, December 07, 2002 11:57 AM
>To: [EMAIL PROTECTED]
>Subject: [PHP-DEV] FR: echo line
>
>
>I have a feature request: I'd like to have '#' comment like 
>macro which would expand "_ foo" to "?> foo\n
>Has this been requested before?  If so, why it wasn't implented?
>
>e.g.
>"
>   for(..) {
>   _   
>   }
>?>
>"
>would echo "\t\n" to page.
>
>-- 
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: Cookie Session Problem

[John Coggeshall]

>   You can turn it off by setting "session.use_trans_sid" parameter
>   to off (btw, it is off by default).

You really should use the session.use_only_cookies directive.

John


>Bye,
>Ivan
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] New SNMP function names

[John Coggeshall]

For what it's worth, I am in agreement with Derick... Consistency is
important..

Besides... A rose is still a rose, even if it's called
sweet_smelling_flower ;)



>OK, I will admit the '_' is then OK, but I rather do not use 
>it in this case, since I would like to use that for a more 
>session oriented 
>functions.

I'm 

>As an example:
>$sess_v1 = snmp_session(1, "localhost:161", "public");
>$sess_v3 = snmp_session(3, "otherhost:161", "username", "seclevel",
>"auth_protocol", "auth_passphrase",
>"priv_protocol", "priv_passphrase");
>
>$vara = snmp_get($sess_v1, "sysUpTime.0");
>$varb = snmp_get($sess_v3, "sysUpTime.0");
>
>
>> Abbreviations should not be used when they greatly decrease the
>> readability of the function name itself.
>>
>> Good:
>> 'mcrypt_enc_self_test'
>> 'mysql_list_fields'
>>
>> ...
>>
>> [2] If they are part of a "parent set" of functions, that 
>parent should
>> be included in the user function name, and should be 
>clearly related
>> to the parent program or function family. This should be 
>in the form
>> of parent_*.
>>
>> A family of 'foo' functions, for example:
>> Good:
>> 'foo_select_bar'
>> 'foo_insert_baz'
>> 'foo_delete_baz'
>>
>> ...
>>
>> [5] Variable names should be in lowercase.  Use underscores 
>to separate
>> between words.
>>
>>
>> more of all, it's common practise with all extensions. If you find 
>> some which do not adhere to this standard, then there was taken into 
>> account a BC problem.
>
>For that alias could have been made to assist people in a 
>migration phase.
>
>>  This is not the case with new functions, like you added,
>> and thus they should stick to the guide lines.
>>
>
>I do not see any problem with the usage of 'v3'.
>
>>>
  As those
 are new functions I propose to change them to the following, to be
 more
 consistent with all other functions:

 snmpv3get  -> snmp3_get
 snmpv3walk -> snmp3_walk
 snmpv3realwalk -> snmp3_real_walk (or snmp3_walk_oid)
 snmpv3set  -> snmp3_get
>>>
>>> I have mentioned this some time ago already on the list. (See 
>>> archive) I believe it is way easier for people to recognise the 
>>> SNMPv3 version by people with the current naming. On top of that I 
>>> can understand all of your concerns, but it is my opinion 
>we have to 
>>> think what is the easiest for the users/programmers of PHP.
>>
>> the proposed names are much more readable, and they follow the oci8_ 
>> convention of only using the verison number, the 'v' in your names 
>> don't add anything useful.
>
>I think it will create confusion when I am done with the new 
>more session oriented approach. That I believe is neither 
>something needed if can be avoided.
>
>>
>>> IMHO, the current naming refers quite clearly to SNMP version 3 or 
>>> SNMPv3. Many people know this version of the protocol as SNMPv3. I 
>>> beleive that the original functions did neither have an '_' 
>>> character. Why is that required suddenly??
>>
>> Backward compatibility for those. Maybe you noticed that we 
>added some 
>> aliases to other extensions because of this, but the snmp extension 
>> was left alone in that. AFAIK, changing or aliasing names is on the 
>> PHP 5 todo.
>
>So, are you saying you should have renamed them all and 
>keeping an alias for the BC??
>
>>
>>> (This states more or less the same opinion as expressed last time)
>>>
>>> I also would like to mention that I am looking into the usage of an 
>>> SNMP-session creation and then use a single variable to provide all 
>>> SNMP-session info in a single variable for the 'data retrieval' 
>>> functions. Therefore, I would like to reserve the use of the 
>>> underscore and then without a version number.
>>
>> As long as you don't break BC it's fine with me.
>
>That is why I would like to keep it as is and how I propose 
>it. It would be less confusing for PHP-coders. But I know this 
>is a personal opinion.
>
>>
>>>
 also, there is no need to introduce an alias for a newly created 
 function so I guess we just should drop it.
>>>
>>> I have created a similar set of functions as exist for SNMPv1. That 
>>> includes the alias. That makes it easier for existing scripts to be 
>>> updated with the new security featres of SNMPv3.
>>
>> We only add aliases if it is absolutely necesary, which is 
>really not 
>> the case here.
>>
 I'd like to make those proposed changes ASAP as they are 
>also added 
 in the PHP_4_3 branch which gets closer to release everyday.
>>>
>>> Personally, I do not prefer and like the name change suggested.
>>>
>>> The name snmp3_ looks to me quite weird, since the world knows this 
>>> as SNMPv3. Therefore, the use of snmpv3 is preferred.
>>
>> yeah, and oci is really called oraclecinterface, so let's fix that 
>> too!
>
>You also could have named it with the 'o' prefix.
>Do I have to laugh here??
>
>>
>>> I am even ten

RE: [PHP-DEV] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false

[John Coggeshall]

>The return false part is ok but why not showing the warnings 
>from fopen?

Well, the issue here is in the bugreport... It's not an issue of PHP
throwing a warning when a file doesn't exist and is attempted to be
opened, but it was throwing the error if the filesize was zero.. I could
see that being annoying. I've got no problem leaving the warning in
I just feel that the function should consistently return false on error.

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false

[John Coggeshall]

Here's the patch (again, this makes all getimagesize() failures return
false instead of some of them returning NULL, and turns off error
reporting if the file fails to open.

John


--- image.org.c Thu Dec  5 06:06:48 2002
+++ image.c Wed Dec  4 22:54:16 2002
@@ -908,7 +908,7 @@
zval_dtor(*info);

if (array_init(*info) == FAILURE) {
-   return;
+   RETURN_FALSE;
}

convert_to_string_ex(arg1);
@@ -919,7 +919,7 @@
break;
}

-   stream = php_stream_open_wrapper(Z_STRVAL_PP(arg1), "rb",
REPORT_ERRORS|IGNORE_PATH|ENFORCE_SAFE_MODE, NULL);
+   stream = php_stream_open_wrapper(Z_STRVAL_PP(arg1), "rb",
IGNORE_PATH|ENFORCE_SAFE_MODE, NULL);

if (!stream) {
RETURN_FALSE;
@@ -976,7 +976,8 @@
if (array_init(return_value) == FAILURE) {
php_error_docref(NULL TSRMLS_CC, E_ERROR,
"Unable to initialize array");
efree(result);
-   return;
+RETURN_FALSE;
+
}
add_index_long(return_value, 0, result->width);
add_index_long(return_value, 1, result->height);

>-Original Message-
>From: Derick Rethans [mailto:[EMAIL PROTECTED]] 
>Sent: Thursday, December 05, 2002 1:39 AM
>To: John Coggeshall
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
>[EMAIL PROTECTED]
>Subject: RE: [PHP-DOC] #20822 [Com]: getimagesize() returning 
>null instead of false
>
>
>On Wed, 4 Dec 2002, John Coggeshall wrote:
>
>> 
>> I've changed the getimagesize() function so that it RETURN_FALSE on 
>> every error, and disables the error reporting if the file fails to 
>> open (it still returns RETURN_FALSE)
>> 
>> If no one has a problem, I'll commit.
>
>Where is the patch?
>
>Derick
>
>> >-Original Message-
>> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>> >Sent: Wednesday, December 04, 2002 9:54 PM
>> >To: [EMAIL PROTECTED]
>> >Subject: [PHP-DOC] #20822 [Com]: getimagesize() returning null 
>> >instead of false
>> >
>> >
>> > ID:   20822
>> > Comment by:   [EMAIL PROTECTED]
>> > Reported By:  [EMAIL PROTECTED]
>> > Status:   Open
>> > Bug Type: Documentation problem
>> > Operating System: linux
>> > PHP Version:  4.2.3
>> > New Comment:
>> >
>> >maybe its also worth mentioning that getimagesize() spews out
>> >an error if the filesize() of the file is 0 bytes :/ - this 
>> >isnt so nice :/
>> >
>> >
>> >Previous Comments:
>> >---
>> >-
>> >
>> >[2002-12-04 20:47:55] [EMAIL PROTECTED]
>> >
>> >cutting out from the php manual:
>> >
>> >If accessing the filename image is impossible, or if it isn't
>> >a valid picture, getimagesize() will return FALSE and generate 
>> >a warning.
>> >
>> >... when getimagesize() in fact returns NULL (atleast in 4.2.3
>> >(debian unstable tree))
>> >
>> >---
>> >-
>> >
>> >
>> >--
>> >Edit this bug report at http://bugs.php.net/?id=20822&edit=1
>> >
>> >
>> >--
>> >PHP Documentation Mailing List (http://www.php.net/)
>> >To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>> 
>> 
>> --
>> PHP Documentation Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>
>-- 
>
>---
>--
> Derick Rethans 
>http://derickrethans.nl/ 
> PHP Magazine - PHP Magazine for 
>Professionals   http://php-mag.net/
>---
>--
>
>
>-- 
>PHP Documentation Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false

[John Coggeshall]

I've changed the getimagesize() function so that it RETURN_FALSE on
every error, and disables the error reporting if the file fails to open
(it still returns RETURN_FALSE)

If no one has a problem, I'll commit.

John


>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
>Sent: Wednesday, December 04, 2002 9:54 PM
>To: [EMAIL PROTECTED]
>Subject: [PHP-DOC] #20822 [Com]: getimagesize() returning null 
>instead of false
>
>
> ID:   20822
> Comment by:   [EMAIL PROTECTED]
> Reported By:  [EMAIL PROTECTED]
> Status:   Open
> Bug Type: Documentation problem
> Operating System: linux
> PHP Version:  4.2.3
> New Comment:
>
>maybe its also worth mentioning that getimagesize() spews out 
>an error if the filesize() of the file is 0 bytes :/ - this 
>isnt so nice :/
>
>
>Previous Comments:
>---
>-
>
>[2002-12-04 20:47:55] [EMAIL PROTECTED]
>
>cutting out from the php manual:
>
>If accessing the filename image is impossible, or if it isn't 
>a valid picture, getimagesize() will return FALSE and generate 
>a warning.
>
>... when getimagesize() in fact returns NULL (atleast in 4.2.3 
>(debian unstable tree))
>
>---
>-
>
>
>-- 
>Edit this bug report at http://bugs.php.net/?id=20822&edit=1
>
>
>-- 
>PHP Documentation Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] New SNMP function names

[John Coggeshall]

+1


>-Original Message-
>From: Ilia A. [mailto:[EMAIL PROTECTED]] 
>Sent: Wednesday, December 04, 2002 3:23 PM
>To: Derick Rethans; PHP Developers Mailing List
>Subject: Re: [PHP-DEV] New SNMP function names
>
>
>Consistency is always good and adding aliases for newly added 
>functions seems 
>like a recipe for bloat & confusion. 
>+1 on the proposed changes.
>
>Ilia
>
>On December 4, 2002 08:49 am, Derick Rethans wrote:
>> Hello,
>>
>> while browsing the CVS I found that the following functions 
>were added 
>> to the CVS recently:
>>
>> +   PHP_FE(snmpv3get, NULL)
>> +   PHP_FE(snmpv3walk, NULL)
>> +   PHP_FE(snmpv3realwalk, NULL)
>> +   PHP_FALIAS(snmpv3walkoid, snmpv3realwalk, NULL)
>> +   PHP_FE(snmpv3set, NULL)
>>C
>> But those functionnames don't adhere to our nameing guidelines. As 
>>those  are new functions I propose to change them to the 
>following, to 
>>be more  consistent with all other functions:
>>
>> snmpv3get  -> snmp3_get
>> snmpv3walk -> snmp3_walk
>> snmpv3realwalk -> snmp3_real_walk (or snmp3_walk_oid)
>> snmpv3set  -> snmp3_get
>>
>> also, there is no need to introduce an alias for a newly created 
>> function so I guess we just should drop it.
>>
>> I'd like to make those proposed changes ASAP as they are 
>also added in 
>> the PHP_4_3 branch which gets closer to release everyday.
>>
>> regards,
>> Derick
>
>
>
>-- 
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] pecl extensions

[John Coggeshall]

> Yeah I know that shady guy Shane.

Heh. He is shady, isn't he? ;)

> Well, it's defintly experimental. There are bindings for 
>opengl and glut. You can run some sample apps that use the 
>glut api. Its pretty cool. Me and Marcus were working on off 
>screen redndering with OSMesa. That would allow you to render 
>a scene without needing to display it somewhere, caputre the 
>content and spit it out as an image. That worked pretty 
>decent, it worked on windows but i had issues with it running 
>under linux. It could reneder a sceen and spit out a png. I 
>remember Andrei told me that there were issues using the api 
>with gtk-opengl but im sure they could be addressed.

My thoughts on it were exactly where you are going with it. However, why
do you need OSMesa in order to do off-screen renderings? It would seem
to me you should be able to render directly to a backbuffer and copy the
bitmap into a GD buffer... Or am I missing something?

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] pecl extensions

[John Coggeshall]

Brad:

I'm going to take a real stab in the dark here and say that you know
Shane Caraveo. I was at PHPCon with him presenting in October and I was
talking about an idea I had to implement opengl in PHP... He said that
someone by the name of Brad (at least, that's what I recall) was working
on a extension and I should get in touch with him... Well, needless to
say I forgot until just now...

What is the status of this extension? Is it experimental, stable, etc?
Just curious...

John


>-Original Message-
>From: Brad LaFountain [mailto:[EMAIL PROTECTED]] 
>Sent: Monday, December 02, 2002 8:05 PM
>To: [EMAIL PROTECTED]
>Subject: [PHP-DEV] pecl extensions
>
>
>I know I'm going to piss people off by asking this but how do 
>I create a new pecl package? I think I want going to put 
>php_opengl in there. See if gets anymore use.
>
> - Brad
>
>__
>Do you Yahoo!?
>Yahoo! Mail Plus - Powerful. Affordable. Sign up now. 
http://mailplus.yahoo.com

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Hashtables

[John Coggeshall]

Hey all

I was playing around and I'm running into a problem with a hashtable...
Basically, it's segfaulting my code :) Specifically, I'm trying to
return the number of items in the hash...

if(zend_hash_num_elements(hash) == 0)

Which causes the following:

Program received signal SIGSEGV, Segmentation fault.
zend_hash_num_elements (ht=0x0) at /home/php/php4/Zend/zend_hash.c:988
988 return ht->nNumOfElements;

Anyone know the steps I need to do in order for something like this to
work? If it hasn't been initialized, how do I tell other than checking
the elements?

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] RE: Bug #2965

[John Coggeshall]

>I'm conflicted on this one.  On the one hand you've got PHP 
>somewhat at fault for treating letters as special characters 
>(such that 'Z'+1 == 'AA') rather than as their ordinal 
>equivalents (such that 'Z'+1 == ord('Z')+1 == 91 == ord('[') 
>== '[' ) which IMO is an ugly thing.

I personally like the C-consistency here, at least on this issue.

>On the other hand, while it's inconsistent with C, it's 
>perfectly in line with Perl and it's a performance trend which 
>is presumably being relied upon by some.  I can certainly see 
>where such behavior (heretofore unexpected by me) would come 
>in handy in fact.

Where possibly would this behavior of 'Z'+1 = 'AA' be useful?

>Against my better judgement, I'm voting to leave the 
>interpreter as is and make notes in the documentation to 
>clarify behavior.

Given the choice, I'm personally for having single-characters treated as
ordinals when appropiate.

John


>-Pollita
>
>
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] RE: Bug #2965

[John Coggeshall]

That's not the issue... In C, the behavior is to actually print the
alphabet A-Z... It looks like our implementation is messed up, but the
bug report is a bit misleading as to if I should fix the documentation
to say you CAN'T do this, or fix the code so you can :)

John


>-Original Message-
>From: Dan Rossi [mailto:[EMAIL PROTECTED]] 
>Sent: Thursday, November 28, 2002 7:06 PM
>To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: [PHP-DEV] RE: Bug #2965
>
>
>i'd try use chr($i) or something like that and start @ A value
>
>-Original Message-
>From: John Coggeshall [mailto:[EMAIL PROTECTED]]
>Sent: Friday, November 29, 2002 11:00 AM
>To: 'electroteque'; [EMAIL PROTECTED]
>Subject: Bug #2965
>
>
>
>This bug was changed to a documentation problem, and I'm a bit 
>confused as to what exactly the issue is
>
>For($i = 'A'; $i <= 'Z' $i++)  echo $i;
>
>I'm assuming this *should* echo the A-Z alphabet (which it 
>doesn't).. But, since it was changed to a documentation 
>problem -- is the current form intended behavior?
>
>John
>
>
>>-Original Message-
>>From: electroteque [mailto:[EMAIL PROTECTED]]
>>Sent: Thursday, November 28, 2002 6:07 PM
>>To: [EMAIL PROTECTED]
>>Subject: [PHP-DEV] Zend Engine 2
>>
>>
>>Hello i was wondering when this is becoming available with the
>>possibilities of private and public class features ?
>>
>>
>>
>>--
>>PHP Development Mailing List <http://www.php.net/>
>>To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Bug #2965

[John Coggeshall]

This bug was changed to a documentation problem, and I'm a bit confused
as to what exactly the issue is

For($i = 'A'; $i <= 'Z' $i++)  echo $i;

I'm assuming this *should* echo the A-Z alphabet (which it doesn't)..
But, since it was changed to a documentation problem -- is the current
form intended behavior?

John


>-Original Message-
>From: electroteque [mailto:[EMAIL PROTECTED]] 
>Sent: Thursday, November 28, 2002 6:07 PM
>To: [EMAIL PROTECTED]
>Subject: [PHP-DEV] Zend Engine 2
>
>
>Hello i was wondering when this is becoming available with the 
>possibilities of private and public class features ?
>
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Bug #2965

[John Coggeshall]

This bug was changed to a documentation problem, and I'm a bit confused
as to what exactly the issue is

For($i = 'A'; $i <= 'Z' $i++)  echo $i;

I'm assuming this *should* echo the A-Z alphabet (which it doesn't)..
But, since it was changed to a documentation problem -- is the current
form intended behavior?

John


>-Original Message-
>From: electroteque [mailto:[EMAIL PROTECTED]] 
>Sent: Thursday, November 28, 2002 6:07 PM
>To: [EMAIL PROTECTED]
>Subject: [PHP-DEV] Zend Engine 2
>
>
>Hello i was wondering when this is becoming available with the 
>possibilities of private and public class features ?
>
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] C++ extensions and ext_skel

[John Coggeshall]

Well, Personally I don't have any problem with introducing C++ into PHP
so no argument there from me. I'm curious if using C++ as opposed to C
would cause a performace hit? 

John


>-Original Message-
>From: J Smith [mailto:[EMAIL PROTECTED]] 
>Sent: Thursday, November 28, 2002 5:43 PM
>To: [EMAIL PROTECTED]
>Subject: RE: [PHP-DEV] C++ extensions and ext_skel
>
>
>
>The door has always been open, as it has always been possible. 
>For instance, 
>the qtdom extension has some C++ components, as does the 
>dotnet extension. 
>This just sort of facilitates the, uh, moving through said door. 
>
>If you're using ANSI/ISO-compliant (or mostly compliant) C and C++ 
>compilers, like the gcc suite or MSVC++, there shouldn't be 
>any problems. 
>(Famous last words, I know.) 
>
>I get at least two emails a week about this sort of thing, so 
>clearly there 
>is interest. It seems that everyone who emails me is looking 
>to do it on 
>either a personal basis or for some proprietary extension, so 
>it's not like 
>PHP itself would suddenly become "polluted" with C++.
>
>J
>
>
>
>John Coggeshall wrote:
>
>> 
>> AFAIK, PHP is designed to function on any standard ANSI-compatible C 
>> compiler (as a goal). Unless this has changed, I don't know 
>if opening 
>> the door for C++ development is the best of ideas (IMHO)
>> 
>> John
>> 
>> 
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] C++ extensions and ext_skel

[John Coggeshall]

AFAIK, PHP is designed to function on any standard ANSI-compatible C
compiler (as a goal). Unless this has changed, I don't know if opening
the door for C++ development is the best of ideas (IMHO)

John


>-Original Message-
>From: J Smith [mailto:[EMAIL PROTECTED]] 
>Sent: Thursday, November 28, 2002 5:25 PM
>To: [EMAIL PROTECTED]
>Subject: [PHP-DEV] C++ extensions and ext_skel
>
>
>
>A couple of times a month, I get questions about from people 
>looking to use 
>C++ with PHP. Apparently, a lot of people end up reading some post I 
>C++ made
>to php.dev or something a year or so ago about C++, and 
>although it worked 
>at the time, the procedure I describe has become stale.
>
>I messed around a bit with ext_skel and ext/skeleton today and 
>added an 
>option to ext_skel (--cpp) that creates a basic C++ extension 
>rather than 
>the standard C extension. The C++ extension is pretty much the 
>same as the 
>standard C extension, with the exception of some extern "C" linkage, 
>modifications to config.m4 and Makefile.in and a small C++ 
>class thrown in 
>for fun.
>
>Would this be worth adding to PHP proper? I have patches available for 
>4.2.3, but if it's worthy, I can whip it up for 4.3 or 
>whatever. It'll save 
>me some email bandwidth if it could be used.
>
>J
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP Memory Error

[John Coggeshall]

>67108860 bytes = 64 mb

64M will also work, I believe.

John



>
>
>"Jonathan Williams" <[EMAIL PROTECTED]> wrote in message 
>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> Could someone 
>please help.  Running Linux 7.3 RH with 512 MB Ram with 
>> Apache and PHP 4.  I receive the following error and was 
>wondering if 
>> anyone had any suggestions.  The error: Fatal error: Allowed memory 
>> size of 8388608 bytes exhausted (tried to allocate 35 bytes) in 
>> /var/www/html/vc/test_fort/bootstrap.php on line 267.  Is there a 
>> server setting eliminating the ability to allocate more memory.  Any 
>> suggestions would be helpful.  You can reply to [EMAIL PROTECTED] 
>> as well.
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> PHP Development Mailing List <http://www.php.net/>
>> To unsubscribe, visit: http://www.php.net/unsub.php
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Redirect patch URL

[John Coggeshall]

>Regarding this proposal, what happens if the url being 
>redirected to has an error?  Or if it's down for some
>reason, how can I still see my errors without bugging 
>the sysadmin?  Also, will CLI and CGI be affected too?

This is still an issue (infinite loops regarding errors
On the error page)... I am trying to figure out a clean
Way of flagging that errors occuring on the error page
Should not be redirected but rather dumped as normal errors.

Input is most welcome for that issue... One thought that is to
Limit redirections to the same server and then compare PHP_SELF
To the relevant portion of the redirect URL:

Error_redirect_url = http://www.somewhere.com/error.php

Basically Before redirecting, make sure "/error.php" != $PHP_SELF

Other thoughts are most welcome on that. 

As for CGI, the behavior for the redirection will work just
As with the module version of PHP. As for CLI, the assumption
Here is that error_redirect would be set to OFF (hence, standard
Error reporting would apply). That can be confirmed by adding
An additional check to disable error-redirects if it is a CLI
PHP within the code...

Cheers,
John




>Regards,
>Philip
>
>On Tue, 26 Nov 2002, John Coggeshall wrote:
>
>> 
>> http://coogle.homeip.net:81/php/patches/error_redirect.txt
>> 
>> John
>> 
>> >-Original Message-
>> >From: Derick Rethans [mailto:[EMAIL PROTECTED]]
>> >Sent: Tuesday, November 26, 2002 4:22 PM
>> >To: John Coggeshall
>> >Cc: 'PHP Developers Mailing List'
>> >Subject: Re: [PHP-DEV] Redirect patch URL
>> >
>> >
>> >On Tue, 26 Nov 2002, John Coggeshall wrote:
>> >
>> >> 
>> >> http://coogle.homeip.net:81/php/patches/error_redirect.html
>> >> 
>> >> Please check out this URL and let me know what you guys think of 
>> >> the
>> >> second version of this patch. It basically is pretty 
>solid at this 
>> >> point.
>> >
>> >Your diff is in the wrong order, the whitespace is totally
>> >screwed, and 
>> >putting it in HTML makes it not readable at all. Can you 
>> >please put up a 
>> >patch in a plain text file and with the correct +/- things?
>> >
>> >Derick
>> >
>> >--
>> >
>> >---
>> >--
>> > Derick Rethans 
>> >http://derickrethans.nl/
>> > PHP Magazine - PHP Magazine for 
>> >Professionals   http://php-mag.net/
>> >---
>> >--
>> >
>> >
>> >
>> 
>> 
>> --
>> PHP Development Mailing List <http://www.php.net/>
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Redirect patch URL

[John Coggeshall]

http://coogle.homeip.net:81/php/patches/error_redirect.txt

John

>-Original Message-
>From: Derick Rethans [mailto:[EMAIL PROTECTED]] 
>Sent: Tuesday, November 26, 2002 4:22 PM
>To: John Coggeshall
>Cc: 'PHP Developers Mailing List'
>Subject: Re: [PHP-DEV] Redirect patch URL
>
>
>On Tue, 26 Nov 2002, John Coggeshall wrote:
>
>> 
>> http://coogle.homeip.net:81/php/patches/error_redirect.html
>> 
>> Please check out this URL and let me know what you guys think of the 
>> second version of this patch. It basically is pretty solid at this 
>> point.
>
>Your diff is in the wrong order, the whitespace is totally 
>screwed, and 
>putting it in HTML makes it not readable at all. Can you 
>please put up a 
>patch in a plain text file and with the correct +/- things?
>
>Derick
>
>-- 
>
>---
>--
> Derick Rethans 
>http://derickrethans.nl/ 
> PHP Magazine - PHP Magazine for 
>Professionals   http://php-mag.net/
>---
>--
>
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Redirect patch URL

[John Coggeshall]

http://coogle.homeip.net:81/php/patches/error_redirect.html

Please check out this URL and let me know what you guys think of the
second version of this patch. It basically is pretty solid at this
point.

John


>-Original Message-
>From: Maxim Maletsky [mailto:[EMAIL PROTECTED]] 
>Sent: Tuesday, November 26, 2002 4:00 PM
>To: John Coggeshall
>Cc: 'Sterling Hughes'; 'Ivan Ristic'; 'James Aylett'; 'PHP 
>Developers Mailing List'
>Subject: Re: [PHP-DEV] Redirect on Error (not localisation)
>
>
>
>
>"John Coggeshall" <[EMAIL PROTECTED]> wrote... :
>
>> 
>> My bad then :) I was under the impression that we had moved passed 
>> this and no one had a real issue with it.
>> 
>> I'll hold off on it then.
>
>
>Only because I18N thingie has smoothen it off doesn't mean we 
>should get
>error redirects already in :)
>
>But, seriousely speaking, since there is no agreement on 
>anything yet, let's
>wait.
>
>--
>Maxim Maletsky
>[EMAIL PROTECTED]
>
>
>
>
>
>> 
>> John
>> 
>> >-Original Message-
>> >From: Sterling Hughes [mailto:[EMAIL PROTECTED]] 
>> >Sent: Tuesday, November 26, 2002 3:18 PM
>> >To: John Coggeshall
>> >Cc: 'Ivan Ristic'; 'James Aylett'; 'PHP Developers Mailing List'
>> >Subject: Re: [PHP-DEV] Redirect on Error (not localisation)
>> >
>> >
>> >> 
>> >> Unless told otherwise, I'm already planning on making a 
>few changes 
>> >> and committing.
>> >>
>> >
>> >john,
>> >
>> >I've told you otherwise, so has derick and about half the 
>> >developers on this list (not talking about the localization 
>> >portion of the thread here).
>> >
>> >Quick answer: don't.  If you wanna come with some patches, 
>> >post them on your website, i and other people will be happy to 
>> >look @ them and discuss them, 
>> >but *do not* commit them without a reasonable concensus.
>> >
>> >-Sterling
>> >
>> >> John
>> >> 
>> >> 
>> >> >-Original Message-
>> >> >From: Ivan Ristic [mailto:[EMAIL PROTECTED]]
>> >> >Sent: Tuesday, November 26, 2002 2:50 PM
>> >> >To: [EMAIL PROTECTED]
>> >> >Cc: 'James Aylett'; 'PHP Developers Mailing List'
>> >> >Subject: [PHP-DEV] Redirect on Error (not localisation)
>> >> >
>> >> >
>> >> >
>> >> > > Anyway... So what of my actual patch we were 
>discussing at some 
>> >> > > point? I never got a real answer as to if it would be 
>> >suitable to 
>> >> > > commit.
>> >> >
>> >> >I have changed the subject of the message in an effort to
>> >> >separate the discussion on the "Redirect on Fatal 
>Error" feature
>> >> >(the subject of this email) from the localisation discussion.
>> >> >
>> >> >...
>> >> >
>> >> >As a reminder, we are discussing a patch that will redirect
>> >> >the user to another page when a fatal or a parse error occurs
>> >> >(parse errors can be caught with lint, fatal can't). The
>> >> >redirection will allow developers to:
>> >> >
>> >> >* Show a decent page to the user (instead of letting them
>> >> >  see a blank or incomplete page)
>> >> >
>> >> >* Send a message to themselves that something
>> >> >  strange has happened (allowing them to react 
>quickly, instead
>> >> >  of having to install log watch software for notification
>> >> >  purposes (and many people cannot do that as they do not
>> >> >  have control over the servers))
>> >> >
>> >> >As far as I am aware, there is not a single reason not to
>> >> >have this feature. Some people seem not to like it, but that
>> >> >is fine; with no performance or stability risks, if you don't
>> >> >want to use the feature - you won't be affected.
>> >> >
>> >> >On the other hand, I will be extremely happy to have it under
>> >> >my belt as yet another tool I can use to make my software
>> >> >run better.
>> >> >
>> >> >Please don't tell me that I wouldn't need this feature if
>> >> >I programmed perfectly. Errors happen all the time, no matter
>> >> >what you do trying to prevent them.
>> >> >
>> >> >
>> >> >Bye,
>> >> >Ivan
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >--
>> >> >PHP Development Mailing List <http://www.php.net/>
>> >> >To unsubscribe, visit: http://www.php.net/unsub.php
>> >> >
>> >> >
>> >> 
>> >> 
>> >> --
>> >> PHP Development Mailing List <http://www.php.net/>
>> >> To unsubscribe, visit: http://www.php.net/unsub.php
>> >> 
>> >
>> 
>> 
>> -- 
>> PHP Development Mailing List <http://www.php.net/>
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Redirect on Error (not localisation)

[John Coggeshall]

My bad then :) I was under the impression that we had moved passed this
and no one had a real issue with it.

I'll hold off on it then. 

John

>-Original Message-
>From: Sterling Hughes [mailto:[EMAIL PROTECTED]] 
>Sent: Tuesday, November 26, 2002 3:18 PM
>To: John Coggeshall
>Cc: 'Ivan Ristic'; 'James Aylett'; 'PHP Developers Mailing List'
>Subject: Re: [PHP-DEV] Redirect on Error (not localisation)
>
>
>> 
>> Unless told otherwise, I'm already planning on making a few changes 
>> and committing.
>>
>
>john,
>
>I've told you otherwise, so has derick and about half the 
>developers on this list (not talking about the localization 
>portion of the thread here).
>
>Quick answer: don't.  If you wanna come with some patches, 
>post them on your website, i and other people will be happy to 
>look @ them and discuss them, 
>but *do not* commit them without a reasonable concensus.
>
>-Sterling
>
>> John
>> 
>> 
>> >-Original Message-
>> >From: Ivan Ristic [mailto:[EMAIL PROTECTED]]
>> >Sent: Tuesday, November 26, 2002 2:50 PM
>> >To: [EMAIL PROTECTED]
>> >Cc: 'James Aylett'; 'PHP Developers Mailing List'
>> >Subject: [PHP-DEV] Redirect on Error (not localisation)
>> >
>> >
>> >
>> > > Anyway... So what of my actual patch we were discussing at some 
>> > > point? I never got a real answer as to if it would be 
>suitable to 
>> > > commit.
>> >
>> >I have changed the subject of the message in an effort to
>> >separate the discussion on the "Redirect on Fatal Error" feature
>> >(the subject of this email) from the localisation discussion.
>> >
>> >...
>> >
>> >As a reminder, we are discussing a patch that will redirect
>> >the user to another page when a fatal or a parse error occurs
>> >(parse errors can be caught with lint, fatal can't). The
>> >redirection will allow developers to:
>> >
>> >* Show a decent page to the user (instead of letting them
>> >  see a blank or incomplete page)
>> >
>> >* Send a message to themselves that something
>> >  strange has happened (allowing them to react quickly, instead
>> >  of having to install log watch software for notification
>> >  purposes (and many people cannot do that as they do not
>> >  have control over the servers))
>> >
>> >As far as I am aware, there is not a single reason not to
>> >have this feature. Some people seem not to like it, but that
>> >is fine; with no performance or stability risks, if you don't
>> >want to use the feature - you won't be affected.
>> >
>> >On the other hand, I will be extremely happy to have it under
>> >my belt as yet another tool I can use to make my software
>> >run better.
>> >
>> >Please don't tell me that I wouldn't need this feature if
>> >I programmed perfectly. Errors happen all the time, no matter
>> >what you do trying to prevent them.
>> >
>> >
>> >Bye,
>> >Ivan
>> >
>> >
>> >
>> >
>> >--
>> >PHP Development Mailing List <http://www.php.net/>
>> >To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>> 
>> 
>> --
>> PHP Development Mailing List <http://www.php.net/>
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Redirect on Error (not localisation)

[John Coggeshall]

Unless told otherwise, I'm already planning on making a few changes and
committing.

John


>-Original Message-
>From: Ivan Ristic [mailto:[EMAIL PROTECTED]] 
>Sent: Tuesday, November 26, 2002 2:50 PM
>To: [EMAIL PROTECTED]
>Cc: 'James Aylett'; 'PHP Developers Mailing List'
>Subject: [PHP-DEV] Redirect on Error (not localisation)
>
>
>
> > Anyway... So what of my actual patch we were discussing at
> > some point? I never got a real answer as to if it would be
> > suitable to commit.
>
>I have changed the subject of the message in an effort to
>separate the discussion on the "Redirect on Fatal Error" feature
>(the subject of this email) from the localisation discussion.
>
>...
>
>As a reminder, we are discussing a patch that will redirect
>the user to another page when a fatal or a parse error occurs
>(parse errors can be caught with lint, fatal can't). The
>redirection will allow developers to:
>
>* Show a decent page to the user (instead of letting them
>  see a blank or incomplete page)
>
>* Send a message to themselves that something
>  strange has happened (allowing them to react quickly, instead
>  of having to install log watch software for notification
>  purposes (and many people cannot do that as they do not
>  have control over the servers))
>
>As far as I am aware, there is not a single reason not to
>have this feature. Some people seem not to like it, but that
>is fine; with no performance or stability risks, if you don't
>want to use the feature - you won't be affected.
>
>On the other hand, I will be extremely happy to have it under
>my belt as yet another tool I can use to make my software
>run better.
>
>Please don't tell me that I wouldn't need this feature if
>I programmed perfectly. Errors happen all the time, no matter
>what you do trying to prevent them.
>
>
>Bye,
>Ivan
>
>
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PATCH] Redirect on Error

[John Coggeshall]

Alrighty :)

I'm not going to force-feed localization down anyone's throat myself,
and since there are some who seem almost pissed at the idea... Well :)
Looks like there's just not a need for it.

Anyway... So what of my actual patch we were discussing at some point? I
never got a real answer as to if it would be suitable to commit.

John


>-Original Message-
>From: James Aylett [mailto:[EMAIL PROTECTED]] 
>Sent: Friday, November 22, 2002 6:36 AM
>To: 'PHP Developers Mailing List'
>Subject: RE: [PHP-DEV] [PATCH] Redirect on Error
>
>
>> From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED]]On
>>
>>What is so hard to understand in word 'FATAL'?
>>If your script doesn't work, what use is it to make it
>>show the cryptic 500 error??
>>
>>I'm -10 for adding anything like this, even if and
>>even more then if it's optional.
>
>Returning a 500 is one of the easiest ways to automatically 
>audit of fatal problems in your script, because it is 
>(usually) pretty trivial to grab such status codes out of the 
>access log. This is incredibly useful in build and test 
>environments (we have automated processes trawling the logs on 
>our dev, stage and production servers looking for problems). 
>Indeed, you could go a step further with an ISAPI or Apache 
>custom error handler (and presumably NSAPI, which I don't have 
>experience of) to have immediate notification (useful if 
>you've got a bunch of non-technical people testing out an interface).
>
>>From a user point of view, you can return an entity (say, an 
>HTML page) 
>>with
>a 500 error. Yes, this requires output buffering, but since 
>this is all being mooted as an optional variant on error 
>handling, that really shouldn't be counted against it. From 
>the point of view of a non-human agent accessing such a page, 
>you really /should/ return 500 so it's obvious that the 
>request wasn't serviced properly. Returning an unparseable 
>mess of pseudo-HTML really isn't useful in that many circumstances.
>
>I'm not qualified to comment on how feasible this sort of 
>thing is for PHP, especially on all the SAPIs it supports, but 
>as a user of PHP it is an option I'd be interested in.
>
>Cheers,
>James
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.370 / Virus Database: 205 - Release Date: 05/06/2002
>
>
>___
>_
>This e-mail has been scanned for all viruses by Star Internet. 
>The service is powered by MessageLabs. For more information on 
>a proactive anti-virus service working around the clock, 
>around the globe, visit: http://www.star.net.uk 
>___
>_
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Error Codes, Langs, etc

[John Coggeshall]

Maxim (and anyone else who is interested)

Shall we try to get a patch for this working then? I'm thinking perhaps
starting off with an XML file defining the error messages, which is
converted to a cdb for actual use. 

Anyone else game?

John


>-Original Message-
>From: Sascha Schumann [mailto:[EMAIL PROTECTED]] 
>Sent: Monday, November 25, 2002 11:29 PM
>To: Shane Caraveo
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Maxim Maletsky'; 
>'PHP Developers Mailing List'
>Subject: Re: [PHP-DEV] Error Codes, Langs, etc
>
>
>> cats or gettext comes to mind.
>
>Neither are usable, though, because PHP would need to support
>multiple concurrent message catalogues on a per-thread base.
>gettext/catgets associate exactly one language with each
>process through the use of environment variables, so that
>they cannot be used in a multi-threaded server.
>
>A mechanism based on the bundled cdb, for example, would be
>superior in terms of speed, thread-safeness, and portability.
>
>- Sascha
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PATCH] Redirect on Error

[John Coggeshall]

>Nearly any singular operation is fast, the question is what 
>happens when it is 
>done often. For a database stored on disk we are talking at 
>least 2-3 drive 
>seeks + reading of meta information at the start of the 
>database. While it 
>may be negligible for a single process it does add up. Given 
>that this done 
>rarely (hopefuly) it would not result in major performance 
>loss, however 
>there will be a performance loss non the less.

I really think you are over-weighing any potential performace loss. 

>I dislike the idea because I believe this idea is going to 
>make PHP more 
>confusing and ultimately harder to use, which is the exact 
>opposite of what 
>this change attempts to accomplish. Fortunately this being an 
>open-source 
>project it is also possible to make your own version free of bloat :)

-1 to making PHP more confusing :)

John


>Ilia
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Error Codes, Langs, etc

[John Coggeshall]

>I had wanted to avoid this whole thread, but decided to read this one 
>message, and ouch.  While I'm all for internationalization in general, 
>I'm realy not all for using xml wherever possible just because it can 
>be.  There are existing techniques and libraries designed for 
>this, find 
>one and use it.

Well, I'm not really concerned with the method be it XML, whatever...
It's the concept that holds the real value IMHO.

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PATCH] Redirect on Error

[John Coggeshall]

>Because errors need to be loaded into memory by some 
>mechanism, stored in a 
>hash table? Meaning that during startup I will be penalized 
>for this process. 
>Hash table has it own overhead as well meaning that PHP memory 
>usage will 
>increase, for a server running 200-300 apache children 
>constantly even a 
>small increase will count.
>This will also make PHP shell scripting impractical due to the 
>high start 
>costs of a PHP binary.

I agree with George on this, loading everything at startup isn't
necessary. Errors can be loaded by some mechanism on-the-fly.

John


>Ilia
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Error Codes, Langs, etc

[John Coggeshall]

>I am definitely -1 for this idea. XML is a buzzword, it is 
>good in some cases 
>not so good in others, definitely not a one size fits all 
>solution. In PHP's 
>case it would add decency on an XML parser, make life of 
>developers adding, 
>modifying, removing error messages difficult and just like the 
>documentation 
>will seriously lag behind the primary (English) localization.

As I mentioned via Shane's comments... XML isn't really the crux of the
matter here, I'm more interested in the concept than implementation. I'm
interested in hearing what libraries and techniques Shane has in mind. 

>just adding more to the pile will drive some users away. RAD (Rapid 
>Application Development) gets you only so far eventually for 
>large scale 
>applications speed becomes essential and if Perl, Python, C 
>can offer it then 
>those languages will be picked over PHP.

I understand your issue, and If the system can't be implemented without
a huge performance hit then we're in agreement. Perhaps the issue here
is that I think the performance hit that could be taken can be limited
almost completely to the occurance of an error, rather than during
normal operations. 

>What will happen to localized error message when the charset 
>of the page they 
>are displayed on does not support the charset required for 
>proper rendering 
>of the text? Most likely gibberish.

Well, obviously if you are writing a French web site it only makes sense
that your error messages would be in French. Why the heck would you
write a french site with German error messages? 

>If you have a constant for every error would that not mean you 
>will need to 
>register hundreds if not thousands of constants at run time at 
>an enormous 
>CPU & memory cost?

Absolutely not. The error constant / values themselves could be
#defined, requiring absoultely no CPU/memory cost to speak of. Regarding
the back-reference, although it could be implemented in memory as a
lookup table this could be stored in a file which is only referenced in
the event of an error.

>> This would be simple to implement, and no more of a hassle 
>to maintain 
>> that what already exists however still provides enough 
>information to 
>> the development/QA teams (we know the type, the module, and 
>the actual 
>> error which occurred) yet still allows the developers who aren't 
>> english-speaking to still have some clue as to what the heck 
>happened 
>> with their script.
>>
>
>How do you figure that it would be just as easy to maintain? 
>Right now adding 
>an error is just a matter of writing the English text inside 
>the C file I am 
>working on. By having messages localized they'll need to be 
>stored else where 
>XML, gettext database and so on... meaning that there is 
>already more for the 
>developer to do.

Well, it'd be easier to maintain because you wouldn't have to know a
darn thing about C, or have to dig through thousands of lines of code in
order to find this php_error() line that contains the error message.
Placing the error information is a hair more difficult for the
developer, who has to actually open up a separate file or two to add
their constants But that's hardly a serious issue IMHO.

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Error Codes, Langs, etc

[John Coggeshall]

Wow..

Alrighty... I've read through all of this stuff -- everyone seems to
have quite a strong opinion on this one :) Since I kinda brought it up
with Maxim, let me provide a concept of implementation and defend it...
I'd of course love to hear what you guys have to say...

I am completely +1 to the concept of taking error codes out of the PHP
core and replacing them with an XML document, period. I say this
regardless of language considerations -- I just think for everyone
involved having a XML document which controls the errors that are
generated is just a good idea.  As I layed out before, I'd like to
replace the current error system with a error-code based system (see my
earlier thread for information on what I was thinking on this)... Now,
on to the question of localization... 

The biggest complaint that people seem to have regarding localization is
that the QA team and such would suddenly find themselves trying to
dechipher french in order to track down a bug... It's funny, you guys
don't want errors in a forigen language because they are too difficult
to understand yet you don't mind forcing the developers who don't speak
english to do the same? This is exactly my point. I feel that, with a
proper implementation, PHP can be globalized WITHOUT making lives
difficult for the development team. 

What I propose is based off of my first proposal of Error codes based on
Maxim's suggestions. Basically, I'd like to see errors broken down into
three separate code constants: TYPE, MODULE, AND ERROR... Where TYPE
would be E_ERROR, etc, MODULE would be the extension causing the error
(M_PHP_CORE, etc) and ERROR would be the actual error that occurred
(i.e. E_PHP_CORE_PARSE). Notice that I am using "descriptive" names for
the error constants. This is because I suggest that although each
individual error message is localized to german, french, etc, every
error message displays this "descriptive" errorcode... Ie..

Error (module: E_ERROR, M_PHP_CORE): A parse error occurred at line 34
of file foobar.php (E_PHP_CORE_PARSE)

Störung (Modul: E_ERROR, M_PHP_CORE): Eine Satzgliederung Störung trat
an Linie 34 der Akte foobar.php auf (E_PHP_CORE_PARSE)
 
Erreur (modules: E_ERROR, M_PHP_CORE): A erreur parse occurred AT ligne
34 of fichier foobar.php (E_PHP_CORE_PARSE) 

This would be simple to implement, and no more of a hassle to maintain
that what already exists however still provides enough information to
the development/QA teams (we know the type, the module, and the actual
error which occurred) yet still allows the developers who aren't
english-speaking to still have some clue as to what the heck happened
with their script. 

Finally, if I may make a suggestion... I really don't think there is a
lot of weight in the argument that "I'd be fired if blah blah" in these
discussions... I'm glad that you never have to work with forigeners who
don't speak english (or really bad english), or that your code is always
parse-error free... It doesn't mean that things like this have some sort
of negative impact on the language and, although I get the feeling that
many of my fellow developers on this list could really give to licks if
PHP is a language that is enterprise-ready I wish they would acknlowedge
that a lot of these things are exactly why PHP is still a hard sell to
corporations. 

John

>-Original Message-
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED]] On Behalf Of Maxim Maletsky
>Sent: Monday, November 25, 2002 9:22 PM
>To: [EMAIL PROTECTED]
>Cc: 'PHP Developers Mailing List'
>Subject: Re: [PHP-DEV] [PATCH] Redirect on Error
>
>
>
>On Mon, 25 Nov 2002 21:11:37 -0500 "Ilia A." <[EMAIL PROTECTED]> wrote:
>
>> On November 25, 2002 08:53 pm, Maxim Maletsky wrote:
>> > Well, in this case you would just add locales like you do with 
>> > dates, for example.
>> >
>> 
>> Meaning that you will be applying the locale logic in real 
>time? Have 
>> you
>> considered what kind of performance degradation this will entail?
>
>Of course it will. But, this is an option, so one can localize 
>them if wishes. Like in cases when you want English while your 
>co-workers use another language and you cannot change the main 
>php settings
>
>> > > > And you, without speaking Italian, will be just as helpful to 
>> > > > him.
>> > >
>> > > Wrong, I've read the first 5 words, the lexical parser 
>in my head 
>> > > failed to interpret the message and accordingly I've moved on. 
>> > > Maybe someone will be more patient, but that is unlikely. 
>> > > Eventually someone may indeed look and address the report, but 
>> > > that may take weeks and possibly months for a prob

RE: [PHP-DEV] [PATCH] Redirect on Error

[John Coggeshall]

>Multi-lingual error codes open's up pandora's box, let's not go 
>there.

I have to disagree with you here Sterling. Worrying about support for
non-english errors in php-general, etc is a bad, bad excuse not to
implement them. The benefits of a completely constant-based error system
(with human-friendly errors just because we like them) is worth
consideration and I really feel is a positive addition to PHP. The only
pandora's box your worried about (at least from the sound of your
e-mail) was your inbox size ;) Or am I missing something?

>In conclusion to both (imho):: 
>English is fine.  Uncatcheable parse errors is also fine. 



Result: false

;)

John




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PATCH] Redirect on Error

[John Coggeshall]

>[1] The annoying thing is that FATAL errors can't be handled 
>by an error 
>handler

With the patch they can be handled without any issues. 

> I don't like the 500 way either, because you simply loose 
>the entire 
>environment
> the bug occured in.

You'll lose the entire environment in any FATAL error, period. If the
parser dies, you just have to start from scratch in terms of the env...
At least with the patch you can tell WHERE the error came from, etc.

John


>
>Met vriendelijke groeten / With kind regards,
>
>Webmaster IDG.nl
>Melvyn Sopacua
>
><@Logan> I spent a minute looking at my own code by accident. 
><@Logan> I was thinking "What the hell is this guy doing?"
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error reporting for PHP5

[John Coggeshall]

I've been cut off from my e-mail since Thursday, so I'm going to have to
play catch-up a little here... 

Issue #1: Maxim's Error handling suggestions

I completely agree with the concept of language-specific errors. I'll be
happy to implement a system on that. However before we do that I think
what should be changed and why needs to be explored a little more... 

I am pretty much in favor for most of what Maxim is suggesting on this,
however one thing that I wasn't sure is being suggested is splitting the
constants into two three groups -- type, module, error. Where E_NOTICE,
E_ERROR, etc. would be the type of error, MOD_CURL, MOD_FOOBAR would be
the module in which the error occurred and E_CURL_BADURL would be the
actual error code.

As for custom error codes, I'm not sure how these would be handled in
PHP... In fact, I'm not entirely convince that we really should have
this sort of thing (i.e. trigger_error()). In my experience (and maybe
I'm unique) I have never actually used trigger_error() in any sort of
meaniful way. Rather, I simply deal with the error myself. I am open to
hearing everyone's ideas on what could be done in this respect.. The
best thought I would have is similar to Maxim's, where you could
register your own module constant (see above) and error codes... Then
PHP could just look them up in the XML document. Perhaps if this system
was available (along with my patch) I'd be using them much more
frequently. 

As for actual implementation, there would need to be a couple new
directives:

error_dir   The directory containing the XMLs
default_error_lang  The language default for errors (perhaps we
could use an already existing language directive?)

And a few functions added/mod'd:

Trigger_error($mod, $error) -- trigger an error  with code $error in mod
$mod (the type of error, E_ERROR, etc, is taken from the XML)
Register_error($type, $mod, $error, $msg [, $lang]) -- register an error
at runtime of type $type for module $mod, errorcode $error with the
message $msg. An option parameter $lang specifies the language the error
is in
Include_errordef($file) -- Include an error defination XML file at
run-time
Set_error_language($lang) -- Set a new error-language (perhaps this
would be better to just be set_language() for all of PHP?)

Of course callback custom error handlers would have to be changed to
accept only $mod, and $error

Notice I left Maxim's suggestion of modify_error() out... The reason is
because there should be no reason to modify the error message at
runtime... If you want to specifically define an error  to distinguish
between an undefined username and an undefined variable

Register_error(E_ERROR, USER_MYSCRIPT, E_MYSCRIPT_UNDEF);
If(!isset($username)) 
trigger_error(USER_MYSCRIPT, E_MYSCRIPT_UNDEF);


Issue #2: The 500 error...

I'm -1 on this. The reason I'm -1 is because no one has shown me a
reason why the 500 error is a more reasonable solution than the Patch
I've already written which accomplishes the same thing. In fact, it does
a better job because the error page knows exactly what went wrong
(unlike a 500 error, which just means something went wrong). 

Issue #3: The redirect patch

Although there are a few things to do for the patch before I commit
(make it more friendly when other error handlers are used,  use the
argument_seperator from the INI, etc) it is basically ready and working.
If no one has any serious objections I'll clean up the code and commit
it when I've tested it. Also, this works out fairly well because the
patch can be easily modified to work with the "new" system Maxim
discussed. 

My 2c -- sorry for being long winded (had to catch up).

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PATCH] Redirect on Error

[John Coggeshall]

>First of all i like the way you did it.
>But why do you cut the errors by using snprintf with maximum 
>length set to ERRORURL_BUF_LEN. Instead you can simply use 
>spprintf and we would get the whole message. I guess you did 
>it because you created a GET solution?

Well, I guess it could be implemented with spprintf -- However
For the use I really didn't see the need to use it. The only
Real "variables" in the string length are the filename/path and
The error-message.. These are of pretty finite length so I figured
A few kilobytes statically wouldn't hurt anyone and makes it
That much more efficient.


>marcus
>
>At 12:56 21.11.2002, John Coggeshall wrote:
>
>>Okay...
>>
>>Well, even though I've yet to convince Derick and a few 
>others... I did 
>>see enough interest in this to create a patch. This creates two new
>>directives: error_redirect (bool) which turns this on/off, and 
>>error_redirect_url (string) which is the URL to redirect to 
>upon error. 
>>In order for these directives to have any effect, the headers (of
>>course) must not have been already sent. This means that 
>either output 
>>buffering must be enabled, or the script never got around to 
>outputting 
>>anything. This patch will allow users to handle every error PHP 
>>generates if desired (including E_PARSE, etc).
>>
>>The URL which is redirected to is passed the following 
>parameters via a 
>>GET statement:
>>
>>errno - The error number (i.e. E_PARSE, whatever)
>>Errfile - The path/file of the effected file
>>Errline - The line which the error occurred
>>Errmsg - The message provided describing the error:
>>
>>If the redirection fails (i.e. because headers had already been sent,
>>whatever) the standard PHP error routine is used.
>>
>>Disclaimer: This is totally meant to be RFC at this point. It works, 
>>but Its not very friendly right now with the other error stuff (i.e. 
>>error_prepend, etc). If I can get a +1 on this concept, I'll clean 
>>things up before I commit.
>>
>>John
>>
>>--- php4/main/main.org.cThu Nov 21 05:43:05 2002
>>+++ php4/main/main.cThu Nov 21 05:43:18 2002
>>@@ -236,6 +236,8 @@
>> STD_PHP_INI_ENTRY("docref_root", "http://www.php.net/";,
>>PHP_INI_ALL,   OnUpdateString,  docref_root,
>>php_core_globals,   core_globals)
>> STD_PHP_INI_ENTRY("docref_ext", "",
>>PHP_INI_ALL, OnUpdateString, docref_ext,
>>php_core_globals,core_globals)
>> STD_PHP_INI_BOOLEAN("html_errors",  "1",
>>PHP_INI_ALL, OnUpdateBool,   html_errors,
>>php_core_globals,core_globals)
>>+   STD_PHP_INI_BOOLEAN("error_redirect",   "0",
>>PHP_INI_SYSTEM, OnUpdateBool,   
>error_redirect,
>>php_core_globals,   core_globals)
>>
>>+STD_PHP_INI_ENTRY("error_redirect_url", NULL,
>>PHP_INI_SYSTEM, OnUpdateString,
>>error_redirect_url, php_core_globals,core_globals)
>> STD_PHP_INI_BOOLEAN("xmlrpc_errors","0",
>>PHP_INI_SYSTEM, OnUpdateBool,   xmlrpc_errors,
>>php_core_globals,core_globals)
>> STD_PHP_INI_ENTRY("xmlrpc_error_number","0",
>>PHP_INI_ALL,OnUpdateInt,
>>xmlrpc_error_number,php_core_globals,   core_globals)
>> STD_PHP_INI_ENTRY("max_input_time", "-1",
>>PHP_INI_SYSTEM|PHP_INI_PERDIR,  OnUpdateInt,
>>max_input_time,php_core_globals,core_globals)
>>@@ -605,7 +607,40 @@
>> if (prepend_string) {
>> PUTS(prepend_string);
>> }
>>-   php_printf(error_format, 
>error_type_str, buffer,
>>error_filename, error_lineno);
>>+   if(PG(error_redirect) && !SG(headers_sent)) {
>>+
>>+sapi_header_line ctr = {0};
>>+char *url_params;
>>+
>>+int out_url_len, t_header_len;
>>+
>>+url_params = do_alloca(ERRORURL_BUF_LEN);
>>+
>>+snprintf(url_params,
>>+ERRORURL_BUF_LEN-1,
>>+
>>"?er

RE: [PHP-DEV] error handling

[John Coggeshall]

>Moving fatal errors to HTTP 500 can be somewhat confusing, 
>unless we have a solid way handling ALL errors in some very 
>logical way. In other words - powerful but clear enough to 
>understand and use for neo programmers.

Check out my patch and tell me what you think. Since this can be turned
on/off (default will be off) we'll maintain the current "pretty" (sorta)
errors and it is completely platform-independant

>+1 to what someone mentioned earlier - PHP is not *only* for web, it is
>*primarily* for web. Maybe, using HTTP headers for error 
>handling would make this less obvious.

Again, check my patch out and let me know what you think.

John


>just my +.2c
>
>--
>Maxim Maletsky
>[EMAIL PROTECTED]
>
>
>
>"James Cox" <[EMAIL PROTECTED]> wrote... :
>
>> it can; 500 means server error -- perl, cgi, mod_include, etc all do 
>> it, so why shouldn't php?
>> 
>>  -- james
>> 
>> > -Original Message-
>> > From: John Coggeshall [mailto:[EMAIL PROTECTED]]
>> > Sent: Wednesday, November 20, 2002 11:06 PM
>> > To: 'James Cox'
>> > Cc: 'PHP Developers Mailing List'
>> > Subject: RE: [PHP-DEV] error handling
>> >
>> >
>> >
>> > >true...
>> > >
>> > >i'd like to see a 500 error though, and some persistent vars...
>> >
>> > See, the problem that I'm seeing here is that I don't 
>believe PHP is 
>> > reponsible for setting the error code returned by PHP.. For 
>> > instance, a 404 error isn't handle by PHP at all. 
>Likewise, I don't 
>> > think PHP can say "turn this into a 500 error" to Apache.
>> >
>> > John
>> >
>> >
>> > >
>> > > -- james
>> > >
>> > >> -Original Message-
>> > >> From: John Coggeshall [mailto:[EMAIL PROTECTED]]
>> > >> Sent: Wednesday, November 20, 2002 10:48 PM
>> > >> To: 'James Cox'
>> > >> Subject: RE: [PHP-DEV] error handling
>> > >>
>> > >>
>> > >> >that can't really be done because parsing has happened, and so 
>> > >> >output has started -- but if we return status 500, the 
>webserver 
>> > >> >can manage it properly..
>> > >>
>> > >> Only if output buffering is off. Custom error handling should 
>> > >> have output buffering on anyway as I've already said... John
>> > >>
>> > >>
>> > >
>> >
>> >
>> 
>> 
>> --
>> PHP Development Mailing List <http://www.php.net/>
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Windows Threads

[John Coggeshall]

Shane (and everyone else):


>Why don't we move PHP into a separate executable. Design a 
>"thin" ISAPI DLL which purely passes the data which the ISAPI 
>DLL exposes between the IIS process and the PHP process (or 
>process-pool for added reliability). The resulting page is 
>processed in the application server and returned to the ISAPI 
>DLL where it is output.

Shane and I have already been looking into a similar solution for the
UNIX version of PHP. In fact, if you ask'd him I think he's already got
something working in this respect using FastCGI. 

Incidently, Shane weren't you involved in the Windows port of PHP? :)

>I think this solution will be *way* easier than trying to fix 
>every single bug in PHP so that it is utterly thread-safe and 
>crash-free.

That's the idea. Part of the issue is that the external libraries PHP
uses can't be promised to be thread-safe.

>If anyone wants to take this on I can give source code to my 
>DLL and application server to give you a kickstart in the 
>right direction.

I'm CC'ing Shane on this... 



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [PATCH] Redirect on Error

[John Coggeshall]

Okay...

Well, even though I've yet to convince Derick and a few others... I did
see enough interest in this to create a patch. This creates two new
directives: error_redirect (bool) which turns this on/off, and
error_redirect_url (string) which is the URL to redirect to upon error.
In order for these directives to have any effect, the headers (of
course) must not have been already sent. This means that either output
buffering must be enabled, or the script never got around to outputting
anything. This patch will allow users to handle every error PHP
generates if desired (including E_PARSE, etc).

The URL which is redirected to is passed the following parameters via a
GET statement:

errno - The error number (i.e. E_PARSE, whatever)
Errfile - The path/file of the effected file
Errline - The line which the error occurred
Errmsg - The message provided describing the error:

If the redirection fails (i.e. because headers had already been sent,
whatever) the standard PHP error routine is used. 

Disclaimer: This is totally meant to be RFC at this point. It works, but
Its not very friendly right now with the other error stuff (i.e.
error_prepend, etc). If I can get a +1 on this concept, I'll clean
things up before I commit.

John

--- php4/main/main.org.cThu Nov 21 05:43:05 2002
+++ php4/main/main.cThu Nov 21 05:43:18 2002
@@ -236,6 +236,8 @@
STD_PHP_INI_ENTRY("docref_root", "http://www.php.net/";,
PHP_INI_ALL,   OnUpdateString,  docref_root,
php_core_globals,   core_globals)
STD_PHP_INI_ENTRY("docref_ext", "",
PHP_INI_ALL, OnUpdateString, docref_ext,
php_core_globals,core_globals)
STD_PHP_INI_BOOLEAN("html_errors",  "1",
PHP_INI_ALL, OnUpdateBool,   html_errors,
php_core_globals,core_globals)
+   STD_PHP_INI_BOOLEAN("error_redirect",   "0",
PHP_INI_SYSTEM, OnUpdateBool,   error_redirect,
php_core_globals,   core_globals)

+STD_PHP_INI_ENTRY("error_redirect_url", NULL,
PHP_INI_SYSTEM, OnUpdateString,
error_redirect_url, php_core_globals,core_globals)
STD_PHP_INI_BOOLEAN("xmlrpc_errors","0",
PHP_INI_SYSTEM, OnUpdateBool,   xmlrpc_errors,
php_core_globals,core_globals)
STD_PHP_INI_ENTRY("xmlrpc_error_number","0",
PHP_INI_ALL,OnUpdateInt,
xmlrpc_error_number,php_core_globals,   core_globals)
STD_PHP_INI_ENTRY("max_input_time", "-1",
PHP_INI_SYSTEM|PHP_INI_PERDIR,  OnUpdateInt,
max_input_time,php_core_globals,core_globals)
@@ -605,7 +607,40 @@
if (prepend_string) {
PUTS(prepend_string);
}
-   php_printf(error_format, error_type_str, buffer,
error_filename, error_lineno);
+   if(PG(error_redirect) && !SG(headers_sent)) {
+
+sapi_header_line ctr = {0};
+char *url_params;
+
+int out_url_len, t_header_len;
+
+url_params = do_alloca(ERRORURL_BUF_LEN);
+
+snprintf(url_params,
+ERRORURL_BUF_LEN-1,
+
"?errno=%d&errfile=%s&errline=%d&errmsg=%s",
+type,
+php_url_encode((char
*)error_filename, strlen(error_filename), NULL),
+error_lineno,
+php_url_encode(buffer,
strlen(buffer), NULL));
+
+/* The +10 is to account for "Location:  "
*/
+t_header_len =
strlen(PG(error_redirect_url)) + strlen(url_params) + 10;
+ctr.line = do_alloca(t_header_len);
+snprintf(ctr.line,
t_header_len+9,"Location:  %s%s", PG(error_redirect_url), url_params);
+
+ctr.line_len = strlen(ctr.line);
+
+sapi_header_op(SAPI_HEADER_REPLACE, &ctr
TSRMLS_CC);
+
+free_alloca(url_params);
+free_alloca(ctr.line);
+
+   } else {
+
+php_printf(error_format, error_type_str,
buffer, error_filename, error_lineno);
+   }
+
if (PG(xmlrpc_errors)) {
free_alloca(error_format);
}


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>Who cares?  :) It really would be much better if some person 
>who thinks 
>IIS rulez fixes the ISAPI module. If that doesn't work 
>correctly nobody 
>should use it at all.

I'm not saying I'm a IIS fan. :) I rather implement one solution
Which works, period. IMHO that's better than have different "work
arounds" for each
Version of PHP. 

If I hacked on the source a bit and got this redirect-error thing
working, would it
Be perhaps worthy of a commit?

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>
>If ErrorDocument is implemented as a sub-request in Apache, it 
>would be 
>enough for PHP to set one or more Apache notes with the necessary 
>information.

Again, what about IIS, etc? 

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>I also believe that header("HTTP/1.1 500 ...") will do the 
>trick, and there is also the revamped Apache hooks stuff that 
>is being worked on that should give even more control to 
>developers who choose to use it.

For some reason here, everyone is forgetting that PHP isn't running just
on apache web servers. I don't agree with the idea of relying on the
potential of apache_hooks, when they are still experimental and
furthermore of course Apache-specific. 

I think everyone is in agreement here that better ways to deal with
"fatal" errors is desirable, and we seem to be aruging about
implementation. Although I do like the idea of having a 500 error, I
don't believe it provides enough flexablity to the developer when
dealing with the error (since there is no way to determine the nature of
the error). 

With that in mind, here's what I propose:

1) two new configuration directives. The first error_handler which
supports the following forms:

internal  (default) -- the standard method of handling errors 
url Upon an error, re-direct the browser to a new URL
and pass a GET query containing the error info
  servercreate a 500 error
  
   The second directive error_handler_url should specify the URL to pass
to if 'url' for error_handler is specififed

2) If the URL option is used, all of the standard error parameters are
passed via GET parameters

I believe this way provides the most flexablity to deal with any error
PHP is going to throw at a user without breaking old code. 

Please RFC of course :)

John


>-Original Message-
>From: Chris Shiflett [mailto:[EMAIL PROTECTED]] 
>Sent: Wednesday, November 20, 2002 6:31 PM
>To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: RE: [PHP-DEV] error handling
>
>
>--- John Coggeshall <[EMAIL PROTECTED]> wrote:
>> See, the problem that I'm seeing here is that I don't believe PHP is 
>> reponsible for setting the error code returned by PHP.. For 
>instance, 
>> a 404 error isn't handle by PHP at all. Likewise, I don't think PHP 
>> can say "turn this into a 500 error" to Apache.
>
>
>Chris
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>true...
>
>i'd like to see a 500 error though, and some persistent vars...

See, the problem that I'm seeing here is that I don't believe PHP is
reponsible for setting the error code returned by PHP.. For instance, a
404 error isn't handle by PHP at all. Likewise, I don't think PHP can
say "turn this into a 500 error" to Apache. 

John


>
> -- james
>
>> -Original Message-
>> From: John Coggeshall [mailto:[EMAIL PROTECTED]]
>> Sent: Wednesday, November 20, 2002 10:48 PM
>> To: 'James Cox'
>> Subject: RE: [PHP-DEV] error handling
>> 
>> 
>> >that can't really be done because parsing has happened, and so
>> >output has started -- but if we return status 500, the 
>> >webserver can manage it properly..
>> 
>> Only if output buffering is off. Custom error handling should have 
>> output buffering on anyway as I've already said... John
>> 
>> 
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

|>And how about that we change PHP so that it changes
|>the status of the response to 500 on a fatal error? Then
|>you would be able to use the Apache directive
|> 
|>ErrorDocument 500 /handle-my-errors.php
|> 
|>to deal with them. You would have to use output buffering,
|>of course, but using output buffering is the only way to
|>shield your users from errors anyway.
|
|+1 !!
|
|Why didn't anyone think of this before? :)

A couple of problems with that:

1) No way for handle-my-errors.php to know the details of the error such
as errorcode, file, etc)
2) Relies on the web server (not PHP) to re-direct the user to another
script

If we are willing to do this, think we're better off creating a
directive error_url which requires output buffering enabled and
re-directs the user to another URL with GET parameters containing the
error messages.

John



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Just a little question (sidenote)

[John Coggeshall]

On a sidenote, is it possible in Zend to implmement something such as:

$string = "Foobar";
$string = &$string[1];

I actually thought that would work, however upon testing it throws an
error... Just curious.

John



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Error Handler

[John Coggeshall]

Did we ever come to some sort of agreement on the error handler thing? 

I'd like to maybe look into working on maybe putting together the
redirect-on-error system we discussed (implementing a new directive
which if set will re-direct the user to another web page if PHP errors
out).

Someone grunt in my direction in approval :)

John


|-Original Message-
|From: Marcus Börger [mailto:[EMAIL PROTECTED]] 
|Sent: Monday, November 18, 2002 10:53 PM
|To: Mike Leddy
|Cc: [EMAIL PROTECTED]
|Subject: Re: [PHP-DEV] Memory persistence with apache question
|
|
|Problems that could arise:
|The sytem tries to open images and does not unset the 
|variables...and such. I guess when everything is working you 
|cannot do anything against. If you want to investigate more 
|you would need a debug version from php to verify if all 
|memory is freed.
|
|But this is the post from the developer who is assigned to the bug on 
|Sourceforge:
|
| >Date: 2002-10-23 17:59
| >Sender: bharat
| >Logged In: YES
| >user_id=42211
| >
| >This is fixed in v1.3.2
|
|marcus
|
|At 04:33 19.11.2002, Mike Leddy wrote:
|>Hello,
|>
|>I administer a linux 2.4.19/apache 1.3.26/php 4.1.2 server in an ISP.
|>
|>Recently some clients started using a gallery php script: 
|>http://gallery.sf.net
|>
|>that causes excessive memory utilization on the server: 
|>http://sourceforge.net/tracker/index.php?func=detail&aid=49802
|8&group_i
|>d=7130&atid=107130
|>
|>So here goes the question:
|>
|>In what situations will memory allocated to a script remain with the 
|>apache process after the script has terminated ?
|>
|>I always thought that memory allocated would be released on script 
|>termination - Am I wrong in this assumption ?
|>
|>Could it be that the heap in the apache process stays at the 
|maximally 
|>used level ?
|>
|>Thanks for any pointers or how I should approach resolving this 
|>problem. (I am already using 'MaxRequestsPerChild 5' in apache as a 
|>stopgap
|>measure)
|>
|>Mike
|>
|>
|>
|>--
|>PHP Development Mailing List <http://www.php.net/>
|>To unsubscribe, visit: http://www.php.net/unsub.php
|


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>> http://somewhere.com/error.php?errno=4";); ?>
>
>> This way, users who don't care can still re-direct a browser 
>to a nice 
>> and pretty "sorry, the server is really screwed" HTML page... Or, if 
>> they'd like, they can simply take that error number and create a 
>> error-handler in PHP without us having to bother with the problems 
>> surrounding a bad parser-state...
>
>I don't think this will work. First of all PHP would have to 
>do output buffering as sending an header() after output has 
>been sent wont work.

Simply fixed if you fix output buffering to ON if you are using a custom
re-direct handler for errors.

>Also if I allow users to input PHP code to allow for greater 
>customization of an application then I wouldn't want eval() to 
>redirect you to the page saying the site is down for 
>maintenance when they preview their script. (I'd rather have 
>eval() create a non fatal error so I can give them a more 
>useful error message.)

What are you doing giving users access to eval()??? That's an incredibly
huge security risk allowing an arbitary user to execute code of their
choosing on your server... (I shiver to think if you actually had the
PEAR Inline_C installed).. Besides, as with all of the directives in
this nature, a function or two could be created to get/set this
directive as necessary from PHP code.

>If people are updating a site with code they haven't tested 
>then you probably are not running a major site, or shouldn't 
>be. If you expect things to break while doing an upgrade it is 
>easy enough to force the web server to serve an "Upgrade in 
>progress page."

Valid, but I'd be careful being too judgemental... I've seen some pretty
big web sites doing some pretty stupid things ... Putting untested code
on them is sometimes the least of it.

John


>-- 
>Kjartan <[EMAIL PROTECTED]> (http://natrak.net/)
>:: "Choose your friends by their character and your socks by
>their color. Choosing your socks by their character makes
>no sense, and choosing your friends by their color is
>unthinkable."
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>hmm, I really thought we didn't have one, as it doesn't make sense at 
>all :)

Ha! I'm not crazy! :)

>>Having a solid way to 
>> gracefully bow-out because my cat managed to open, fill with 
>junk, and 
>> save a critical include file would just be nice. The choice between 
>> the blank screen, or a nasty error message isn't a good one... I'd 
>> personally love to have a "sorry, our site is hosed" error 
>page... If 
>> for nothing else then piece of mind...
>
>Your cat knows your passwords? :) Anyway, you can always use the 
>error_append_string and error_prepend_string for this. (by 
>putting  in append string for example).

Not true. All I've done in that case is display a half-completed page
And hide the fact it died in a comment. Not to mention that doesn't
allow
For any sort of e-mailing me to let me know my cat hacked my account
again
(she's a smart little bugger). I guess I just really do believe that
PHP's 
Error handling mechanism has little real use in its current form. There
are
Better methods of dealing with logic-errors than using trigger_error()
if
The only thing they are good for is logic-errors... However, If I could
handle
Every single error that didn't cause some catastrophe seg-fault I feel
that
It would add a nice capability to the language. 

Hence, I am still standing by my re-direct (with GET parameters for the
nature
Of the error :)) suggestion :)

John
(and his cat)


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>uhm, John, we dont have a E_PARSE yet. 

It's late... I actually stared at that sentence for about 30 seconds
trying to determine if I had spelled PARSE wrong... Then I actually went
and checked the manual to make sure I hadn't lost my mind and there was
actually a E_PARSE constant... Now I'm just confused as to what the heck
your talkin' about Derick :)

>I stil see not why you would want to handle PARSE errors 
>gracefully. If 
>a user has broken code it should not even be on a production box. Bad 
>code -> dead site. 

Can't argue about broken code not being a production box. However,
dealing with errors in code cleanly (regardless of the problem) is more
than just an internal PHP problem. Having a solid way to gracefully
bow-out because my cat managed to open, fill with junk, and save a
critical include file would just be nice. The choice between the blank
screen, or a nasty error message isn't a good one... I'd personally love
to have a "sorry, our site is hosed" error page... If for nothing else
then piece of mind... 

On a secondary note, as Rasmus pointed out when Mattia first suggested
his ideas for error handling, everyone's got their own method. This
seems like a reasonable and easy way to allow Mattia to SMS, Fax, Call,
log, whatever on a critical error without forcing the rest of the PHP
community to conform to an entirely new way of doing business.

John


>Derick
>
>-- 
>
>---
>
> Derick Rethans   
>http://derickrethans.nl/ 
> JDI Media Solutions
>--[ 
>if you hold a unix shell to your ear, do you hear the c? ]-
>
>
>-- 
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>> Can't argue with that, however (;)), I find it annoying that 
>PHP stops 
>> processing if there is a parse error passed to an eval() 
>command. I'd 
>> like a way to make eval() just return E_PARSE if the script 
>passed to 
>> it fails.

This is exactly the type of situation where E_PARSE really bothers me as
well.. Although no one likes eval(), and it seems to me it is become
more and more of a security-risk and less and less useful... The last
time I've actually seen it implemented in a useful way (that couldn't be
done in a better way) was in PHPLIB. Then again, maybe I'm not coding
things that would need such a function :)
 
>>   $code_str(implode("", file("include.inc")));
>>   if (php_valid($code_str)) {
>> include_once("include.inc");
>>   }
>
>That would be hard, as the zend_compile function which runs the parse 
>also adds the functions, so if the code parses it includes it right 
>away. Again, for this one we _could_ not abort the script, but in the 
>case of include files I'd like to see it die hard again. eval() is 
>something different in a logical way, but the implementation 
>in the zend 
>engine is about the same.

What about require'd files?

Back on the note that I was discussing (the E_PARSE with a user
error-handler), Perhaps the issue can be slightly skirted without having
to code a whole lot... Specifically, what about simply re-directing the
user to another URL in the event of a fatal PHP error (as specified by a
directive)... Ie.

On_fatal_error=http://somewhere.com/error.php

Where on a E_PARSE, or something similar, PHP basically does a C-version
of:

http://somewhere.com/error.php?errno=4";); ?>

This way, users who don't care can still re-direct a browser to a nice
and pretty "sorry, the server is really screwed" HTML page... Or, if
they'd like, they can simply take that error number and create a
error-handler in PHP without us having to bother with the problems
surrounding a bad parser-state...

John


>Derick
>
>-- 
>
>---
>
> Derick Rethans   
>http://derickrethans.nl/ 
> JDI Media Solutions
>--[ 
>if you hold a unix shell to your ear, do you hear the c? ]-
>
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[John Bradford]

> I don't like this patch because it doesn't add anything to PHP itself. 
> You can easily do this with the error_prepend_string and 
> error_append_string configuration settings.

> You were also told that this functionality can be achieved with 
> error_prepend_string and error_append_string ini settings, so there
> is no real need for additional functionality.

Ah, right, sorry about that I didn't read the explaination properly
:-).  Yes, you're right, it can be done without a patch.

What I'm now thinking, though, is that it might be useful to have all
of the non-fatal error messages buffered, and output in a visible way
at the end.  I know you can log to a file, or the system log, but I
can't see a way of buffering all errors until the script ends either
properly, or with a fatal error.

Is this worth working on, or a waste of time? :-)

John.

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

FW: [PHP-DEV] error handling

[John Coggeshall]

This is what I sent Derick about a possible method of implementing a
custom error handler for E_PARSE, etc... Free to flame if I'm off base
here :)


>-Original Message-
>From: John Coggeshall [mailto:[EMAIL PROTECTED]] 
>Sent: Monday, November 18, 2002 3:52 AM
>To: 'Derick Rethans'
>Subject: RE: [PHP-DEV] error handling
>
>
>
>>Core errors are _fatal_ because it leaves the engine in an unclean
>>state. If you have a parse error then the script hasn't been parsed  
>>fully and thus the compilation step did not even interpreted 
>>the tokens 
>>generated by the parse, so how do you want PHP to execute a 
>>function then?
>
>Well, in order for it to work you'd have to be prepared to 
>parse the Error function completely on its own merit... How 
>about this...
>
>Create a configuration directive error_handler which accepts 
>one of Two values... Either a PHP script (like auto_prepend) 
>which is responsible For dealing with any (and all) errors 
>which occur, or 'internal' which is Of course the internal PHP 
>handler.. Then, upon script execution if there Is a 
>error_handler script that gets executed and parsed first. If 
>no core Errors occur during the parse/execution of the error 
>handler script then shouldn't The engine be capiable of 
>executing that script upon an error somewhere else?
>
>John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] error handling

[John Bradford]

> I think in a modern web application the error handling function should do
> the following:
> in case of error (any: parse error, internal application error,)
> 
> 1. a message should be shown to the user sayng that an error has occured
> like "an internal error has occured. the webmaster has been notified via
> email"
> 2. a more detailed message should be logged in a generic system ErrorLog, or
> notified via email or fax, or telephone, or SMS. Depending on the severity
> of the error (warning, fatal,...)

On a similar note, I posted a patch a few days ago which was intended
for development environments - it makes error messages appear in a
clear 'window' in the middle of the browser window, so that you don't
have to hunt around in the output of the program to find it.  I've
attached it again, in case you're insterested.

John.

Index: main/main.c
===
RCS file: /repository/php4/main/main.c,v
retrieving revision 1.512
diff -u -r1.512 main.c
--- main/main.c 12 Nov 2002 14:40:00 -  1.512
+++ main/main.c 14 Nov 2002 20:57:31 -
@@ -246,6 +246,7 @@
STD_PHP_INI_BOOLEAN("expose_php",   "1",
PHP_INI_SYSTEM, OnUpdateBool,   expose_php,
 php_core_globals,   core_globals)
STD_PHP_INI_ENTRY("docref_root", "http://www.php.net/";, PHP_INI_ALL,   
 OnUpdateString, docref_root,php_core_globals, 
  core_globals)
STD_PHP_INI_ENTRY("docref_ext", "",
 PHP_INI_ALL,OnUpdateString, docref_ext,   
  php_core_globals,   core_globals)
+   STD_PHP_INI_BOOLEAN("fancy_html_errors","1",PHP_INI_ALL,   
+ OnUpdateBool,   fancy_html_errors,  
+php_core_globals,   core_globals)
STD_PHP_INI_BOOLEAN("html_errors",  "1",
PHP_INI_ALL,OnUpdateBool,   html_errors,   
 php_core_globals,   core_globals)
STD_PHP_INI_BOOLEAN("xmlrpc_errors","0",
PHP_INI_SYSTEM, OnUpdateBool,   xmlrpc_errors, 
 php_core_globals,   core_globals)
STD_PHP_INI_ENTRY("xmlrpc_error_number","0",PHP_INI_ALL,   
 OnUpdateInt,xmlrpc_error_number,php_core_globals, 
  core_globals)
@@ -453,7 +454,11 @@
}
}
if (PG(html_errors)) {
-   php_error(type, "%s(%s) [%s]: 
%s", get_active_function_name(TSRMLS_C), params, docref_root, docref, docref_target, 
docref, buffer);
+   if (PG(fancy_html_errors)) {
+   php_error(type, "%s(%s)
+ [%s]: %s", get_active_function_name(TSRMLS_C), params, 
+docref_root, docref, docref_target, docref, buffer);
+   } else {
+   }   
+   php_error(type, "%s(%s) [%s]: %s", 
+get_active_function_name(TSRMLS_C), params, docref_root, docref, docref_target, 
+docref, buffer);
} else {
php_error(type, "%s(%s) [%s%s%s]: %s", 
get_active_function_name(TSRMLS_C), params, docref_root, docref, docref_target, 
buffer);
}
@@ -609,6 +614,9 @@
error_format = PG(html_errors) ?
"\n%s:  %s in %s on line 
%d\n"
: "\n%s: %s in %s on line %d\n";
+   if (PG(fancy_html_errors)) {
+   error_format = "\n%s:  %s in %s on line %d\n";
+   }
if (PG(xmlrpc_errors)) {
error_format = do_alloca(ERROR_BUF_LEN);
snprintf(error_format, ERROR_BUF_LEN-1, "faultCode%ldfaultString%%s:%%s
 in %%s on line 
%%d", 
PG(xmlrpc_error_number));
Index: main/php_globals.h
===
RCS file: /repository/php4/main/php_globals.h,v
retrieving revision 1.84
diff -u -r1.84 php_globals.h
--- main/php_globals.h  21 Oct 2002 16:41:06 -  1.84
+++ main/php_globals.h  14 Nov 2002 20:57:31 -
@@ -125,6 +125,7 @@
char *docref_ext;
 
zend_bool html_errors;
+   zend_bool fancy_html_errors;
zend_bool xmlrpc_errors;
 
long xmlrpc_error_number;


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

>Both? I'm not totally sure what you mean with "when the custom error 
>handler also has errors". Can you elaborate?

Okay



Which would output something like this:

Error: There was an parse error on line X of file.php.
Additional Error: Custom error handler myerrorhandler() also errored in
line X of file.php

What I mean here is that, allow PHP to have custom error handlers for
core errors instead of just the user-defined errors.

Am I being clear?

John

>(and can you please use "> " for quoting mail?)
>
>Derick
>
>-- 
>
>---
>
> Derick Rethans   
>http://derickrethans.nl/ 
> JDI Media Solutions
>--[ 
>if you hold a unix shell to your ear, do you hear the c? ]-
>
>


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

|And this can never be supported safely, as a parse error leaves the 
|parse in an unstable state. Also, I really don't think that we should 
|try to add hacks to make this possible.

Is this directed toward my wish (of having a secondary error if the
custom error handler also errors) or toward Mattia's suggestion?

John


|Derick
|
|-- 
|
|---
|
| Derick Rethans   
|http://derickrethans.nl/ 
| JDI Media Solutions
|--[ 
|if you hold a unix shell to your ear, do you hear the c? ]-
|
|


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[John Coggeshall]

|I know this is possible now, but not within the error handling 
|function of PHP, or without setting a custom error handler.

Well, it's not really possible now -- a E_PARSE won't get thrown to a
custom PHP handler, it'll just die with a parse error. 

If there is an improvement to be made, perhaps something like what
Apache does:

Parse Error on line blah blah, Additionaly, there was XYZ error in
errorhandle.php.

Maybe I can look into this... I'm kinda busy right now though.

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: php4 / configure.in /main php_version.h

[John Coggeshall]

|What is left to do to get 4.3.0 out the door? Anyone have any 
|sort of list or idea Of where things need to be polished/cleaned up? 

I meant of course beyond the little TODO already posted :)

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: php4 / configure.in /main php_version.h

[John Coggeshall]

|I thought we're going with 5.0.0 after 4.3.0? Obviously we'd 
|maintain the 
|4.3.0 branch and continue to release bug fix releases. Or do 
|you think we 
|should wait for 4.3.1? I'm a bit concerned about 5.0 lingering for too 
|long. You can see how 4.3 has lingered.

I was under the impression there would be a 4.4.0 then a 5.0. I would
like
To see it head right toward 5.0 

What is left to do to get 4.3.0 out the door? Anyone have any sort of
list or idea
Of where things need to be polished/cleaned up? 

John


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php