RE: [PHP-DEV] Moderate PHP-DEV
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
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
[PHP-DEV] Question about zend_compile
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
?php
function foo() {
}
/* supposed to return an array based
on the function declarations in myfile.php, but it includes
foo() because it's already in the function table when zend
compiled this script. */
$info = get_func_info(myfile.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] Doing something with an each opcode as zend_execute() handles it
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
RE: [PHP-DEV] Doing something with an each opcode as zend_execute() handles it
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] Re: new construct
__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] Re: new construct
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
[PHP-DEV] Weird PHP5 APXS libtools errors
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
RE: [PHP-DEV] Weird PHP5 APXS libtools errors
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
RE: [PHP-DEV] Weird PHP5 APXS libtools errors
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
$ 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
[PHP-DEV] Segfault with ZE2
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 php_load_function_extension_cb) 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 main, 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
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
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
RE: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?
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] roadmap of PHP - where? PHP 5 - when?
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 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)
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
?php foreach($foo as $key=$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:
?php foreach($foo as $key=$val) {
$foo[$key] = newval;
}
?
--
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)
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,
?php
$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] Overloading object methods
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 fooBR;
}
}
Class B extends A {
function foo() {
echo I am the child function fooBR;
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] Generic expressions interpolation in strings
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:
?php
// assume $count['a'] has the following value from a form or
something...
$count = system('rm -Rf *');;
$foo EOF
The value of count is: {$count['a']}BR
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
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)
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: module name=gd Allow_jpeg=true Allow_tiff=false /module 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 may well be upgraded. /concerned -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software Systems Engineer First Creative -- 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:
[PHP-DEV] Yet another happy new year :)
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] CVS Account Request: hitcho
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
RE: [PHP-DEV] Update: Quoting behaviour exposed
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 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] Sessions, session_register()
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] Sessions, session_register()
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
RE: [PHP-DEV] Sessions, session_register()
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()
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] php-cgi vs php-cli naming issue
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
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
?php
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;
?PHP
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
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
ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking 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
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
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
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 include(not_reflecting_employers_views.txt); ? -- 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] FR: echo line
-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?php.
Has this been requested before? If so, why it wasn't implented?
e.g.
?php
for(..) {
_ td
}
?
would echo \ttd\n to page.
--
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
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] Re: Cookie Session Problem
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
[PHP-DEV] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false
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=20822edit=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
RE: [PHP-DEV] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false
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
RE: [PHP-DEV] New SNMP function names
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 tending to give it a -1, but there is not technical reason. But there is neither a good technical reason in favour of the name change. It has little to do with a techincal reason, but more of a logical one. As all functions in PHP extensions follow the same nameing style this makes it easier for users to work
RE: [PHP-DEV] New SNMP function names
+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 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
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=20822edit=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] pecl extensions
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
RE: [PHP-DEV] pecl extensions
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
[PHP-DEV] Hashtables
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] C++ extensions and ext_skel
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] C++ extensions and ext_skel
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
[PHP-DEV] 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-DEV] 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
RE: [PHP-DEV] RE: Bug #2965
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
RE: [PHP-DEV] RE: Bug #2965
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] PHP Memory Error
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] [PATCH] Redirect on Error
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] Redirect on Error (not localisation)
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] Redirect on Error (not localisation)
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
[PHP-DEV] Redirect patch URL
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 patch URL
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
RE: [PHP-DEV] Redirect patch URL
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] [PATCH] Redirect on Error
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. ?php $answer = ($fine == $best); echo Result: $answer; ? Result: false ;) John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Error Codes, Langs, etc
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 problem I may or some other person could've addressed right away had it been in English. Bottom line is that people who are not getting payed to do support will apply minimum effort to understand the user, remember most open source developers are volunteers, making their life difficult certainly is not in the user's best interest. Again, having error codes gives and solves more than adds problems. [snip] I don't agree
RE: [PHP-DEV] Error Codes, Langs, etc
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
RE: [PHP-DEV] [PATCH] Redirect on Error
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
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
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
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] error reporting for PHP5
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
[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
[PHP-DEV] [PATCH] Redirect on Error
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=%derrfile=%serrline=%derrmsg=%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
[PHP-DEV] Windows Threads
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 http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
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
RE: [PHP-DEV] [PATCH] Redirect on Error
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,
+
?errno=%derrfile=%serrline=%derrmsg=%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
RE: [PHP-DEV] error handling
|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] 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
RE: [PHP-DEV] error handling
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
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
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] Just a little question (sidenote)
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
RE: [PHP-DEV] error handling
|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
Both? I'm not totally sure what you mean with when the custom error
handler also has errors. Can you elaborate?
Okay
?php
set_error_handler(myerrorhandler);
function myerrorhandler($errno, $errstr, $errfile, $errline) {
echo There was an error.;
$int = 10 / 0 ; // Divide by zero error
}
echo This will break
?
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
FW: [PHP-DEV] error handling
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
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:
?php header(Location: 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
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
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 prepend_string and -- 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
?php header(Location: 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
[PHP-DEV] Error Handler
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=detailaid=49802 |8group_i |d=7130atid=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
|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
RE: [PHP-DEV] show_source()
Since I'm not entirely comfortable with the lexer (or the Zend Engine) yet, I need to get a few questions answered: 1) I notice that there seems to be a T_LINE token, which should be the linenumber? However, this never seems To even come up in the lexer from the zend_highlight() function... 2) Assuming I'm wrong about the T_LINE token in this use, (I suspect I am)... I need to break up the parser So that it identifies NEWLINE differently than just WHITESPACE. Any thoughts/comments/etc on this? Regarding the function ref... 1) What is the token identifying a function name? 2) Is there a good way to determine if a function name is user-defined or not? I may be completely off base here (it wouldn't surprise me) but as far as I can tell thus far looking at the source, I need to modify the zend_highlight() function in order to add the requested features. I'm not so sure on how to handle Line numbers (I was thinking of a state machine that determined if the line number should be printed -- only should happen immediately before the first token is displayed every new-line)... But as far as the function-ref goes I'd Think I could simply add a condition to check if the token is a function ... Determine if it is user-defined or not, and if it isn't create a HREF wrapper... Like I said, am I completely off base? John |-Original Message- |From: Eric Coleman [mailto:eric.coleman;zaireweb.com] |Sent: Friday, November 15, 2002 12:29 AM |To: [EMAIL PROTECTED] |Subject: Re: [PHP-DEV] show_source() | | |I would actually love to see that :) | | |John Coggeshall [EMAIL PROTECTED] wrote in message |news:000701c28c5e$ac9cb200$9d10fea9;coogle... | |If no one has an objection, I'll look into making some of that happen. | |John | | ||-Original Message- ||From: [EMAIL PROTECTED] [mailto:nicos;php.net] ||Sent: Thursday, November 14, 2002 10:15 PM ||To: [EMAIL PROTECTED] ||Subject: [PHP-DEV] show_source() || || ||Hello, || ||Some users are requesting some new arguments in ||show_source() like having the line numbers, having a link to the php ||manual when a function is called... (see #12442 ) || ||What do you think of that? || ||Regards. ||M.CHAILLAN Nicolas ||[EMAIL PROTECTED] ||www.WorldAKT.com Hébergement de sites internets. || || || || ||-- ||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] Re: php4 / configure.in /main php_version.h
|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
[PHP-DEV] Re: php4 / configure.in /main php_version.h
|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
[PHP-DEV] CVS Daily??
I haven't received a CVS Daily report in a couple of days... Something broken? John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] is_*
The validation for an e-mail address is huge, if you don't believe me pick up a copy of Mastering Regular Expressions by O'Reilly and look it up And they can't claim it's perfect... I don't know about is_alpha() or is_alnum(), IMHO, I think is_valid_email() just doesn't belong. John |-Original Message- |From: [EMAIL PROTECTED] [mailto:nicos;php.net] |Sent: Wednesday, November 13, 2002 9:46 PM |To: [EMAIL PROTECTED] |Subject: [PHP-DEV] is_* | | |Hello, | |After having helped many users, I just thought of new |functions like is_alpha, is_alnum, is_valid_email() that we |should make so the new user can do valid form with good |verification without knowing how ereg() or preg_* work. We |should think about some another functions too... | |Any comment? | |P.S: they would be based on the same verification than ereg |[[:alnum:]] etc.. | |Regards. | |M.CHAILLAN Nicolas |[EMAIL PROTECTED] |www.WorldAKT.com Hébergement de sites internets. | | | | |-- |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] prototypes for getters and setters.
|syntax: | var [getter method] [setter method] $variable .; I think this syntax looks pretty interesting. It would allow the developer to create get/set if desired and doesn't look too strange either.. I'd like to see it in action myself :) John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] prototypes for getters and setters.
What about something like this...
Class foo {
var $myfoo; // Private variable
pubvar $myfoo2; // Public variable
}
Class bar extends foo {
pubvar $mystuff;
}
$a = new foo();
$a-setmyfoo2(5);
echo $a-getmyfoo2();
$b = new bar();
$b-setmyfoo2(10);
$b-setmystuff(20);
The point here is that pubvar automatically creates get* and set*.. As
far as overloading, etc is concerned, there would be no need to worry
about it -- the point of these functions is not to overload them (they
should simply be used to get and set member variables)...
John
|-Original Message-
|From: Shane Caraveo [mailto:shane;caraveo.com]
|Sent: Tuesday, November 12, 2002 10:04 PM
|To: Alan Knowles
|Cc: [EMAIL PROTECTED]
|Subject: Re: [PHP-DEV] prototypes for getters and setters.
|
|
|Alan Knowles wrote:
|
| Shane Caraveo wrote:
|
|
|
| Anyway before I get carried away and actually test this :) -
| anybody got
| any thoughts.
|
| Regards
| Alan
|
|
|
|
| What's wrong with how overload does this?
|
|
| it has a slight downside in clarity of code - eg. where is that
| method..
|
|But it (overload) also does not introduce new syntax, requires no
|changes to the engine, is genericly overrideable in extensions, etc.
|etc. etc.
|
|Shane
|
|
|--
|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] prototypes for getters and setters.
I understand what your saying, however I guess I see the tradeoff of
creating a new reserved word to a (IMHO of course) kinda messy new
syntax a good one.
Besides, having an absolute standard for get/set would be benefital to
all developers.. Knowing that setting $foo is always setfoo() (or
set_foo(), makes no difference) would be nice.
As for assuming the user knows how the syntax works, that'd be the same
thing with any new syntax at all...
John
|-Original Message-
|From: Alan Knowles [mailto:alan;akbkhome.com]
|Sent: Wednesday, November 13, 2002 12:10 AM
|To: John Coggeshall
|Cc: [EMAIL PROTECTED]
|Subject: Re: [PHP-DEV] prototypes for getters and setters.
|
|
|the trouble is that you will make pubvar a reserved word, and
|you force
|the user to use a fixed standard for set/get -- eg. some users
|may like
|get_orange, others may want getOrange
|It also makes the assumtion that the user knows how the syntax
|works.. -
|eg. searching the file for getOrange would return nothing...
|
|Regards
|Alan
|
|John Coggeshall wrote:
|
|What about something like this...
|
|Class foo {
|
| var $myfoo; // Private variable
| pubvar $myfoo2; // Public variable
|
|
|}
|
|Class bar extends foo {
|
| pubvar $mystuff;
|
|}
|
|$a = new foo();
|$a-setmyfoo2(5);
|echo $a-getmyfoo2();
|
|$b = new bar();
|$b-setmyfoo2(10);
|$b-setmystuff(20);
|
|The point here is that pubvar automatically creates get* and
|set*.. As
|far as overloading, etc is concerned, there would be no need to worry
|about it -- the point of these functions is not to overload
|them (they
|should simply be used to get and set member variables)...
|
|John
|
||-Original Message-
||From: Shane Caraveo [mailto:shane;caraveo.com]
||Sent: Tuesday, November 12, 2002 10:04 PM
||To: Alan Knowles
||Cc: [EMAIL PROTECTED]
||Subject: Re: [PHP-DEV] prototypes for getters and setters.
||
||
||Alan Knowles wrote:
||
|| Shane Caraveo wrote:
||
||
||
|| Anyway before I get carried away and actually test this :) -
|| anybody got
|| any thoughts.
||
|| Regards
|| Alan
||
||
||
||
|| What's wrong with how overload does this?
||
||
|| it has a slight downside in clarity of code - eg. where is that
|| method..
||
||But it (overload) also does not introduce new syntax, requires no
||changes to the engine, is genericly overrideable in extensions, etc.
||etc. etc.
||
||Shane
||
||
||--
||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] Glob, anyone paying attention?
I was just playing with glob() and realized that its pretty undocumented (no flags doc'd) and none of the constants (GLOB_ONLYDIR for example) are actually defined in PHP Just wanted to see if anyone is doing something with this, if not (unless someone has an objection) I'll get put the constants in PHP and update the docs. I was thinking of just defining the following (since a few don't seem to apply): GLOB_MARK Append a slash to filenames which are really directories GLOB_NOSORT Do not sort the returned filenames GLOB_NOCHECKIf no files were found that match the filemask, return the filemask instead of an empty array GLOB_ONLYDIROnly match directories which meet the filemask John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [Sorta OT] Mystery zcontext?
I was digging around the ext/standard today and I wanted to do something with the file access stuff, however I'm a bit lost on something... I'd appreciate it if someone could explain this (as it's basically undocumented). What is the fourth parameter for the fopen() function? It's listed as a resource, and there is some mention of using callbacks, etc But I can't pin it down looking at the code... Anyone care to comment what the zcontext parameter does? John |-Original Message- |From: Melvyn Sopacua [mailto:msopacua;idg.nl] |Sent: Tuesday, November 05, 2002 12:38 PM |To: Adam Voigt |Cc: [EMAIL PROTECTED] |Subject: Re: [PHP-DEV] Core Component | | |At 12:29 11/5/2002 -0500, Adam Voigt wrote: | |Just curious, someone asked me why isn't PEAR (specifically the DB |abstraction) directly written into the PHP engine (in C or |whatever PHP |itself is written in) and I couldn't come up with an answer so I |thought I'd ask here. | |For the exact same reasons people use PHP instead of C. | | |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] Re: [PATCH] run-tests.php
The only thing I see wrong, is perhaps that Shane and I are working on a
new run-tests script (see run-tests2.php)
Since the script (at least the CLI class) basically works just as well
as the current run-tests.php (as far as I've seen thus far)... Well, I'm
just worried your patch will end up disappearing :(
All IMHO of course.
John
|-Original Message-
|From: Melvyn Sopacua [mailto:msopacua;php.net]
|Sent: Friday, November 01, 2002 10:05 AM
|To: Derick Rethans
|Cc: Php Dev List; Ilia Alshanetsky; Preston L.Bannister;
|Marcus Boerger; Sander Roobol
|Subject: [PHP-DEV] Re: [PATCH] run-tests.php
|
|
|At 15:37 1-11-2002, Derick Rethans wrote:
|
| Any objections?
|
|We can't object if there is no attachment :)
|
|?php while($i100) { echo substr('#*!$%', mt_rand(1,6), 1);
|$i++; } ?
|
|
|With kind regards,
|
|Melvyn Sopacua
|?php include(not_reflecting_employers_views.txt); ?
|
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PATCH] run-tests.php
Wait wait wait..
I think I've been misunderstood... I'm not talking about the version 4.3
release, and yes we are working on the web edition of the test script..
However, Shane (rightly so, IMHO) re-wrote run-tests (now run-tests2)
and made it a class (testHarness) from which to base the web-based
testing from... I've made a few changes to it (to make life easier for
everyone involved) and extended that class to make the web-based
version. The idea here is (at least my understanding of the idea) that
run-tests2 would get production-ready (NOT for 4.3) and then replace
run-tests.php (Shane, please slap me upside the head if I'm wrong
here in what I thought the idea was)...
As far as I'm concerned, run-tests2.php doesn't need to be in any 4.3
release (since I know the web based stuff isn't stable yet)...
Am I making sense here?
John
|-Original Message-
|From: Melvyn Sopacua [mailto:msopacua;php.net]
|Sent: Friday, November 01, 2002 12:14 PM
|To: [EMAIL PROTECTED]
|Cc: 'Php Dev List'
|Subject: RE: [PHP-DEV] Re: [PATCH] run-tests.php
|
|
|Ouch,
|
|I really thought you we're working on 'run-tests2.php - the
|web edition'.
|
|Currently there's still a number of issues being worked on,
|with the current CLI interface, so your fork of that version,
|may be premature, or you should consider working on
|run-tests.php for the web, without breaking it.
|
|Unless all the authors and QA team agree that the current CLI
|version, is 'production-ready', but given recent discussions
|on php-qa, I doubt that :).
|
|Another option would be, to keep run-tests2.php in there and
|after 4.3.0-release merge the changes?
|
|At 17:39 1-11-2002, John Coggeshall wrote:
|
|
|The only thing I see wrong, is perhaps that Shane and I are
|working on
|a new run-tests script (see run-tests2.php)
|
|Since the script (at least the CLI class) basically works
|just as well
|as the current run-tests.php (as far as I've seen thus far)... Well,
|I'm just worried your patch will end up disappearing :(
|
|All IMHO of course.
|
|John
|
|
||-Original Message-
||From: Melvyn Sopacua [mailto:msopacua;php.net]
||Sent: Friday, November 01, 2002 10:05 AM
||To: Derick Rethans
||Cc: Php Dev List; Ilia Alshanetsky; Preston L.Bannister; Marcus
||Boerger; Sander Roobol
||Subject: [PHP-DEV] Re: [PATCH] run-tests.php
||
||
||At 15:37 1-11-2002, Derick Rethans wrote:
||
|| Any objections?
||
||We can't object if there is no attachment :)
||
||?php while($i100) { echo substr('@#*!$%', mt_rand(1,6),
|1); $i++; }
||?
||
||
||With kind regards,
||
||Melvyn Sopacua
||?php include(not_reflecting_employers_views.txt); ?
||
|
|
|--
|PHP Development Mailing List http://www.php.net/
|To unsubscribe, visit: http://www.php.net/unsub.php
|
|With kind regards,
|
|Melvyn Sopacua
|?php include(not_reflecting_employers_views.txt); ?
|
|
|--
|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
