Re: [PHP-DEV] session security
Keyser Soze [EMAIL PROTECTED] wrote... : There's also something I'm using in my session scripts. I compare the browser referer with all the possible pages it must have come from in each script, this way the user MUST start from the login page, and not can simply type the url with the session id. I only tested it with Internet Explorer 5 and Mozilla (don't remember the version now), it worked fine. This is an insecure method as HTTP_REFERER is being sent by browser. One can simply create a socket connection inputing that variable into the HTTP request headers. -- Maxim Maletsky [EMAIL PROTECTED] []'s Keyser Soze - Original Message - From: Sascha Schumann [EMAIL PROTECTED] To: Hans Prins [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, February 11, 2003 2:08 AM Subject: Re: [PHP-DEV] session security Can anyone point me to a possible solution for this? 1. Use SSL. 2. Throw away an existing session id, if a user authenticated successfully (e.g. destroy the old session, and copy the data into a new one). 3. Provide a logout button which destroys the session. - 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 Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions
On Fri, 07 Feb 2003 14:48:50 +0200 Andi Gutmans [EMAIL PROTECTED] wrote: At 02:37 PM 2/7/2003 +0200, moshe doron wrote: well, what about sun_set(), sun_rise()? me too :) We are not going to have the whole sun extension (which is what this naming convention suggests) :) If ever these two functions would get implemented (which I think is a good idea to have such algorithm) then they would be something like date_sunrise() and date_sunset(). Much more logic, no? +1 for date_sunrise() and date_sunset() -- Maxim Maletsky [EMAIL PROTECTED] I hope you're kidding. Andi -- 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] new idate() - sunrise() - sunset() functions
and `double' should be called `float' for ptoto purposes.
--
Maxim Maletsky
[EMAIL PROTECTED]
Andrey Hristov [EMAIL PROTECTED] wrote... :
- Original Message -
From: Moshe Doron [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, February 06, 2003 5:02 PM
Subject: Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions
Zeev Suraski [EMAIL PROTECTED] wrote in message
5.1.0.14.2.20030206161428.050f11c0@localhost">news:5.1.0.14.2.20030206161428.050f11c0@localhost...
At 13:36 06/02/2003, moshe doron wrote:
b. sunrise()
c. sunset()
Hrm, what are these functions?
* {{{ proto mixed sunrise(mixed time[, double latitude][, double
longitude][, double zenith,][ double gtm_offset][, int format])
Returns time of sunrise for a given day location */
shouldn't be gtm_offset - gmt_offset
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] Bug #21279 Karma request (Windows Bug)
Normally, you should contact the file's maintainers with the similar email as you wrote here and patches attached. The maintainer will review, apply and test the patches. After what, if the maintainer considers you should have the independent CVS access to the repository, he/she will direct you to request the PHP's CVS account and will notify whoever is in the charge for approving it. That is pretty much the way things work here, of course exceptions are possible, but in your case i don't see them. -- Maxim Maletsky [EMAIL PROTECTED] Ernani Joppert Pontes Martins [EMAIL PROTECTED] wrote... : OK, I will change the Style of the comments But that's not the point. The point is that I need CVS Karma to commit it and I don't have. When I get it then I will make the unified diff and send to the list... TIA, Ernani Joseph Tate [EMAIL PROTECTED] escreveu na mensagem [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... You need to use C style /*comments*/. Also, send a unified diff. Do this by running cvs diff -u files you modified. Joseph -Original Message- From: Ernani Joppert Pontes Martins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 10:05 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug #21279 Karma request (Windows Bug) Hi Rasmus, A Few months ago I was willing to help in bug fixes and bcompiler development I solved the bug #21279 and now I need karma to commit my changes there I debbuged the file with the help of Manuel Lemos and I found the bug. Here is the diff: 1615: // Z_STRVAL_P(tmp) = empty_string; 1616: ZVAL_NULL(tmp); 1626: // Z_STRVAL_P(tmp) = empty_string; 1627: ZVAL_NULL(tmp); TIA and HTH, Ernani -- 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] CVS Account Request: cysoft
There are some people already working on the Chinese (Simplified) translation: http://www.php.net/manual/zh/ Please contact them and see whether they need your help. -- Maxim Maletsky [EMAIL PROTECTED] On 6 Feb 2003 01:17:36 - cui yan [EMAIL PROTECTED] wrote: Translating the documentation in to Chinese (Simplified). i just received email form [EMAIL PROTECTED] in the email you denied my request so i appeal against your decision,cause i need CVS just for Translating the documentation,that listed in the page of http://www.php.net/cvs-php.php. please pay more attention on my request. thx a lot. your's yan -- 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] Mono PHP
Seems like it :) In a pre-alpha phase ;) Ans, I also want to do the same for Ruby (in case you haven't heard ;) ) -- Maxim Maletsky [EMAIL PROTECTED] Dan Hardiker [EMAIL PROTECTED] wrote... : Is it true you can catch mono from using php? -- 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: http://www.php.net/unsub.php
Re: [PHP-DEV] problems on building php_win32 release binaries
you need to include a few libs to VC before building. Most of it is within win32build.zip, which you should unpack on your system and set the inc/lib/bin of your VC pointing there. Should fix your issues. -- Maxim Maletsky [EMAIL PROTECTED] Ernani Joppert Pontes Martins [EMAIL PROTECTED] wrote... : Hi Fellows, I was trying to build a win32 version of the CVS Snapshots and I got some problems on its build. Anyways I wish to help with a odbc bug that in not solved yet and I can't understant why some files in the project is missing... The Snapshot version I got was php4-STABLE-200302021430.tar.gz Here is the log of VStudio Configuration: TSRM - Win32 Release_TS Compiling... TSRM.c tsrm_strtok_r.c tsrm_virtual_cwd.c tsrm_win32.c Creating library... Configuration: Zend - Win32 Release_inline Compiling... zend.c zend_alloc.c zend_API.c zend_builtin_functions.c zend_compile.c zend_constants.c zend_execute.c zend_execute_API.c C:\Documents and Settings\Administrador\Desktop\php4_source\Zend\zend_execute_API.c(362) : warning C4018: '==' : signed/unsigned mismatch zend_extensions.c zend_hash.c zend_highlight.c zend_indent.c zend_ini.c zend_ini_parser.c zend_ini_scanner.c zend_language_parser.c zend_language_scanner.c C:\Documents and Settings\Administrador\Desktop\php4_source\Zend\zend_language_scanner.c(5558 ) : warning C4273: 'isatty' : inconsistent dll linkage. dllexport assumed. zend_list.c zend_llist.c zend_multibyte.c Generating Code... Compiling... zend_opcode.c zend_operators.c zend_ptr_stack.c zend_qsort.c zend_sprintf.c zend_stack.c zend_variables.c Generating Code... Creating library... Configuration: libmysql - Win32 Release_inline Compiling... array.c bchange.c bmove.c bmove_upp.c charset.c ctype.c dbug.c default.c dll.c errmsg.c errors.c get_password.c int2str.c is_prefix.c libmysql.c C:\Documents and Settings\Administrador\Desktop\php4_source\ext\mysql\libmysql\libmysql.c(923 ) : warning C4018: '' : signed/unsigned mismatch C:\Documents and Settings\Administrador\Desktop\php4_source\ext\mysql\libmysql\libmysql.c(982 ) : warning C4018: '' : signed/unsigned mismatch list.c longlong2str.c mf_casecnv.c mf_dirname.c mf_fn_ext.c mf_format.c mf_loadpath.c mf_pack.c mf_path.c mf_unixpath.c mf_wcomp.c mulalloc.c my_alloc.c my_compress.c my_create.c my_delete.c my_div.c my_error.c my_fopen.c my_getwd.c my_init.c my_lib.c my_malloc.c my_messnc.c my_net.c my_once.c my_open.c my_pthread.c my_read.c my_realloc.c my_static.c my_tempnam.c my_thr_init.c my_wincond.c my_winthread.c my_write.c net.c password.c safemalloc.c str2int.c strcend.c strcont.c strend.c strfill.c string.c strinstr.c strmake.c strmov.c strnmov.c strtoll.c strtoull.c strxmov.c thr_mutex.c typelib.c violite.c Creating library... Configuration: php4dll - Win32 Release_inline Compiling... aggregation.c css.c cyr_convert.c fopen_wrappers.c C:\Documents and Settings\Administrador\Desktop\php4_source\main\php_network.h(28) : fatal error C1083: Cannot open include file: 'arpa/inet.h': No such file or directory main.c C:\Documents and Settings\Administrador\Desktop\php4_source\main\php_network.h(28) : fatal error C1083: Cannot open include file: 'arpa/inet.h': No such file or directory mergesort.c network.c C:\Documents and Settings\Administrador\Desktop\php4_source\main\php_network.h(28) : fatal error C1083: Cannot open include file: 'arpa/inet.h': No such file or directory output.c ..\ext/zlib/php_zlib.h(25) : fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory php_content_types.c php_ini.c php_logos.c php_open_temporary_file.c php_ticks.c php_variables.c C:\Documents and Settings\Administrador\Desktop\php4_source\main\php_network.h(28) : fatal error C1083: Cannot open include file: 'arpa/inet.h': No such file or directory quot_print.c reentrancy.c rfc1867.c safe_mode.c SAPI.c ..\ext/zlib/php_zlib.h(25) : fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory snprintf.c spprintf.c streams.c C:\Documents and Settings\Administrador\Desktop\php4_source\main\php_network.h(28) : fatal error C1083: Cannot open include file: 'arpa/inet.h': No such file or directory strlcat.c strlcpy.c user_streams.c C:\Documents and Settings\Administrador\Desktop\php4_source\main\user_streams.c(640) : warning C4244: '=' : conversion from 'long ' to 'unsigned short ', possible loss of data C:\Documents and Settings\Administrador\Desktop\php4_source\main\user_streams.c(641) : warning C4244: '=' : conversion from 'long ' to 'unsigned short ', possible loss of data C:\Documents and Settings\Administrador\Desktop\php4_source\main\user_streams.c(642
Re: [PHP-DEV] preg_replace oddity [exploitable]
James E. Flemer [EMAIL PROTECTED] wrote... : I found a more evil example: ?php $a = ___! `rm -rf /tmp/sess_*` !___; $b = preg_replace(/!(.*)!/e, print(\\1);, $a); ? This happily executes rm -rf /tmp/sess_*. I will not give out more examples, but if one examines the code for addslashes() it is quite obvious what you can an cannot do here. Thus it is clearly a Bad Thing for someone to use preg_replace with the /e modifier and not use quotes around the \\n or $n backrefs. The docs should be updated to include a very noticeable warning about this hole. I am contemplating possible solutions for this problem... Also as a side note, it does not seem to be possible to use 'echo' as part of the expression, print must be used. (Yes I know why, just pointing it out.) -James On Thu, 30 Jan 2003, James E. Flemer wrote: Can someone explain what is going on here: --- foo.php --- ?php $a = ___! 52); echo(42 !___; $b = preg_replace(/!(.*)!/e, print(\\1);, $a); print(\n---\na: $a\nb: $b\n); ? --- end --- --- output --- 52 --- a: ___! 52); echo(42 !___ b: ___1___ --- end --- I understand that one is supposed to use single quotes around the \\1 in the above preg_replace. But what happens when they do not? Clearly the echo(42); is not executed, and it is not printed by print(). Even more interesting is if you put something like echo(\42 in $a, then you get a bunch of errors including: Fatal error - Failed evaluating code: print( 52); echo(\42 ); In fact, /e eval()uates the code. It does with the replaced result just what eval() does with a string PHP code. At most, it could be noted in docs. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] can't get wincvs to ask for login
it happens if you are behind the firewall. If so, then create the SSH tunnel from localhost:2401 to cvs.php.net:2401 and connect to localhost instead -- Maxim Maletsky [EMAIL PROTECTED] Greg Beaver [EMAIL PROTECTED] wrote... : Hi, I'm trying to commit some changes, and can't get wincvs to log me in or even to request a password with pserver. I've changed the username from cvsread to cellog. Anyone with wincvs experience know how to make the stupid thing work? Greg -- 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] Again scope
stranno, dovrebbe comunque funzionare datto che ZEND_CHANGES.txt ha quasi
un anno mentre il tuo CVS checkout e, credo, sia un sacco piu fresco.
Sicuro che non funzioni?
---
Maxim Maletsky
[EMAIL PROTECTED]
On 02 Feb 2003 21:56:08 +0100 michel 'ziobudda' morelli [EMAIL PROTECTED] wrote:
Il dom, 2003-02-02 alle 21:31, Maxim Maletsky ha scritto:
da http://www.php.net/ZEND_CHANGES.txt
?php
class FooClass {
function foo() {
$this-bar();
bar();
}
function bar() {
print foobar\n;
}
}
$obj = new FooClass;
$obj-foo();
?
Ok, this not works. My cvs is old, very old. Tnx anyway.
--
michel 'ziobudda' morelli [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Again scope
On Sun, 2 Feb 2003 22:06:24 +0100 (CET) Derick Rethans [EMAIL PROTECTED] wrote: On Sun, 2 Feb 2003, Maxim Maletsky wrote: stranno, dovrebbe comunque funzionare datto che ZEND_CHANGES.txt ha quasi un anno mentre il tuo CVS checkout e, credo, sia un sacco piu fresco. Sicuro che non funzioni? No problem if you answer in italian, but there is no need to CC the list then :-) Sorry, guys - haven't noticed that Michele added php-dev to the conversation :) (Should have guessed why his answer was in english) Anyway, what he talked about was why that code didn't work for him. Sounded strange to me since it was noted in ZEND_CHANGES.txt. --- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Mono PHP
I read the code, quite nice!
It's been a while I was thinking to integrate Ruby into PHP, which would
probably be a very very similar extension as this one. Are they going to get
into the official PHP distr or PECL?
--
Maxim Maletsky
[EMAIL PROTECTED]
On 02 Feb 2003 18:13:10 -0500 Sterling Hughes [EMAIL PROTECTED] wrote:
I spent a little time this weekend implementing an extension that allows
PHP to load .NET classes on the Unix environment - 100% open source, by
leveraging the mono library(*). For more information, view the README
file in the distribution by downloading the file
http://www.edwardbear.org/php_mono_0_1.tar.gz.
Its PHP5 only, as that's what I've switched to for all new development.
Hi Ho.
?php
$Console = new Mono('System.Console');
$Console-WriteLine('Hello World, PHP is .NET ready!');
?
- Sterling No More Extensions Needed Hughes
(*) Mono is much more than library, of course. But it links to/uses the
mono library.
PS: I'll be adding it into PECL in a little bit, I want to finish the
type proxying code. I'd also like to add all of the object and method
caching.
PPS: If anyone has suggestions for a better way of doing type proxying
than what's described in the README, please let me know.
--
First they ignore you, then they laugh at you,
then they fight you, then you win.
- Gandhi
--
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: str_ireplace vs. stri_replace
Ilia A. writes: 1. Not all users will notice the extra parameter easily. Will take some time. This modification will not appear until PHP 5 is released, by then this extra parameter (hopefully) will be well documented and people will be aware that it exists. Adding extra code, which virtually does the same thing IMHO is pointless and only creates a messy code that is difficult to maintain at a future point. 2. If some users made their own function called stri_replace, this is nothing that should be stopping from implementing it officially. In fact, to fix it would be as easy as encapsuling the function declaration in You are correct in the event of a user writing a new function, however consider what will happen if we are dealing with a old code, especially if it is no longer used just by the author but rather by a variety of other people not familiar with PHP code. The result is that after they or their ISPs upgrade to new PHP their scripts will stop working. Yes, but you are talking about a few dozen of cases forgetting thousands of newbies that are seeking for stri_replace function... They aren't guessing whether this time there a forth parameter in str_replace ... I think a logical function set is better for consistency... especially when strstr has stristr, ereg* has eregi* and so on... At the end, releasing PHP all of the sudden with register_globals off by default a year ago made much more damage worldwide... That was a change for PHP5, not in the middle of the releases... But, the reason was good - security. This little change (str(i?)_replace) only asks for removing user defined functions because the official one exists... Once *ALL* PHP users passed through register_globals, I think another dozen of them can go through stri_replace prob :) Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Again scope
dovrebbe essere:
?
Class Foo {
var $foo2;
Function Bar()
{
echo $this-foo2.\n;
print Bar;
}
Function Bar2()
{
$foo2=foo2;
$this-Bar();
}
}
$f = new foo;
$f-Bar2();
?
--
Maxim Maletsky
[EMAIL PROTECTED]
michel 'ziobudda' morelli [EMAIL PROTECTED] wrote... :
?
Class Foo {
var $foo2;
Function Bar()
{
echo $foo2.\n;
print Bar;
}
Function Bar2()
{
$foo2=foo2;
Bar();
}
}
$f = new foo;
$f-Bar2();
?
give me this error:
Fatal error: Call to undefined function: bar() in
/home/httpd/html/PHP/test/3.php on line 14
I'm using php-cli from cvs (2 weeks ago).
And there is a variable scope (for the class).
--
michel 'ziobudda' morelli [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] Re: str_ireplace vs. stri_replace
On Thu, 30 Jan 2003 17:11:53 -0500 Ilia A. [EMAIL PROTECTED] wrote:
On January 30, 2003 04:55 pm, Jon Parise wrote:
On Thu, Jan 30, 2003 at 01:44:27PM -0800, Sara Golemon wrote:
You're not the first to voice this opinion. *I* feel str_ireplace is
better as it follows the naming convention of module_function.
Others feel stri_replace is better as that follows eregi_replace's style.
I have no trouble going with whatever the majority feels is best.
Get rid of stri_replace() and/or str_ireplace() and just add a fourth
optional parameter to str_replace() to control case-sensitivity.
+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.
Although this is not my area of expertise, I would like to express my
negative opinion towards solving the problems with extra parameters.
Why?
1. Not all users will notice the extra parameter easily. Will take some
time.
2. If some users made their own function called stri_replace, this is
nothing that should be stopping from implementing it officially. In fact,
to fix it would be as easy as encapsuling the function declaration in
if(!function_exists('stri_replace')) {
function stri_replace($str = '') {
// ... user code
}
}
... which means acting on a centralized object - two lines of code after
an upgrade.
3. There is no reason to believe that this function was already used so
many times - as noted before, many have simply used regex. Look at this:
http://www.google.com/search?hl=enlr=ie=UTF-8oe=UTF-8q=stri_replace+-php.net
only 17 results. Of course, the use of this name might be much more, but
still - gives an idea of not such used user function.
Thus, my conclusion is that I doubt there is any gain of stability by
solving this issue with a parameter instead of an intuitive function.
--
Maxim Maletsky
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fw: [PHP - NOTES] note 28935 added to function.strftime
A user posted this note below. I do not know Catalan and cannot check it myself, however I decided not to ignore it and ask if anyone on the dev list could confirm that the user makes sense. If he does, then what? Maxim Maletsky [EMAIL PROTECTED] Forwarded by Maxim Maletsky [EMAIL PROTECTED] --- Original Message --- From:Iván@rack1.php.net To: [EMAIL PROTECTED] Date:28 Jan 2003 15:07:31 - Subject: [PHP-NOTES] note 28935 added to function.strftime PHP contains a bug in the Catalan (ca_ES) locale, as it has decembre for december, when it should be desembre. It also affects to the abbreviation dec, which should be des. Take this into account if you're coding locale-dependant for Catalan display settings... -- http://www.php.net/manual/en/function.strftime.php http://master.php.net/manage/user-notes.php?action=edit+28935 http://master.php.net/manage/user-notes.php?action=delete+28935 http://master.php.net/manage/user-notes.php?action=reject+28935 -- PHP Notes Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php - Original Message Ends -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fw: [PHP - NOTES] note 28935 added to function.strftime
Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 28 Jan 2003, Maxim Maletsky wrote: A user posted this note below. I do not know Catalan and cannot check it myself, however I decided not to ignore it and ask if anyone on the dev list could confirm that the user makes sense. If he does, then what? It wouldn't be a bug in PHP, but in the locales installed on his system I guess. Derick In fact, I did guess that. Anything we can do, though? At least, I think we should remove his note as it is unrelated to other locale's installations. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compiling php4activescript
There are a few libraries to include in the VC path. Find them on the net (I did it somehow myself and don't have a clue where from). -- Maxim Maletsky [EMAIL PROTECTED] On Mon, 27 Jan 2003 11:04:58 -0600 joe hansche [EMAIL PROTECTED] wrote: I just tried downloading the latest stable source snapshot ( http://snaps.php.net/php4-STABLE-200301271630.tar.gz at the time of posting ), and would like to compile the php4activescript library, and have been unsuccessful doing so. Looking at the Compile Log on the snapshots site, when compiling the ZendTS project, the site's log shows this: = Configuration: ZendTS - Win32 Release_TS_inline Performing Custom Build Step on .\zend_language_parser.y Performing Custom Build Step on .\zend_ini_parser.y zend_ini_parser.y:215.4-6: unrecognized escape: `\\0' Performing Custom Build Step on .\zend_language_scanner.l Performing Custom Build Step on .\zend_ini_scanner.l = But I am receiving this: = Configuration: ZendTS - Win32 Release_TS_inline Performing Custom Build Step on .\zend_language_parser.y 'bison' is not recognized as an internal or external command, operable program or batch file. Error executing c:\winnt\system32\cmd.exe. php.exe - 1 error(s), 0 warning(s) = I don't see what I have done differently, but obviously I didn't do something right :\ I am opening the win32\php4ts.dsw workspace file, and building the Release_TS_inline configuration. Is there anything else I need to configure in the project before it will compile? Or is there something else I need to download? All I really want to compile is the activescript library =[ Thanks a lot, Joe Hansche -- 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] If... Else.. I'm not getting it!
On Sat, 25 Jan 2003 10:12:56 +0100 Frank Keessen [EMAIL PROTECTED] wrote:
?php
$vname=$_POST['vname'];
if($submit) {
if you would have sent this message to [EMAIL PROTECTED] you
would be then instantly explained that $submit should have been
$_POST['submit'] in you code.
Please ask yoiur questions from now on to [EMAIL PROTECTED] -
this list is for developing PHP itself.
--
Maxim Maletsky
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] win32 builtin zlib
On Sat, 25 Jan 2003 18:59:37 +0100 Friedhelm Betz [EMAIL PROTECTED] wrote: Hi, I rewrote the part in the phpdoc manual about building on windows. zlib is builtin with 4.3.0 but the shipped Workspace for VC++ relies on a precompilded external zlib.lib. This is just what I run into a few hours ago trying to build php5 checkout with VC6. Therefore building on win32, out of the box, is not possible without downloading zlib sources, compiling them and either modify the workspace or figure out where to place zlib.lib. I had to download zlib.lib from w3c.org before building (here: http://dev.w3.org/cvsweb/libwww/Library/External/zlib.lib?sortby=file) Two points: 1.) In the released 4.3.0 source dist, the workspace points to ../../zlib, 2.) for example snapshot php4-STABLE-200301241430 points to ../../zlib/Release This is hard to document 1.) Are there future plans to include the zlib sources? probably the quickiest way, unless there are some problems with it, not really sure. 2.) Should users be advised to modify config.win32.h.in This would mean that every distribution would have to be modified beforeit is built for win32, not the best way IMO. 3.) Should users be advised to download zlib sources, building zlib.lib? The link above from w3c could be a good idea to point the user to. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] win32 builtin zlib
On Sat, 25 Jan 2003 23:39:36 +0100 Friedhelm Betz [EMAIL PROTECTED] wrote: [...] The link above from w3c could be a good idea to point the user to. Sure, but not a very smart solution IMHO ;-). It think it should be possible (and preferable) to bundle the required whatever files with win32build.zip ;-) I completely agree. I didn't know about the win32build.zip untill Zeev mentioned it. --- Maxim Maletsky [EMAIL PROTECTED] -- 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 tend to agree about the fact that in Open Source people often spend more time on politics rather than developing. Imagine a company office where the programmers get paid per hour while spending tons of time at the round table of a meeting room throwing into each other what they like better and why. In open source this happens a lot. But, at the same time, I think that closing a developers list does not really solve this issue. What about let the developers subscribe to the list in read-only mode so we all get updated on what's going on with PHP5. Or simply open the list completely and ignore the messages from those who you don't consider active PHP5 contributors. That would probably be more correct. -- Maxim Maletsky [EMAIL PROTECTED] Zeev Suraski [EMAIL PROTECTED] wrote... : Ok, I can't be bothered to fight a mailing list that was supposed to trim down endless discussions. I'm not the one that asked for the list, but I definitely supported it, as unlike most of the members on this list, I remember the pre-v4 days, and what kind of mountains we had to push in order to get it released half a year after it was ready. But as you said, no matter what valid reasons there are for having this list, we got to a situation where the fuzzy feeling will always outweigh the logic, and nobody will ever be able to persuade anybody otherwise. Whatever, let's end the list. Piotr - we'll call back mid 2005! Zeev At 19:31 23/01/2003, Dan Kalowsky wrote: Then discontinue it. End of discussion. This is an open source project, and I see little to no-advantage to it's use outside of creating a rather vile aftertaste in the mouths of those developers who are not invited. I've heard the arguments for the list, and I can only say they are valid reasons. But you're now making PHP a political project rather than a software project. Thanks. This is the sort of thing I don't want to have to deal with in my personal time. If you want a private list, take PHP out of the Open Source. If you want to cut down on the signal/noise ratio then moderate the list, but don't make it private and invite only. Zeev no matter how you see it or say it, the inclusion of members into a private mailing list is an exclusive ranking. You may claim otherwise, but all such claims by members of such group will more than likely be disregarded. On Thursday, January 23, 2003, at 11:38 AM, Rasmus Lerdorf wrote: I had nothing to do with that limited php5 list. I thought that was completely bogus myself and argued against it. --- Dan KalowskyCause fear is strong and love's http://www.deadmime.org/~dank for everyone, who isn't me. [EMAIL PROTECTED] - Burden In My Hand, [EMAIL PROTECTED] Soundgarden -- 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] roadmap of PHP - where? PHP 5 - when?
this email: [EMAIL PROTECTED] -- Maxim Maletsky [EMAIL PROTECTED] Brian Moon [EMAIL PROTECTED] wrote... : | Imagine a company office where the programmers get paid per hour while | spending tons of time at the round table of a meeting room throwing into | each other what they like better and why. In open source this happens a | lot. hey, who let you in to the dealnews dev room? Brian. dealnews.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Bug #17868: Multiple Includes
Michael D. Petersen [EMAIL PROTECTED] wrote... : I have been following PHP Bug #17868 for some time now (since upgrading to Red Hat 8.0 and Apache 2.0) with quite a bit of interest. This is the bug where multiple include statements don't work and only the first one gets parsed by PHP. Yes, only the first one gets parsed by all the subsequent get executed. This speeds the process up - what's the problem? -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request data filter
Rasmus Lerdorf [EMAIL PROTECTED] wrote... : this would likely have different security policies, but I do think a general hook is something that would be useful to all of PHP. A huge number of web apps today are extremely vulnerable to cross-site-scripting attacks. Occasionally developers remember to clean their data before displaying it, but for the most part they don't. Take half and hour and find yourself a collection of sites where you can enter data that is somehow displayed back to you. Shopping carts that ask for your name and phone number, or half of php.net's own stuff. Stick a bit of javascript in your phone number and watch. Just a little note here. The government project I am working on was attacked on New Year's night with XSS. Therefore, after we fixed it we decided to see what else is vulnerable oiut there. During the last two weeks I have played with a variaty of sites/portals/apps trying to hack them to see how far I can go. I ended up stealing the sessions of any installations, changing the passwords on main website and could see the list of passwords in pain user:pass format assigned as a cookie to anyone who sees my message on ***. Now, every *** was notified by me and, till they all will fix these, I will try not to reveal their names. What I think PHP should have is a function of a whole extension which parses the output in various ways cleaning XSS in it. Also, having such functionality in PHP would help it looking more secure as XSS affects any programming language and not namy have such protections. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php 4.3.0 ext/oci8 -- OCI_SHARED patch
Thies C. Arntzen [EMAIL PROTECTED] wrote... : I've modified the following files to allow for use of OCI_SHARED in ext/oci8 module if OCI8_VERSION = 8.1, which will provide memory savings by sharing connection and statement data (refer to http://www.csee.umbc.edu/help/oracle8/server.815/a67846/basics.htm; search for Shared Data Mode) between connections and statments respectively. I only have access to ext/oci8, so I can't check this in: Haven't really played with it, but the possiblity of some thread issues come into my mind. How have you tested it? configure main/php_config.h.in ext/oci8/config.m4 ext/oci8/oci8.ca there should be no nned to change anything outside ext/oci8/ to make this work. configure is auto-generated. just go ahead and commit the stuff to ext/oci8 It should only be within the ext/oci8/oci8.c thing, I presume. We are talking about a flag for OCI(?)Logon function, right? Note: I'm not familiar enough with the windows distribution to add the mod there. neither am i. Unless it requires loading something particular during the compilation, windows distribution shouldn't differ in any way. What I still keep wondering is the thread safety of it. Also, since this is a = 8.1 thingie, you'd need to see whether it compiles and doesnt crash on lower versions of OCI (is OCI_SHARED defined in all OCIs? You need to control it for BC). -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Single quotes VS. Double quotes
Brian Moon [EMAIL PROTECTED] wrote... : This is of really low importance, but I found it interesting. A new guy on the Phorum dev team decided to convert all double quotes to single quotes for speed in CVS. The common assumption is that single quotes are faster than double quotes. However, I am of the mind set of using double always as it creates less headaches later to add a variable to the string. In an attempt to show him the marginal savings of this, I did some benchmarks. The results were confusing. $var=This is test number $x; was really slow. but, $var=This is test number .$x; and $var='This is test number '.$x; we basically identical. Andi, Zeev, if you want waste some energy on exanding on why this is and if anything in ZE2 will change it I would find it a good read. Actually, I've benchmarked this long time ago on v4.0.x and my results were completely meaningless. Don't remember right now, but I guess I ended up believing that both parsing's (a dot in single and a variable in double) were having their own tiny delays with minimal difference. Only non-concatenated strings were resulting faster for some miserable particle of a millisecond with single quotes (what, seems to be optimized/normalized in PHP v4.3.0). Whatever the result is, even with thousands loops, the speed gained by optimizing concatenations will generally be times less than the overall execution of the script that uses so many strings - it's proportional. IMHO, the only reasons to care about this are the code readability and coding standards within a team. If that makes sense to be so much restrictive. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OCI patch
Cool.
From the first sight it looks good, but I am gonna have to test it
through various platforms - I have access to multilingual environments here.
I tend to be a bit concerned changing the session type, but it seems
alright for me so far. Let me play with it and let you know if it can go
up the way it is.
Any comments, Thies?
--
Maxim Maletsky
[EMAIL PROTECTED]
Abdul-Kareem Abo-Namous [EMAIL PROTECTED] wrote... :
sure, here's thecode, diff'd against the latest cvs (from today). hope it's
ok!
oci8_charsets_oci8c.diff is for oci8.c
oci8_charsets_configm4.diff for config.m4 and guess what
oci8_charsets_phpoci8h.diff is for ;-)))
cheers,
Abdul
- Original Message -
From: Maxim Maletsky [EMAIL PROTECTED]
To: Abdul-Kareem Abo-Namous [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, November 28, 2002 1:27 PM
Subject: Re: [PHP-DEV] OCI patch
Thies was on it. But, I think he is pretty busy right now. Resubmit it
to me and I will look instead of him. Meanwhile, if Thies has time he
will spare the light on the issue.
--
Maxim Maletsky
[EMAIL PROTECTED]
Abdul-Kareem Abo-Namous [EMAIL PROTECTED] wrote... :
hi everyone
what happened to the patch i submitted? is it of such bad quality? ;-)
maybe someone can tell me more..? :-)
thanks,
Abdul
- Original Message -
From: [EMAIL PROTECTED]
To: MaximMaletsky [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, October 17, 2002 12:55 PM
Subject: Re: Re: [PHP-DEV] OCI patch
Ok, I've attached a pretty ok version. I had to update the config.m4
to
inculde a HAVE_OCI9 define, but since I'm not really good in this kind
of
thing, buildconf now reports a warning
autoheader: No template for symbol `HAVE_OCI9'
don't know what to do about it. otherwise everything compiles and runs
smoothly, so I hope you'll enjoy :-).
Abdul
Maxim Maletsky [EMAIL PROTECTED] schrieb am 17.10.02 12:45:57:
OK, then.
--
Maxim Maletsky
[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote... :
Thies, Maxim, if you could hang on for a few hours I'll be back
with a
few ideas and a cleaned up version of the patches + a switch for oracle
9+
to enable the new nls functions.
Abdul
--
--
--- oci8.c Wed Oct 9 16:55:16 2002
+++ oci8.c Thu Oct 17 13:32:09 2002
@@ -20,7 +20,7 @@
+--+
*/
-/* $Id: oci8.c,v 1.176 2002/09/12 09:48:02 thies Exp $ */
+/* $Id: oci8.c,v 1.175 2002/08/20 07:26:50 edink Exp $ */
/* TODO list:
*
@@ -199,7 +199,7 @@
static oci_server *_oci_open_server(char *dbname,int persistent);
static void _oci_close_server(oci_server *server);
-static oci_session *_oci_open_session(oci_server* server,char
*username,char *password,int persistent,int exclusive);
+static oci_session *_oci_open_session(oci_server* server,char
*username,char *password,int persistent,int exclusive,char *charset);
static void _oci_close_session(oci_session *session);
static sb4 oci_bind_in_callback(dvoid *, OCIBind *, ub4, ub4, dvoid
**,
ub4 *, ub1 *, dvoid **);
@@ -451,7 +451,7 @@
OCI_DEFAULT,
0,
NULL));
-
+
CALL_OCI(OCIHandleAlloc(
OCI(pEnv),
(dvoid **)OCI(pError),
@@ -631,7 +631,7 @@
php_info_print_table_start();
php_info_print_table_row(2, OCI8 Support, enabled);
- php_info_print_table_row(2, Revision, $Revision: 1.176 $);
+ php_info_print_table_row(2, Revision, $Revision: 1.175 $);
#ifndef PHP_WIN32
php_info_print_table_row(2, Oracle Version, PHP_OCI8_VERSION );
php_info_print_table_row(2, Compile-time ORACLE_HOME,
PHP_OCI8_DIR );
@@ -1158,9 +1158,9 @@
php_error(E_WARNING, Unknown descriptor type %d.,Z_TYPE_P(descr));
return 0;
}
-
+
CALL_OCI_RETURN(OCI(error), OCIDescriptorAlloc(
- OCI(pEnv),
+ connection-session-pEnv,
(dvoid*)(descr-ocidescr),
Z_TYPE_P(descr),
(size_t) 0,
@@ -1244,7 +1244,7 @@
oci_debug(_oci_make_zval: %16s,retlen = %4d,retlen4 =
%d,storage_size4
= %4d,indicator %4d, retcode = %4d,
column-name,column-retlen,column-retlen4,column-storage_size4,column-in
dicator,column-retcode);
- if ((! statement-has_data) || (column-indicator == -1)) { /*
column is
NULL or statment has no current data */
+ if (column-indicator == -1) { /* column is NULL */
ZVAL_NULL(value);
return 0;
}
@@ -1351,14 +1351,14 @@
statement = ecalloc(1,sizeof(oci_statement));
CALL_OCI(OCIHandleAlloc
Re: [PHP-DEV] OCI patch
Thies was on it. But, I think he is pretty busy right now. Resubmit it
to me and I will look instead of him. Meanwhile, if Thies has time he
will spare the light on the issue.
--
Maxim Maletsky
[EMAIL PROTECTED]
Abdul-Kareem Abo-Namous [EMAIL PROTECTED] wrote... :
hi everyone
what happened to the patch i submitted? is it of such bad quality? ;-)
maybe someone can tell me more..? :-)
thanks,
Abdul
- Original Message -
From: [EMAIL PROTECTED]
To: MaximMaletsky [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, October 17, 2002 12:55 PM
Subject: Re: Re: [PHP-DEV] OCI patch
Ok, I've attached a pretty ok version. I had to update the config.m4 to
inculde a HAVE_OCI9 define, but since I'm not really good in this kind of
thing, buildconf now reports a warning
autoheader: No template for symbol `HAVE_OCI9'
don't know what to do about it. otherwise everything compiles and runs
smoothly, so I hope you'll enjoy :-).
Abdul
Maxim Maletsky [EMAIL PROTECTED] schrieb am 17.10.02 12:45:57:
OK, then.
--
Maxim Maletsky
[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote... :
Thies, Maxim, if you could hang on for a few hours I'll be back with a
few ideas and a cleaned up version of the patches + a switch for oracle 9+
to enable the new nls functions.
Abdul
--- oci8.c Wed Oct 9 16:55:16 2002
+++ oci8.c Thu Oct 17 13:32:09 2002
@@ -20,7 +20,7 @@
+--+
*/
-/* $Id: oci8.c,v 1.176 2002/09/12 09:48:02 thies Exp $ */
+/* $Id: oci8.c,v 1.175 2002/08/20 07:26:50 edink Exp $ */
/* TODO list:
*
@@ -199,7 +199,7 @@
static oci_server *_oci_open_server(char *dbname,int persistent);
static void _oci_close_server(oci_server *server);
-static oci_session *_oci_open_session(oci_server* server,char
*username,char *password,int persistent,int exclusive);
+static oci_session *_oci_open_session(oci_server* server,char
*username,char *password,int persistent,int exclusive,char *charset);
static void _oci_close_session(oci_session *session);
static sb4 oci_bind_in_callback(dvoid *, OCIBind *, ub4, ub4, dvoid **,
ub4 *, ub1 *, dvoid **);
@@ -451,7 +451,7 @@
OCI_DEFAULT,
0,
NULL));
-
+
CALL_OCI(OCIHandleAlloc(
OCI(pEnv),
(dvoid **)OCI(pError),
@@ -631,7 +631,7 @@
php_info_print_table_start();
php_info_print_table_row(2, OCI8 Support, enabled);
- php_info_print_table_row(2, Revision, $Revision: 1.176 $);
+ php_info_print_table_row(2, Revision, $Revision: 1.175 $);
#ifndef PHP_WIN32
php_info_print_table_row(2, Oracle Version, PHP_OCI8_VERSION );
php_info_print_table_row(2, Compile-time ORACLE_HOME, PHP_OCI8_DIR );
@@ -1158,9 +1158,9 @@
php_error(E_WARNING, Unknown descriptor type %d.,Z_TYPE_P(descr));
return 0;
}
-
+
CALL_OCI_RETURN(OCI(error), OCIDescriptorAlloc(
- OCI(pEnv),
+ connection-session-pEnv,
(dvoid*)(descr-ocidescr),
Z_TYPE_P(descr),
(size_t) 0,
@@ -1244,7 +1244,7 @@
oci_debug(_oci_make_zval: %16s,retlen = %4d,retlen4 = %d,storage_size4
= %4d,indicator %4d, retcode = %4d,
column-name,column-retlen,column-retlen4,column-storage_size4,column-in
dicator,column-retcode);
- if ((! statement-has_data) || (column-indicator == -1)) { /* column is
NULL or statment has no current data */
+ if (column-indicator == -1) { /* column is NULL */
ZVAL_NULL(value);
return 0;
}
@@ -1351,14 +1351,14 @@
statement = ecalloc(1,sizeof(oci_statement));
CALL_OCI(OCIHandleAlloc(
- OCI(pEnv),
+ connection-session-pEnv,
(dvoid **)statement-pStmt,
OCI_HTYPE_STMT,
0,
NULL));
CALL_OCI(OCIHandleAlloc(
- OCI(pEnv),
+ connection-session-pEnv,
(dvoid **)statement-pError,
OCI_HTYPE_ERROR,
0,
@@ -1392,9 +1392,7 @@
if (query) {
statement-last_query = estrdup(query);
}
-
statement-conn = connection;
- statement-has_data = 0;
statement-id = zend_list_insert(statement,le_stmt);
@@ -1771,7 +1769,6 @@
}
statement-error = 0; /* OCI_NO_DATA is NO error for us!!! */
- statement-has_data = 0;
return 0;
}
@@ -1831,16 +1828,12 @@
_oci_make_zval(column-define-zval,statement,column,OCIFetch,0
TSRMLS_CC);
}
- statement-has_data = 1;
-
return 1;
}
oci_error(statement-pError, func, statement-error);
oci_handle_error(statement-conn, statement-error);
- statement-has_data = 0;
-
return 0;
}
@@ -1855,8 +1848,8 @@
ub4 siz = 0;
ub4 readlen = 0;
char *buf;
+
TSRMLS_FETCH();
-
*loblen = 0;
if (Z_TYPE_P(mydescr) == OCI_DTYPE_FILE) {
@@ -1888,17 +1881,17 @@
buf = emalloc(readlen + 1);
while
Re: [PHP-DEV] PHP Beginner
1. This is not the right list for asking the question - join the other mailing list at [EMAIL PROTECTED] which is right for that. 2. You already answered yourself: PHP Beginner (www.phpbeginner.com). If that does not satisfy you try the other sites within the links section of www.php.net -- Maxim Maletsky [EMAIL PROTECTED] Mahamadou ZERBO [EMAIL PROTECTED] wrote... : Hi, I'm a beginner in PHP. I'm looking for ressources (templates, samples, ...) which can help me. Where can I find it. Thanks -- 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
Just an update, I have made a 117m thread on PHP-IT wondering what Italian users think of porting error messages to their language. Apparently, users seemed to be already used to English errors and this idea wasn't completely accepted by everyone (some people agreed, though). Objections to it were similar to what we had here. However, error codes were very well welcomed because of several reasons including searching the docs and for web help, eventual ability catching/recognizing errors run-time, possibility of triggering core errors, etc. Shall we still consider introducing error codes to PHP? IMO, it does not represent any enormous maintenance increase while has some positive points. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Ilia A. [EMAIL PROTECTED] wrote... : On November 28, 2002 12:56 pm, Maxim Maletsky wrote: Shall we still consider introducing error codes to PHP? IMO, it does not represent any enormous maintenance increase while has some positive points. Do you have an effecient manner in which to implement the introduction of error codes? I believe that it could be done gradually like the way docref was introduced. It might also be an alternative function of something similar. One important things will remain is the naming convention for errors - allocating the numbers in a logical ways. In my first thoughts I'd propose this format: PHP1234 where 12 means the extension and 34 is the error. This way, one could check things by parsing error strings or by calling some built in function which returns the extension name for the error, for instance. I think there could be many utilities for it. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Ilia A. [EMAIL PROTECTED] wrote... : On November 25, 2002 09:22 pm, Maxim Maletsky wrote: 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 If my co-workers and I cannot communicate in the same language we will probably go our separate ways within a week. Afterall, how can we work together if we don't have a common language between us. By the way, could you please advise by how much I will need to increase the power of my server(s) to maintain the same level of performance? nah... not really. I, at work, have my OS, keyboard and everything else set in en-us, while everyone else in Italian. Of course - this is the Ministry of Economy and Finance of Italy :) This is not the point yet. A team sets the language in php.ini, who needs it different can alter it. XML is what I think would be the best for the whole thing of managing errors. It could be integrated into the docs, parallelly translated into multiple language, adding extra flexibility and features growth. This can be also useful for modifying errors for users themselves if they wish to. It would probably flexible solution, but terribly complex. Why? Having to only pass numbers in error and one XML file to edit is not *that* complex. Whole PHP internals is complex itself, if for that. Let's consider the process, a developer decides to add sanity check with a warning. They write the code and now need to modify an XML file with an error message, reference the XML entry from their code. Commit all this to CVS and hope they did not messup. Yup. Also, how and when XML parsing will be merged inserted into C code? Won't you be adding an XML parser decency to PHP? This is something to have discussed. I am definitely not the best guy to know what is better for this case. My only point is this: ERROR STRINGS **OUT** OF THE C CODE! Then, whether we use XML or not is another topic. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
John Coggeshall [EMAIL PROTECTED] wrote... : 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 code is a bit of an integer code, not constants. I wouldn't say its a bad idea, but might be difficult to start. +0.5 for constants. 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. I agree on it, especially, when you use DBs and other extension that have their own error reportings. At first, it would seem like how do you translate those? but in reality it would create a better understanding of the error. -- Maxim Maletsky [EMAIL PROTECTED] 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
Re: [PHP-DEV] [PATCH] Redirect on Error
And, most importantly, what the hell doi I care of losing 0.12 secs for a Fatal Error dysplay? -- Maxim Maletsky [EMAIL PROTECTED] George Schlossnagle [EMAIL PROTECTED] wrote... : By the way, could you please advise by how much I will need to increase the power of my server(s) to maintain the same level of performance? Why would this need to kill your performance if you're not throwing errors? -- 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
Well, yes, if it is not XML it can still work. A thought here is - to connect built-in errors to the documentation, which is where XML would help. -- Maxim Maletsky [EMAIL PROTECTED] Shane Caraveo [EMAIL PROTECTED] wrote... : 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 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. 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] Error Codes, Langs, etc
Again, XML was my throw to this thread. I intuitively thought of XML because it would help connecting the PHP error reporting to the official documentaion. Don't you think it would be helpful? Of course there are work-arounds for that too. -- Maxim Maletsky [EMAIL PROTECTED] John Coggeshall [EMAIL PROTECTED] wrote... : 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
It can be parsed run time at a small cost, which in this case of errors, as many here agree, can be used. -- Maxim Maletsky [EMAIL PROTECTED] John Coggeshall [EMAIL PROTECTED] wrote... : 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
[EMAIL PROTECTED] (Marcus Börger) wrote... : WE can use cdb (constant databse) which is very fast and we have the code bundled now. The documnet group might want work on error messages XML based. We may write a script wich will generate a cdb file from that XML file. I thought af it - I think this can be one of the best solutions. However i would VERY MUCH appreciate having english error messages hard coded into the source. AND those i18n error messages only activateable by an ini setting. I disagree. Leaving english comments in C code is obvious, but the errors that get printed to user's screens should be out of C code. I know, it will hassle some lazy us while coding, but nevertheless, it will help documentation ppl to translate errors easlier without knowing how extensions are set :) I also think that error messages will be tranlated much shorter as they inspire more translators to work on. They's cool :) -- Maxim Maletsky [EMAIL PROTECTED] -- 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 am on. Here, without a patch sample, nothing will roll. Anyone joins? -- Maxim Maletsky [EMAIL PROTECTED] John Coggeshall [EMAIL PROTECTED] wrote... : 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Derick Rethans [EMAIL PROTECTED] wrote... : IMO it doesn't improve anything; people who don't want to understand undefined function also dont want to understand undefiniertes Funktion, it's all arabic techo-speak for them anyway. Then how does it help if you explain either undefined function or undefiniertes Funktion to them? Derick It is just as true. But, there is also another side of the coin - having errors internationalized will sound like PHP-translated not only DOCS translated - an extra tool to tell that Open Source cares of usability. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
XML or not XML is not yet the question. It can be something else having its own XML version. What is the browsercap then? Somthing of that nature for core PHP, but creating that file from a Documentation XML error file. -- Maxim Maletsky [EMAIL PROTECTED] Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: Yes, this is the way to go. but, I would still prefer to have to pass it only a code like: php_error(255, data, data, data); where in an XML structure we can predefine everything else. XML?!? More bloat is hardly needed, thank you! Not to forget that it's a hell to maintain for PHP extension developers, like me. 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] Error Codes, Langs, etc
Andrey Hristov [EMAIL PROTECTED] wrote... : I've seen a big poster in my local Fullbright foundation represantive. It says something like : One of every four people on the earth knows some English. Why does Billy localize M$ windows then? And, most importantly, what would he sell without doing it? Remember, his users know basic IT english too. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
[EMAIL PROTECTED] (Marcus Börger) wrote... : At 10:14 26.11.2002, Derick Rethans wrote: On Tue, 26 Nov 2002, John Coggeshall wrote: 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. Waste of time Derick Hi Jon, maybe Derick is right but here's for the error codes themselves: You could try to add only names or numbers as error codes. The first you must change is all php_error() calls to php_error_docref() calls. After that you will have to add those message codes and remeber no double entry. php_error_docref now uses internal php_error_cb(). Here you will have to find a solution for displaying your codes. Problems: Some php_error() calls are called from functions which do not have a TSRMLS_C(C) parameter. Here you must add TSRMLS_FETCH(). When all this is working you can try and work on i18n...but that'l be far away. Or someone else has a faster solution Something like that. We can do lots of tests first for cb etc. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
I apologize for shouting, didn't mean to be offensive. What I want to say is that error messages are string and should, IMHO, be reference instead of hardcoded in the C code. -- Maxim Maletsky [EMAIL PROTECTED] Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: Ilia A. [EMAIL PROTECTED] wrote... : If my co-workers and I cannot communicate in the same language we will probably go our separate ways within a week. Afterall, how can we work together if we don't have a common language between us. By the way, could you please advise by how much I will need to increase the power of my server(s) to maintain the same level of performance? nah... not really. I, at work, have my OS, keyboard and everything else set in en-us, while everyone else in Italian. Of course - this is the Ministry of Economy and Finance of Italy :) This is not the point yet. A team sets the language in php.ini, who needs it different can alter it. Let's consider the process, a developer decides to add sanity check with a warning. They write the code and now need to modify an XML file with an error message, reference the XML entry from their code. Commit all this to CVS and hope they did not messup. Yup. I don't think so. Also, how and when XML parsing will be merged inserted into C code? Won't you be adding an XML parser decency to PHP? This is something to have discussed. I am definitely not the best guy to know what is better for this case. My only point is this: ERROR STRINGS **OUT** OF THE C CODE! NO WAY. And don't shout on the mailinglist. 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
Derick, that's the price of usability. Open Source always suffered from that, and forever will if the usability will not be considered as one of the main benefits, especially for a programming language as PHP. I agree on 110% that it will be harder to maintain the code. I myself will never use any non-english errors in my PHP setups and will always spend precious minutes grepping for error code. But, this will benefit the whole project. It is not a stupid idea - it is usability. -- Maxim Maletsky [EMAIL PROTECTED] Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: [EMAIL PROTECTED] (Marcus Börger) wrote... : However i would VERY MUCH appreciate having english error messages hard coded into the source. AND those i18n error messages only activateable by an ini setting. I disagree. Leaving english comments in C code is obvious, but the errors that get printed to user's screens should be out of C code. No, I won't want the C code less maintainable and have to search for error codes all the time. I know, it will hassle some lazy us while coding, but nevertheless, it will help documentation ppl to translate errors easlier without knowing how extensions are set :) It's giving coders more work, work which looks like documenting; and we all know that coders dont like to document. And being lazy has nothing to do with it, it's just all practical. Dont forget that most coders work on PHP because they _need_ the function they are working on in their jobs. 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
Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : IMO it doesn't improve anything; people who don't want to understand undefined function also dont want to understand undefiniertes Funktion, it's all arabic techo-speak for them anyway. Then how does it help if you explain either undefined function or undefiniertes Funktion to them? It is just as true. But, there is also another side of the coin - having errors internationalized will sound like PHP-translated not only DOCS translated - an extra tool to tell that Open Source cares of usability. I don't care what others think about the usability, I only know that adding these localized things brings more work for me when working on PHP. That sounds selfish of us, Derick. PHP is an Open Source and has to compete with commercial applications where this is being one of the highest priorities, often even higher than overall performance. PHP has already accomplished remarkable performance and efficiency values, it also has done good job in usability. Only because coders will have to open an extra file when looking for an error string, should not mean that this programming language musts abandon these values. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: This can be easily avoided. When I have to report an Oracle error in Italian on an English page, I simply type the error code. We need to introduce error codes in PHP, that would really solve the trouble. and it would make us enter the maintainers-hell It's not really that much of hell. just adding an English comment like: /* Fail if this data no good */ php_error(354, bad_data); Huh, what is code 354? What is the exact message? Comments dont help, and then you need to update the message at two locations! Woohoo! even more work. Can save the whole thing. Naming conventions and coding style used commonly can be the solution. Yeah, and you just tell us what to do. I rather propose. And, it seems to interest many on the list. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Zeev Suraski [EMAIL PROTECTED] wrote... : They should definitely be in the C code. Look at gettext as a pretty good example. Taking them out is seriously inferior to having them in - it makes maintenance much tougher, and PHP itself less robust. Suddenly, if you don't have some external file, errors would show up as stupid error numbers. What are we looking forward to? Having something like Error 29871 and then having to look up error 29871 and seeing it means Unable to find external error message database? I think it can be stable enough since once you add an error in code you would add it to the message database. No, please. About the topic of internationalized error messages in general - I think the cons outweigh the pros. If we were, however, to ever internationalize them - it would have to be optional, and with the full hardcoded error messages inside the code remaining intact. It, of course, would be optional. Set by local setting in php.ini or runtime. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Sascha Schumann [EMAIL PROTECTED] wrote... : Since error code domains need to be centrally assigned so that they don't overlap, I'd suggest to simply set up a central data repository with assigned error code domains and a per-domain set of mappings. The error codes should be easily recognizable (%foo-123%), so that e.g. the bugs.php.net parser can present the English error message automatically. There is really no need for XML at this point in time. What if we were to store more data for the same error which is still mapped the same. That is where I thought of XML, which is not the one to use here, because it would allow more properties per error. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Zeev Suraski [EMAIL PROTECTED] wrote... : At 13:11 26/11/2002, Maxim Maletsky wrote: That sounds selfish of us, Derick. No, it doesn't. If we're going to attempt at doing something that has a high risk of screwing up PHP and slow down its QA and support, we should be mature enough to know our limits. If we don't, the ones that would suffer eventually would actually be the users. Knowing your limits is a virtue, and taking unnecessary risks, while may seem noble, will often lead to much worse results. Let's say, as a user, I get this error for not defining a variable: Notice: Undefined variable: var in E:\CVS\PHP\php4\Release_TS\tests\release.php on line 20 What if that error would be: Notice (235): Undefined variable: var in E:\CVS\PHP\php4\Release_TS\tests\release.php on line 20 Docref... FAQ... etc ... where 1. Underfined Variable is translated to ohter languages. In this example it is just a simple english, but there are other, more complex ones. 2. 235 is the error code. One can type it in google: Notice (235) and get lots of info. Still possible even now, by typing error message instead. What i love about Oracle is its error code format: ORA-25688 - you type it anywhere and get find tons of solutions instantly. 3. Docref and FAQ links to a documentaion and FAQ pages on php.net where there would be descriptions of errors and relevant solutions. Very, very handy. It is what Marcus was doing, but, he needed to add new functions to it, referencing by code will be more flexible as you could edit the storage only. 4. User could use and extend this error reporting techniques on his own. These are just my thoughts of what I would see usable about it all. IMO, the current error reporting will be someday dedesigned anyway - it does need a redesign. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Concrete suggestion re: i18n messages
Sascha Schumann [EMAIL PROTECTED] wrote... : A possible implementation would look like this: A new ini setting is added. php.error_lang A new function is provided. php_error_ex(int type, const char *err_code, const char *fmt, ...); The function tries to lookup the err_code key in php-php.error_lang.cat. If it exists, the value will be used instead of the format fmt. The control is then passed to php_verror(). That sounds like 30-50 additional LOC to me. No bloat in sight. The program which generates the .cat files (gen-cat) will ensure that the error code is prepended to the format message. That could be a simple C file with another 50 LOC, parsing input files of the form file: file line | line line: ERROR-CODE MSG Each extension can maintain its own file (e.g. cat.session.nl for the NL version of the session error messages). During .cat build-time, a single per-language file is generated and fed through gen-cat. The result can then be used by PHP. Per-extension thingies sounds nice to me - would make it easier getting the patches with these errors from users. But, it should be in it own directories, thought - having 20 .cat files along your .c files would be boring. I'd say: ext/session/errors/en.cat etc... Also, a logic to always use english error as default. There, simple and straight-forward. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Let me do the same for Italian -- Maxim Maletsky [EMAIL PROTECTED] Daniel Lorch [EMAIL PROTECTED] wrote... : hi, I fired off a mail to PHP-DE asking the average PHP user about localization of error messages. My mail might be a bit biased, so if you have something to say, do it now. I will summarize the results here. Ok, here's the summary of my NON-representative poll to PHP-De about localization of error messages in PHP: Pro: 1 Contra: 8 Some thoughts that were brought up: - PHP developers should not waste their time on localization, instead focus on increasing verbosity of existing error messages (a meaningless error message in english will be meaningless in every other language as well). - The english used in error messages is only a small subset of the whole language (come on, everyone knows enough MTV-english to understand error messages). However, other countries might have more problems as their languages don't come from the same language family. -daniel -- 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] Concrete suggestion re: i18n messages
Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Sascha Schumann wrote: ext/session/errors/en.cat Sounds good. No, it does not to me. It means that translators need to have access to the php4/ cvs module, which is something I'm very against. I agree on this fact, though. Can it be somehow built from phpdoc module? -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Redirect on Error (not localisation)
John Coggeshall [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] [PATCH] Redirect on Error
On 27 Nov 2002 00:54:59 +0100 Stig S. Bakken [EMAIL PROTECTED] wrote: On Tue, 2002-11-26 at 14:57, Andrei Zmievski wrote: On Tue, 26 Nov 2002, Edin Kadribasic wrote: On Tue, 26 Nov 2002, Maxim Maletsky wrote: I rather propose. And, it seems to interest many on the list. Don't forget that there seem to be many who strongly opose your suggestion. Myself included. -1 on localized error messages +1 on errno-style error codes (for PHP 5) - Stig Yeah, let's then vote: +0.5 localizing (oh well, got convinced it won't happen for now) +1.0 error codes --- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
On 27 Nov 2002 01:27:18 +0100 Stig S. Bakken [EMAIL PROTECTED] wrote: If someone wants help on php-general and their error message is in Urdu, then too bad. Companies like IBM and Oracle has solved this problem by introducing more complex error codes (such as 0123-456 File not found), which is an absolute must if one does go in this direction, or the poor Urdu-speaking guy won't be able to find people who can help him. Right! I was mentioning that - no translation or any kind of other flexibility on errors is possible if there is no solid error code logic accomplished. These would help really a lot. Even if messges will never be localized, error codes will still be helpful a whole bunch. But the task of maintaining such a registry, and avoiding that it degenerates into a chaotic mess, requires an amount of collective self-discipline that I simply don't think a big project like PHP can muster. I doubt it adds all that much of complexity as many think. of course, it requires going through them all over and then, when coding, looking up for the code conventions. But, IMO, this all is not such a disaster to do. It can help more. Let's try being realistic, and focus on the quick wins first, such as good error codes. Amen! That is where i was leading and got misleading :) --- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On 27 Nov 2002 01:49:54 +0100 Stig S. Bakken [EMAIL PROTECTED] wrote: On Tue, 2002-11-26 at 12:11, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : IMO it doesn't improve anything; people who don't want to understand undefined function also dont want to understand undefiniertes Funktion, it's all arabic techo-speak for them anyway. Then how does it help if you explain either undefined function or undefiniertes Funktion to them? It is just as true. But, there is also another side of the coin - having errors internationalized will sound like PHP-translated not only DOCS translated - an extra tool to tell that Open Source cares of usability. I don't care what others think about the usability, I only know that adding these localized things brings more work for me when working on PHP. That sounds selfish of us, Derick. How on earth can you say that? Derick has received an _throphy_ for spending his spare time on the painful process of managing PHP releases, he knows what he is talking about, and it is not a selfish opinion. I am in no way insulting Derick for his great work. Caring of usability is what I also think of an importance. Open Source is very often critized for that - we should care, IMO. Maintenance overhead hurts PHP. And our maint.overhead curve is going up. We should strive to _reduce_ that overhead, not increase it. That way php-dev will be more productive and give even the our users what they really need: a (continously) solid product. As you said - PHP is a big project and maintainance overhead hurts it. Just this is not the limit, I think - we can add such innovations as error codes on upcoming major releases. Unless a common agreement isn't reached. --- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Oracle 8.1.7
Guys, I'm hassling on a quite mysterious and not documented (but pretty useful) function for OCI8 called OCIServerRelease() which would return you the Oracle Server release integer for compatibility comparisons. Because there are no official docs anywhere about this function (WTF? google only returns 2 pages both of which is Ruby's OCI8 module docs), I was unable to track it's BC, although tests for me worked just fine. So, what I am trying to do instead is to test this OCI call on lower Oracle versions. So far it worked smoothly for me on three Oracle machines I currently have access to: * Oracle9i Release 9.0.2.0.1 * Oracle9i Release 9.0.1.1.1 * Oracle8i Enterprise Edition Release 8.1.7.3.0 Both with Client 9. Does anyone have an access to any lower versions of Oracle Servers and Oracle Clients to compile and test from CVS? Especially Client. If so, please let me know. Cheers, -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Oracle 8.1.7
Perhaps, but not all is that easy - OCI uses its own definitions for every function, and so far I have not found what defined this one. Also because there is no documentation about this call whatsoever, I am a little lost understanding it well - I only see how it is used with several libraries. --- Maxim Maletsky [EMAIL PROTECTED] On Tue, 26 Nov 2002 01:09:13 +0200 (EET) Jani Taskinen [EMAIL PROTECTED] wrote: Can't you just check if it exists and add some #ifdef's in the code? --Jani On Mon, 25 Nov 2002, Maxim Maletsky wrote: Guys, I'm hassling on a quite mysterious and not documented (but pretty useful) function for OCI8 called OCIServerRelease() which would return you the Oracle Server release integer for compatibility comparisons. Because there are no official docs anywhere about this function (WTF? google only returns 2 pages both of which is Ruby's OCI8 module docs), I was unable to track it's BC, although tests for me worked just fine. So, what I am trying to do instead is to test this OCI call on lower Oracle versions. So far it worked smoothly for me on three Oracle machines I currently have access to: * Oracle9i Release 9.0.2.0.1 * Oracle9i Release 9.0.1.1.1 * Oracle8i Enterprise Edition Release 8.1.7.3.0 Both with Client 9. Does anyone have an access to any lower versions of Oracle Servers and Oracle Clients to compile and test from CVS? Especially Client. If so, please let me know. Cheers, -- Maxim Maletsky [EMAIL PROTECTED] -- - For Sale! - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Oracle 8.1.7
That sounds very good. What version is your oracle client? --- Maxim Maletsky [EMAIL PROTECTED] On Tue, 26 Nov 2002 00:03:36 +0100 Edin Kadribasic [EMAIL PROTECTED] wrote: Does anyone have an access to any lower versions of Oracle Servers and Oracle Clients to compile and test from CVS? Especially Client. If so, please let me know. I've got access to Oracle 8.0.5 on Linux. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Oracle 8.1.7
ok.
here is the patch as txt. It applies to the latest CVS of the file. But,
in any case - there is only that very function that is not documented
anywhere, and I wonder whether it works.
to test it, just run this:
?php
$conn = OCILogon('user', 'pass', 'listener');
echo \nServer version: . OCIServerVersion($conn);
echo \nServer release: . OCIServerRelease($conn);
/*
you should expect something like that. Important part is the last line - release code
Server version: Oracle9i Enterprise Edition Release 9.0.1.1.0 - Production
With the Partitioning option
JServer Release 9.0.1.0.0 - Production
Server release: 150999296
*/
?
let me know.
---
Maxim Maletsky
[EMAIL PROTECTED]
On Tue, 26 Nov 2002 00:18:17 +0100 Edin Kadribasic [EMAIL PROTECTED] wrote:
That sounds very good. What version is your oracle client?
The client is on the same Linux box, so the version is still 8.0.5.
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Oracle 8.1.7
That's what I thought... Gonna have now to look for the definition of
the function to avoid the compiling failure. Many thanks, man!
---
Maxim Maletsky
[EMAIL PROTECTED]
On Tue, 26 Nov 2002 01:18:15 +0100 Edin Kadribasic [EMAIL PROTECTED] wrote:
No go. OCIServerRelease seems not to be supported in Oracle 8.0:
ext/oci8/oci8.o: In function `zif_ociserverrelease':
ext/oci8/oci8.c:4551: undefined reference to `OCIServerRelease'
Edin
- Original Message -
From: Maxim Maletsky [EMAIL PROTECTED]
To: Edin Kadribasic [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, November 26, 2002 12:46 AM
Subject: Re: [PHP-DEV] Oracle 8.1.7
ok.
here is the patch as txt. It applies to the latest CVS of the file. But,
in any case - there is only that very function that is not documented
anywhere, and I wonder whether it works.
to test it, just run this:
?php
$conn = OCILogon('user', 'pass', 'listener');
echo \nServer version: . OCIServerVersion($conn);
echo \nServer release: . OCIServerRelease($conn);
/*
you should expect something like that. Important part is the last line -
release code
Server version: Oracle9i Enterprise Edition Release 9.0.1.1.0 - Production
With the Partitioning option
JServer Release 9.0.1.0.0 - Production
Server release: 150999296
*/
?
let me know.
---
Maxim Maletsky
[EMAIL PROTECTED]
On Tue, 26 Nov 2002 00:18:17 +0100 Edin Kadribasic [EMAIL PROTECTED]
wrote:
That sounds very good. What version is your oracle client?
The client is on the same Linux box, so the version is still 8.0.5.
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Mon, 25 Nov 2002 15:21:06 -0500 Sterling Hughes [EMAIL PROTECTED] wrote: Educate users to speak the base amount of english required, I18N'ing the language is just going to lead to headaches from a user perspective (incorrect translations, slower performance, translations for english speakers) and a developer perspective (having to lookup tokens, understanding another language, getting bug reports with horrible error messages). That is why we have error codes :) Are you saying that Oracle is wrong giving the ability to localize even SQL error messages? These does not have to ever happen, but in my Italian team the guys are simply rocking - they find out instantly what they did wrong to a query because it is in their language. Sets the language to what you speak and you will develop faster wherever you're coming from. As of bug reports - as long as every error has its own error code everyone in the world can find out what the error means. How different is that from simply translating the documentation? -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Mon, 25 Nov 2002 16:15:29 -0500 Sterling Hughes [EMAIL PROTECTED] wrote: Not at all, i don't expect them to speak fluent english, just to understand the small subset of english errors and programming terms. I've conversed with plenty of PHP users (second-hand at least) where they didn't know english, yet understood the error codes. Users need not know english, they can download a quicksheet. If you see Constant 3 And I tell you it means: Undefined constant, assuming string after a while that term will become like your own language, especially if its as simple as copying pasting, and clicking search. There are millions of IT people that do not know what either one of undefined, constant and assuming would exactly mean. Just in your two examples. assume you are coming from HTML world, how much of that will you know? Yet, these are PHP's most arrivals. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Mon, 25 Nov 2002 22:18:32 +0100 (CET) Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 25 Nov 2002, Sascha Schumann wrote: Frankly, so far the discussion has been primarily developer-focused, which is not too surprising. The developers are rarely exposed to support requests from newbies in various non-English forums. Thank god not; would you like to see your bugreports in french, or hebrew or finnish? If the error message is in a foreign language, people are going to report bugs in that language too, and I dont think QA is waiting for that. Even with an error number attached is going to be annoying; I myself would not even bother. If PHP is supposed to become easier to use, then native language error messages would be a big hit. Who says that PHP needs to be even easier then it already is? I think with the millions of users there are we're doing pretty okay I'd say. This can be easily avoided. When I have to report an Oracle error in Italian on an English page, I simply type the error code. We need to introduce error codes in PHP, that would really solve the trouble. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Mon, 25 Nov 2002 23:29:11 +0100 Daniel Lorch [EMAIL PROTECTED] wrote: You're right. We should think about writing a colorful GUI for PHP, so scripts just can be clicked together. Oh, and it definitively should support skins.. That isn't really a topic, and there are projects that work on it already. I can absolutely understand your argumentation (which you forgot to CC to the list, by the way) and being a regular to PHP-DE (german PHP users mailinglist), I am also in touch with people you described. But what's wrong about just HREF'ing to the manual, which is localized anyway? wrong is: 1. Internet connection. For instance, 1 sec or 5 mins online are oten same for many dial-ups - many will hesitate clicking their own errors :) 2. Speed for the connection 3. Many use downloaded manuals and want to find it there instead The only thing we are endlessly quarrelling^H^H ^H^H^H^H^H discussing about is whether we want to add localized error messages, yes? yes. Ok, simple question: Who would be (theoretically) willing to write AND maintain the appropriate code? I would! +111 from me. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002 00:30:55 +0200 (EET) Jani Taskinen [EMAIL PROTECTED] wrote: Just forget this. I'm not native english speaker, but I REALLY don't want to see any errors in any other language but english. (does Perl/Python/etc have multi-lingual errors btw?) --Jani The world's most powerful database server does - Oracle. And, just type something out of the place and you will get them dozens :) -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Mon, 25 Nov 2002 20:14:56 -0500 Ilia A. [EMAIL PROTECTED] wrote:
On November 25, 2002 07:57 pm, Maxim Maletsky wrote:
On Mon, 25 Nov 2002 15:21:06 -0500 Sterling Hughes [EMAIL PROTECTED]
wrote:
Educate users to speak the base amount of english required, I18N'ing the
language is just going to lead to headaches from a user perspective
(incorrect translations, slower performance, translations for english
speakers) and a developer perspective (having to lookup tokens,
understanding another language, getting bug reports with horrible error
messages).
That is why we have error codes :)
Are you saying that Oracle is wrong giving the ability to localize even
SQL error messages? These does not have to ever happen, but in my
Italian team the guys are simply rocking - they find out instantly what
they did wrong to a query because it is in their language.
Oracle is by far the most bloated piece of software in existence, adopting
ideas from it is hardly a good idea. It is so complex, that perhaps
localization was the only way they could make it usable for international
users.
Complex because does a lot - it is, in a way, an Operating Sytems on its
own.. But, as you can say yourself - localization of errors does help.
Sets the language to what you speak and you will develop faster wherever
you're coming from.
And the next logical step from that would be to develop in the language you
speak and this is how you get PHP code that makes Perl look good. Right now
code written by French developer can be understood by a Chinese developer,
with the eventual evolution of your suggestion understanding code would
require the knowledge of the language the author decided to use in addition
to PHP.
Hello?/?? we're talking about errors here, not page content.
Hopefuly that does not become the same :)
When you get an error while developing, seeing it in your own language,
whichever it is - English, Chinese, Russian or Japanese - it will be the
language you will set it to and thus the best for you, developer. What's
so wrong with that?
As of bug reports - as long as every error has its own error code
everyone in the world can find out what the error means. How different
is that from simply translating the documentation?
Bugs imply a problem with either PHP itself or in some cases an application
written in PHP. In those cases the person resolving the bug will be the
original developer who if he cannot understand the problem will pipe it to
/dev/null. I don't know how you evaluate your time, but most people just
don't have the time to look up error code XYZ in the big error-code codebook.
php_error(225);
whereas 255 is defined some string in many languages appering like this:
Warning (255): Undefined Variable.
One writes in bugs.php.net:
Non dovrei ricevere questo errore:
Attenzione (225): Variabile non predefinita.
in questo codice:
if($var) {
}
perche?
And you, without speaking italian, will be just as helpful to him.
Realistically, I think that even if you did introduce i18n in error message
most would still remain in English with maybe 20-30% of messages being
translated in popular locales like German and French and even lower in less
common locales. With such low translation level you are only going to
introduce confusion, which is the exact opposite of what you are trying to
do.
I don't think so. There are much less error strings than manual pages -
these got tranlsated well, and so will error string.
Just think how cool it is to be able to speak one language and still
find a programming langguage easy to understnad! A great marketing tool!
--
Maxim Maletsky
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Yes, this is the way to go. but, I would still prefer to have to pass it only a code like: php_error(255, data, data, data); where in an XML structure we can predefine everything else. -- Maxim Maletsky [EMAIL PROTECTED] On Tue, 26 Nov 2002 02:19:35 +0100 [EMAIL PROTECTED] (Marcus Börger) wrote: At 02:03 26.11.2002, Maxim Maletsky wrote: On Mon, 25 Nov 2002 22:18:32 +0100 (CET) Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 25 Nov 2002, Sascha Schumann wrote: Frankly, so far the discussion has been primarily developer-focused, which is not too surprising. The developers are rarely exposed to support requests from newbies in various non-English forums. Thank god not; would you like to see your bugreports in french, or hebrew or finnish? If the error message is in a foreign language, people are going to report bugs in that language too, and I dont think QA is waiting for that. Even with an error number attached is going to be annoying; I myself would not even bother. If PHP is supposed to become easier to use, then native language error messages would be a big hit. Who says that PHP needs to be even easier then it already is? I think with the millions of users there are we're doing pretty okay I'd say. This can be easily avoided. When I have to report an Oracle error in Italian on an English page, I simply type the error code. We need to introduce error codes in PHP, that would really solve the trouble. When using error codes we could supply a error-message-loader. php_error_docref would than not use fmt parameter but a number. The modules would then have to register their normal errors. For example: php_error_docref(NULL TSRMLS_CC, E_WARNING, Error %d, error) would convert to: php_error_docref(NULL TSRMLS_CC, E_WARNING, PHP-42, error) and in the init code we would register these errors: register_error_message(PHP-42, Error %d) and now translation tables for these error messages are possible. Main problem left is that we have to stick to error-code naming rules. We should always use the extensionname followed by a number. Exeptions would be main, standard and zend. marcus -- 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
Who cares? I am an Oracle fun, but this is still not my point. My point is that oracle, as arguable as can be, thinks about marketing its product. They biggest sales point, in fact, is not the usability and nor even the documentation. Though, as a matter of fact, every usage of its SQL and PLSQL programming is ported to every language. That is what I want for PHP. DB2 and MSSQL (of which I am not expert) do also care about this. Why shouldn't we, the world's most used web programming language? -- Maxim Maletsky [EMAIL PROTECTED] On Mon, 25 Nov 2002 20:24:03 -0500 Ilia A. [EMAIL PROTECTED] wrote: On November 25, 2002 08:15 pm, Maxim Maletsky wrote: On Tue, 26 Nov 2002 00:30:55 +0200 (EET) Jani Taskinen [EMAIL PROTECTED] wrote: Just forget this. I'm not native english speaker, but I REALLY don't want to see any errors in any other language but english. (does Perl/Python/etc have multi-lingual errors btw?) --Jani The world's most powerful database server does - Oracle. And, just type something out of the place and you will get them dozens :) That's arguable, there are many people who would say the same about IBM's DB2. According to TPC (http://www.tpc.org/tpcc/results/tpcc_perf_results.asp) Microsoft SQL Server 2000 is faster and has lower cost per transaction. So claims about greatness of Oracle and greatly exaggerated. 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] [PATCH] Redirect on Error
the number is not for speed, but rather to avoid all these parameters within the C code. Save all the docref etc data in an XML file each per language or in any other logic where also error strings will reside, but leave the C code clean. This would be a good gain in practicity of such method. Again, I am not saying the details, but rather the idea of what I meant. -- Maxim Maletsky [EMAIL PROTECTED] On Tue, 26 Nov 2002 02:40:21 +0100 [EMAIL PROTECTED] (Marcus Börger) wrote: A number is slightly faster but that is of no interest for error messages. More important is conflict avoidance and naming the extension in the error would be a fast first hint for us. Also we need the php_error_docrefn forms and the other parameters. Especially the error category (E_whatever) cannot be removed from the parameter since it is the easiest way to differenciate between those errors which are continuable and those not. marcus At 02:26 26.11.2002, Maxim Maletsky wrote: Yes, this is the way to go. but, I would still prefer to have to pass it only a code like: php_error(255, data, data, data); where in an XML structure we can predefine everything else. -- Maxim Maletsky [EMAIL PROTECTED] On Tue, 26 Nov 2002 02:19:35 +0100 [EMAIL PROTECTED] (Marcus Börger) wrote: At 02:03 26.11.2002, Maxim Maletsky wrote: On Mon, 25 Nov 2002 22:18:32 +0100 (CET) Derick Rethans [EMAIL PROTECTED] wrote: On Mon, 25 Nov 2002, Sascha Schumann wrote: Frankly, so far the discussion has been primarily developer-focused, which is not too surprising. The developers are rarely exposed to support requests from newbies in various non-English forums. Thank god not; would you like to see your bugreports in french, or hebrew or finnish? If the error message is in a foreign language, people are going to report bugs in that language too, and I dont think QA is waiting for that. Even with an error number attached is going to be annoying; I myself would not even bother. If PHP is supposed to become easier to use, then native language error messages would be a big hit. Who says that PHP needs to be even easier then it already is? I think with the millions of users there are we're doing pretty okay I'd say. This can be easily avoided. When I have to report an Oracle error in Italian on an English page, I simply type the error code. We need to introduce error codes in PHP, that would really solve the trouble. When using error codes we could supply a error-message-loader. php_error_docref would than not use fmt parameter but a number. The modules would then have to register their normal errors. For example: php_error_docref(NULL TSRMLS_CC, E_WARNING, Error %d, error) would convert to: php_error_docref(NULL TSRMLS_CC, E_WARNING, PHP-42, error) and in the init code we would register these errors: register_error_message(PHP-42, Error %d) and now translation tables for these error messages are possible. Main problem left is that we have to stick to error-code naming rules. We should always use the extensionname followed by a number. Exeptions would be main, standard and zend. marcus -- 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] [PATCH] Redirect on Error
It was to say that these three (Oracle, SQL and DB2) do have internationalized error reporting. I meant them as an example for the one PHP has. -- Maxim Maletsky [EMAIL PROTECTED] On Mon, 25 Nov 2002 20:44:03 -0500 George Schlossnagle [EMAIL PROTECTED] wrote: Is your claim that db2 has no international error messages? It does, or did last I checked. Or was it that SQLServer doesn't either (it does as well). On Monday, November 25, 2002, at 08:24 PM, Ilia A. wrote: On November 25, 2002 08:15 pm, Maxim Maletsky wrote: On Tue, 26 Nov 2002 00:30:55 +0200 (EET) Jani Taskinen [EMAIL PROTECTED] wrote: Just forget this. I'm not native english speaker, but I REALLY don't want to see any errors in any other language but english. (does Perl/Python/etc have multi-lingual errors btw?) --Jani The world's most powerful database server does - Oracle. And, just type something out of the place and you will get them dozens :) That's arguable, there are many people who would say the same about IBM's DB2. According to TPC (http://www.tpc.org/tpcc/results/tpcc_perf_results.asp) Microsoft SQL Server 2000 is faster and has lower cost per transaction. So claims about greatness of Oracle and greatly exaggerated. 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Mon, 25 Nov 2002 20:46:32 -0500 Ilia A. [EMAIL PROTECTED] wrote: Hello?/?? we're talking about errors here, not page content. Hopefuly that does not become the same :) Actually I am talking in users using their native language to name their functions variables and actually write them in that language. So, a person could use ISO-8859-15 encoding or cp1251 encoding because afterall it is easier to understand the code that way. OK :) When you get an error while developing, seeing it in your own language, whichever it is - English, Chinese, Russian or Japanese - it will be the language you will set it to and thus the best for you, developer. What's so wrong with that? Because when I work on a server where the language is set to Japanese which, I unfortunately do not know, I will have no idea what the error is. Well, in this case you would just add locales like you do with dates, for example. 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. I don't think so. There are much less error strings than manual pages - these got tranlsated well, and so will error string. Really? Let's see on average each function generates @ least one warning message, so we have @least as many warnings as we have functions. Warning messages get constantly re-arranged, by having a separate database for them making changes to warning messages will become more complex then writing the actual code. So, people will in many cases cut corners and just RETURN_FALSE; without giving a detailed explanation. Most developers like to write code, not modify XML files and write essays for proof look @ http://www.zend.com/phpfunc/statistics.php, according to that page ~14% of all functions in PHP are not documented in the English language. I don't agree with you, Ilia. Errors are string, even a part of the documentation. They need to be also translated whether it does or does not make a developer modifying an XML file. There can be several ways accomplishing it. I am more that just +1 for globalization or run time reporting. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Mon, 25 Nov 2002 20:47:01 -0500 Sterling Hughes [EMAIL PROTECTED] wrote: I spent about 15 minutes to learn the terms, and was set, besides using the german terms when all the german SAP consultants used the English terms (bedarfsbestandliste, stammdaten, lallalaa). If there was an error, I asked a colleague or looked it up on the internet - I survived. This happens to tons of php developers across the world, its not really that hard, and it really does open up pandora's box, also from an implementation perspective, its alot more feasible for Oracle than for PHP... If you would just ini_alter() for your language you would survive with PHP better than with Oracle when have to work in multiple languages at the same time. This problem would be inevitable anyway :) -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
YAY! -- Maxim Maletsky [EMAIL PROTECTED] On Mon, 25 Nov 2002 20:51:06 -0500 George Schlossnagle [EMAIL PROTECTED] wrote: MySQL also supports error message internationalization - one more RDBMS to annoy Sterling, I guess. George On Monday, November 25, 2002, at 08:47 PM, Maxim Maletsky wrote: It was to say that these three (Oracle, SQL and DB2) do have internationalized error reporting. I meant them as an example for the one PHP has. -- Maxim Maletsky [EMAIL PROTECTED] On Mon, 25 Nov 2002 20:44:03 -0500 George Schlossnagle [EMAIL PROTECTED] wrote: Is your claim that db2 has no international error messages? It does, or did last I checked. Or was it that SQLServer doesn't either (it does as well). On Monday, November 25, 2002, at 08:24 PM, Ilia A. wrote: On November 25, 2002 08:15 pm, Maxim Maletsky wrote: On Tue, 26 Nov 2002 00:30:55 +0200 (EET) Jani Taskinen [EMAIL PROTECTED] wrote: Just forget this. I'm not native english speaker, but I REALLY don't want to see any errors in any other language but english. (does Perl/Python/etc have multi-lingual errors btw?) --Jani The world's most powerful database server does - Oracle. And, just type something out of the place and you will get them dozens :) That's arguable, there are many people who would say the same about IBM's DB2. According to TPC (http://www.tpc.org/tpcc/results/tpcc_perf_results.asp) Microsoft SQL Server 2000 is faster and has lower cost per transaction. So claims about greatness of Oracle and greatly exaggerated. 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 -- 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
On Mon, 25 Nov 2002 20:53:55 -0500 Ilia A. [EMAIL PROTECTED] wrote: On November 25, 2002 08:29 pm, Maxim Maletsky wrote: Who cares? I am an Oracle fun, but this is still not my point. My point is that oracle, as arguable as can be, thinks about marketing its product. They biggest sales point, in fact, is not the usability and nor even the documentation. Though, as a matter of fact, every usage of its SQL and PLSQL programming is ported to every language. My point was that just because application XYZ does something, it does not mean PHP should do it to. Plus, comparing a database to a scripting language, how about we compare it to something equivalent, like Perl? Yes, they are not equal. But, database and scripting language has one thing in common - they both throw errors into any possible user on the earth. For this, we can even compare operating systems and hotmail footers. Fact is fact - when you make a product for the world's usage, you need to support world's different languages. PHP already does it very, very well with the documentation. I don't see why to argue so much whether to help these non-english speakers and gain more usage for PHP or not. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Mon, 25 Nov 2002 20:55:52 -0500 Sterling Hughes [EMAIL PROTECTED] wrote: MySQL also supports error message internationalization - one more RDBMS to annoy Sterling, I guess. MySQL IS NOT A RDBM. I like when you speak like that, Sterling :) Let me agree with you! Besides that, I've said my piece, anyhow, i think its stupid, I'll wait till I see a patch to disagree fully :) YAP! That is the way to go. Whoever is +(int)something start throwing up ideas and patches on how to accomplish this. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
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 with you, Ilia. Errors are string, even a part of the documentation. They need to be also translated whether it does or does not make a developer modifying an XML file. There can be several ways accomplishing it. I am more that just +1 for globalization or run time reporting. I have nothing against error codes, that is a good idea. I just have a problem with XML errors and i18n in error messages generated by PHP. When do we draw the line, how about function prototypes inside the C source code? Should those be translated as well, it would make developing PHP by example easier, no? XML is what I think would be the best for the whole thing of managing errors. It could be integrated into the docs, parallelly translated into multiple language, adding extra flexibility and features growth. This can be also useful for modifying errors for users themselves if they wish to. The rest I would not plan to change. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Problem with a php function
Mike, I am not really the person to ask about the parse_ini_file functionality. I remind, though, that just the other day there was something discussed on PHP-DEV list regarding it. Therefore, I CC this mail to the DEV list hoping there is any interest regarding your problem. Chances are it is a bug of some kind. -- Maxim Maletsky [EMAIL PROTECTED] Mike [EMAIL PROTECTED] wrote... : Hi, I have a question to you. I use a function named parse_ini_file but I think this is perhaps bugged let me explain to you : I have a spool directory , I put in file with .txt extension . My script despool the directory and rename the .txt to .ini After I use parse_ini_file() to parse the file and get all information Something (lot of time) parse_ini_file() give a array empty ! But there are something in my file ( perhaps I try it on the same file) So I use strace to see what happens with it and I get this : 1037980915.096081 ioctl(8, TCGETS, 0xbfffce9c) = -1 ENOTTY (Inappropriate ioctl for device) 0.10 1037980915.096165 read(8, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ 0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ 0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ 0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ 0\0\0\0\0\0, 8192) = 157 0.31 1037980915.096529 read(8, , 8035) = 0 0.09 1037980915.097249 read(8, , 8192) = 0 0.09 1037980915.097325 ioctl(8, TCGETS, 0xbfffc338) = -1 ENOTTY (Inappropriate ioctl for device) 0.09 1037980915.097395 close(8) = 0 0.11 You can seen that parse_ini_file() use ioctl() but this function is not appropriate for this utilisation. cf man ioctl : ENOTTY d error is : is not associated with a character special device. and sometimes the ioctl function return -1 code and nothing in the array . So I ask me why coder have been used ioctl and why the coder don't get the -1 error and put a php warning or other thing. Can you foward this mail to the parse_ini_file() coder and telle him to contact me to say me if I m in the wrong way ? Best regards, Michaël F. WEB / PHP Developer. Mobileway (+33) 1 41 44 46 21 [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Derick Rethans [EMAIL PROTECTED] wrote... : On Thu, 21 Nov 2002, John Coggeshall wrote: Again, what about IIS, etc? 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. Never used IIS in my entire life, but I would be scared shall PHP start loosing its IIS support letting .NET and Java more space on Win32 systems. I am sure there are cases when IIS is prefered to Apache on MS servers and when MS is prefered for certain production architectures and these architectures are prefer by certain brains. Don't ask me why - I hate that myself, but we should not ignore if want to be competitive. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Writing for newbies, I often heard them mentioning one things they liked about PHP (before even trying to use it) - PHP errors are not 500 weird pages made by your browser. 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. +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. just my +.2c -- Maxim Maletsky [EMAIL PROTECTED] James Cox [EMAIL PROTECTED] wrote... : it can; 500 means server error -- perl, cgi, mod_include, etc all do it, so why shouldn't php? -- james -Original Message- From: John Coggeshall [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 11:06 PM To: 'James Cox' Cc: 'PHP Developers Mailing List' Subject: RE: [PHP-DEV] error handling true... i'd like to see a 500 error though, and some persistent vars... See, the problem that I'm seeing here is that I don't believe PHP is reponsible for setting the error code returned by PHP.. For instance, a 404 error isn't handle by PHP at all. Likewise, I don't think PHP can say turn this into a 500 error to Apache. John -- james -Original Message- From: John Coggeshall [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 10:48 PM To: 'James Cox' Subject: RE: [PHP-DEV] error handling that can't really be done because parsing has happened, and so output has started -- but if we return status 500, the webserver can manage it properly.. Only if output buffering is off. Custom error handling should have output buffering on anyway as I've already said... John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] error reporting for PHP5
Guys,
I have been following the thread about error reporting thing and, I
think, it is all going off route.
Of course, the ideas John and Marcus working on both are very nice, they seem
to make many interested. But PHP's error reporting itself is very
limited. So, as often mentioned in past, the whole error reporting
logic should be redesigned at some point. PHP5 comes in mind.
I will start laying out some my thoughts to hopefully get a discussion
towards working on the complete error reporting logic. I had an
extensive experience implementing custom errors, so approve or
disapprove my ideas.
1. Error message should be ported to multiple languages. Most of the
largest app. servers do that - Oracle, for instance has a wonderful
one - you specify NLS and all the errors appear in your language.
Can't PHP be the same?
It can if, every PHP error is completely exported from C code and
stored in an XML file. The errors would be then called by passing the error
codes as numbers.
This will allow:
a) Having one XML file per language. Thus, translations can be easily
done by dozens of people without having to hassle with core and
extensions.
b) Documentation Team can edit errors files at any time and, by using
XML definitions, add any possible kind of features to it.
Something like what Marcus has been doing with docref. We could
add other important notices, relevances etc, etc. Possibilities
would be infinite.
c) Having error codes as well is handy. This can be very helpful for
docref - you can provide a link to FAQ with code in GET and help
immensely any developer understanding and debugging the error.
Few other apps do that and, I think, it could be an enormous jump for
usability of PHP.
d) Users will be able to alter their custom error codes if needed.
This could be helpful in cases when one wants to control the
appearance of error messages.
e) Any patch (like one proposed by John, for example) or
functionality on user's end that requires to recognize or store an
error can use error code to point to the specific message. For
instance, imagine this:
?php
...
// Assume that 225 is the code for Undefined variable error
// message
if(!@$var) {
// Assume we have such function that returns us last error code
if(last_error_code(225)) {
echo Failed because \$var was undefined;
}
else {
echo Failed because \$var is an empty string, zero, null or
false;
}
}
...
?
Of course, I know that you could use isset() function to work out
code below - I simply used it as the simplest example of
flexibility a user can have with this methology of coding.
f) You might add your own errors by reusing the same logic.
For instance:
?
// If you don't have error stored in XML,
// define it run-time:
register_error(346, Hey, this is what I failed like);
// To use it do simply:
trigger_error(E_ERROR, 346);
// throws user defined error on screen
?
Or, for instance, one can alter error message per-script in order
to have it differently for his case:
?
modify_error(225, Undefined Username);
// instead of just Undefined Variable
?
And things like this. Very, very useful for debugging logistics.
I believe that there will be the difficulty on dynamically passing
values to errors. Sometimes adding %s in messages might not be enough
because the words order isn't same in all languages. So, we should be
passing named values. I have done it once in one of my projects - I
can share the code.
2. Error messages can be controlled by locales runtime on multi-language
sites.
As i mentioned - this framework can be very flexible.
These are my ideas. I have been working on error reporting features
quite a few times for several clients, but mostly in PHP, where only
methodic are useful.
I think this (or whatever else that has this result) has to be
implemented in PHP from PHP5. It shouldn't break an y existing code, it
would be firstly an internal change, but it would definitely scale PHP
a lot. I would be happy to work on this if it gets approved
Now, throw all your good and bad thoughts into me :)
--
Maxim Maletsky
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: error reporting for PHP5
Ivan Ristic [EMAIL PROTECTED] wrote... : I will start laying out some my thoughts to hopefully get a discussion towards working on the complete error reporting logic. I had an extensive experience implementing custom errors, so approve or disapprove my ideas. I like your ideas too, but some of your suggestions need to be compared to the exception mechanism, to avoid duplicated effort. You are right. Extension errors, such as the ones returned from database, should be incorporated in a way that you can pass them to the end user. I think with a little bit of logic this is very much doable. For instance, in one of the project I have done it like: Error 1256: Cannot Connect to Oracle Listener. Oracle reported $ora_error where you pass as the parameter the actual message Oracle receives. So, in my opinion it is simple do accomplish. I have been following the thread about error reporting thing and, I think, it is all going off route. While I do agree that the error handling mechanism needs to be enhanced, none of your suggestions are directly related to the error handling discussion and the patch. I think we should finish with the patch discussion first so that we can later proceed to more complex issues. Completely agree again. It is why I started the new thread. Throwing this idea on another time can sound rush. Rright now, when our heads are occupied analysing error reporting, this can result being more productive, IMO. And, it is till related anyway. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] need directions adding a func.
Guys, I've added an OCI8 function in CVS the other week. I've avoided its release in RC1 so I can test it well, but it seems to be pretty stable and can be released with RC2. Since I never had to do this yet, I wanted to know a few things before I mess up something: 1. How do I get it onto ChangeLog? Normally, I would commit it with @ my Message to have it in NEWS, but I heard it is broken. What should I do? 2. Is there anything I should be aware of before tagging current oci8.c for RC2? Will all CVS be tagged for RC2 or is it left up to maintainers? 3. How would I go about adding the docs for the function? The function I refer to is OCIPasswordChange(). It allows you to handle expired Oracle users. OCIPasswordChange() is strictly based on Oracle internal permissions and directly aliases OCI. It was in TODO list for quite long time. I've been also considering disallowing this function in safe mode for security reasons. Opinions? (Thies disappeared somewhere. Anyone heard from him?) Cheers, m -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] need directions adding a func.
Thanks, Derick, Derick Rethans [EMAIL PROTECTED] wrote... : On Thu, 21 Nov 2002, Maxim Maletsky wrote: I've added an OCI8 function in CVS the other week. I've avoided its release in RC1 so I can test it well, but it seems to be pretty stable and can be released with RC2. We dont put new functions in a release after we branched to make sure we don't introduce new bugs with functions. Wasn't aware of this at all. Good I asked. Since I never had to do this yet, I wanted to know a few things before I mess up something: 1. How do I get it onto ChangeLog? Normally, I would commit it with @ my Message to have it in NEWS, but I heard it is broken. What should I do? It went to ChangeLog automatically, and you should indeed just use @- before your commit message. OK. If I commit oci.c with @- as HEAD now, ChangeLog will copy it into HEAD branch for NEWS without affecting PHP_4_3, correct? Or is it better if I wait? 3. How would I go about adding the docs for the function? checkout the phpdoc module and just put a new .xml file in the en/reference/oci8 directory. Can I already start preparing it now, or better leave it for later as well? I've been also considering disallowing this function in safe mode for security reasons. Opinions? I think it should be disabled in safe_mode indeed. Will do now. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Pear::db and odbc issue
You can be helped by mailing to [EMAIL PROTECTED] or by submitting a bug report at http://bugs.php.net. -- Maxim Maletsky [EMAIL PROTECTED] Chandler, Jacob R [EMAIL PROTECTED] wrote... : We are querying two different odbc databases using the Pear::DB library. When we try to print out the number of Rows ($result-numRows()), the output is 'Object'. We tried the same thing using odbc and we are getting '-1' as the number of rows. This appears to be an error because there are results in the database and if we attempt to get data, we can do this in a while loop with the fetchRow function and we get valid data. Can anyone give any suggestions? Jacob Chandler -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
John Coggeshall [EMAIL PROTECTED] wrote... : 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 I must say that I like this idea. User should be alble to specify the error page in php.ini for different error types and instructing the script to move onto a custom page, leaving the execution of a bad code alone. There would be several reasons why to treat errors gracefuly, even the E_PARSE ones: First reason is to be able to update the current pages in the production server with less risks. When you edit a file on a production site, you might create an E_PARSE error and correct it few seconds later. Not a big deal, but users currently online will be simply told - be back later - server experiences some trouble. Throwing errors on screen includes the full path and can sometimes be a theoretical security risk. Another reason I find for this is, when you do dynamic things like grabbing PHP code from other sources passing it through eval(). That can be out of your control and as such requires a more friendly error treatment. All that provided that an error log is being generated with on line xxx in file xxx but the page is the URL you specify in php.ini. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
It would still be good to have as there are tons of sites that use sessions and plain header() calls - they care of not having the output before processing is done. If E_PARSE error happens after an output the header() can fail bad too with headers sent message. But, if one wants to control well the whole error thing - it would then be possible. -- Maxim Maletsky [EMAIL PROTECTED] Kjartan Mannes [EMAIL PROTECTED] wrote... : Monday, November 18, 2002, 11:43:48 AM, John Coggeshall wrote: 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... 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. ? print Welcome; include(File that doesn't parse.inc); ? This would show the parse error then a header() error, unless you buffer everything and only do output after processing. 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.) 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. -- 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 Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: is_*
even earlier, I though... What really needs to be done is to document them better under ereg* and preg* and, maybe even, strings sections of documentation. This, I think, would give them the required famousity. -- Maxim Maletsky [EMAIL PROTECTED] Hartmut Holzgraefe [EMAIL PROTECTED] wrote... : [EMAIL PROTECTED] wrote: Okay, some of them are in ctype. But it should be easier to have them in standard so basic user should use them. ctype is enabled by default in 4.3 ... -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- 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: is_*
I was refering about ctype lib :) -- Maxim Maletsky [EMAIL PROTECTED] Maxim Maletsky [EMAIL PROTECTED] wrote... : even earlier, I though... What really needs to be done is to document them better under ereg* and preg* and, maybe even, strings sections of documentation. This, I think, would give them the required famousity. -- Maxim Maletsky [EMAIL PROTECTED] Hartmut Holzgraefe [EMAIL PROTECTED] wrote... : [EMAIL PROTECTED] wrote: Okay, some of them are in ctype. But it should be easier to have them in standard so basic user should use them. ctype is enabled by default in 4.3 ... -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- 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] build fails on bison
guys,
current W32 build has failed on bison for me with the parse error:
Configuration: TSRM - Win32 Release_TS
Compiling...
TSRM.c
tsrm_strtok_r.c
tsrm_virtual_cwd.c
tsrm_win32.c
Creating library...
Configuration: ZendTS - Win32 Release_TS
Performing Custom Build Step on .\zend_language_scanner.l
Compiling...
zend.c
zend_alloc.c
zend_API.c
zend_builtin_functions.c
zend_compile.c
Generating Code...
Compiling...
zend_constants.c
zend_dynamic_array.c
zend_execute.c
zend_execute_API.c
F:\CVS\PHP.NET\php4\Zend\zend_execute_API.c(366) : warning C4018: '==' :
signed/unsigned mismatch
zend_extensions.c
Generating Code...
Compiling...
zend_hash.c
zend_highlight.c
zend_indent.c
zend_ini.c
zend_ini_parser.c
Generating Code...
Compiling...
zend_ini_scanner.c
zend_language_parser.c
bison.simple(81) : error C2059: syntax error : '/'
bison.simple(83) : warning C4138: '*/' found outside of comment
bison.simple(189) : error C2449: found '{' at file scope (missing function header?)
bison.simple(196) : error C2059: syntax error : '}'
bison.simple(248) : error C2449: found '{' at file scope (missing function header?)
zend_language_parser.y(177) : error C2130: #line expected a string containing the
filename, found ''
zend_language_parser.y(358) : error C2005: #line expected a line number, found
'identifier'
bison.simple(760) : error C2059: syntax error : '}'
zend_language_scanner.c
zend_language_scanner.c(5726) : warning C4273: 'isatty' : inconsistent dll linkage.
dllexport assumed.
zend_list.c
zend_llist.c
Generating Code...
Compiling...
zend_multibyte.c
zend_opcode.c
zend_operators.c
zend_ptr_stack.c
zend_qsort.c
Generating Code...
Compiling...
zend_sprintf.c
zend_stack.c
zend_variables.c
Generating Code...
Error executing cl.exe.
php.exe - 7 error(s), 3 warning(s)
--
Maxim Maletsky
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] build fails on bison: update
That does not happen, however, on PHP_4_3 tag.
So just FYI.
--
Maxim Maletsky
[EMAIL PROTECTED]
On Thu, 14 Nov 2002 00:40:00 +0100 Maxim Maletsky [EMAIL PROTECTED] wrote:
guys,
current W32 build has failed on bison for me with the parse error:
Configuration: TSRM - Win32 Release_TS
Compiling...
TSRM.c
tsrm_strtok_r.c
tsrm_virtual_cwd.c
tsrm_win32.c
Creating library...
Configuration: ZendTS - Win32 Release_TS
Performing Custom Build Step on .\zend_language_scanner.l
Compiling...
zend.c
zend_alloc.c
zend_API.c
zend_builtin_functions.c
zend_compile.c
Generating Code...
Compiling...
zend_constants.c
zend_dynamic_array.c
zend_execute.c
zend_execute_API.c
F:\CVS\PHP.NET\php4\Zend\zend_execute_API.c(366) : warning C4018: '==' :
signed/unsigned mismatch
zend_extensions.c
Generating Code...
Compiling...
zend_hash.c
zend_highlight.c
zend_indent.c
zend_ini.c
zend_ini_parser.c
Generating Code...
Compiling...
zend_ini_scanner.c
zend_language_parser.c
bison.simple(81) : error C2059: syntax error : '/'
bison.simple(83) : warning C4138: '*/' found outside of comment
bison.simple(189) : error C2449: found '{' at file scope (missing function header?)
bison.simple(196) : error C2059: syntax error : '}'
bison.simple(248) : error C2449: found '{' at file scope (missing function header?)
zend_language_parser.y(177) : error C2130: #line expected a string containing the
filename, found ''
zend_language_parser.y(358) : error C2005: #line expected a line number, found
'identifier'
bison.simple(760) : error C2059: syntax error : '}'
zend_language_scanner.c
zend_language_scanner.c(5726) : warning C4273: 'isatty' : inconsistent dll linkage.
dllexport assumed.
zend_list.c
zend_llist.c
Generating Code...
Compiling...
zend_multibyte.c
zend_opcode.c
zend_operators.c
zend_ptr_stack.c
zend_qsort.c
Generating Code...
Compiling...
zend_sprintf.c
zend_stack.c
zend_variables.c
Generating Code...
Error executing cl.exe.
php.exe - 7 error(s), 3 warning(s)
--
Maxim Maletsky
[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
[PHP-DEV] reg.c warning patch
I've patched a tiny signed/unsigned mismatch warning in ext/standard/reg.c. I based on what a similar line (343) was doing. Someone with karma double-check and commit. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Photos from the Conference
I put some up. Whoever is interested: http://www.php-conference.de/gallery/album10 -- Maxim Maletsky [EMAIL PROTECTED] On Thu, 7 Nov 2002 13:25:50 +0100 Björn Schotte [EMAIL PROTECTED] wrote: * Maxim Maletsky wrote: But hey! Where is me? You got no photos of me there :) How come? Perhaps at http://www.phpconference.de/gallery/ ? (Those people who made photos should upload them there) -- 35 Kundenportale mit mehreren tausend Nutzern erstellen. Bei geringen Kosten und einer großen Anzahl an Modulen (DMS, CMS, CRM, Community-Funktionen). Wie das geht? = http://testthesystem.com/ * [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] Proto void and return values...
Most of them (70% ?) are actually having wrong protos in docs. I refer to the ones that return boolean (like phpinfo() for instance) but documented as returning an integer. This is not really a huge issue, but does make confusion because of the kind of functions that MUST return true of false (is_link() for example). -- Maxim Maletsky [EMAIL PROTECTED] On 12 Nov 2002 22:59:50 +0100 Zak Greant [EMAIL PROTECTED] wrote: On Tue, 2002-11-12 at 20:25, David Brown wrote: On Tue, Nov 12, 2002 at 02:16:41PM -0500, David Brown wrote: | Hi everyone: | | For functions prototyped as returning void, return values seem to be applied | at random. Some functions, such as trigger_error/user_error, srand, ob_start, | and phpinfo, use RETURN_TRUE. The vast majority of these functions just fall | through, implicitly returning NULL to userland. Or perhaps I'v just thought about this entirely too long. Is it possible that the prototypes are just wrong in the documentation? Bingo! :) (or at least, that is my belief - I might be wrong :) --zak -- 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] What happened to the notes on php.net?
For my big surprise there aren't there Did I miss something? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Flash and PHP
please re-post this message to [EMAIL PROTECTED] php-dev is a wrong list for such questions. -- Maxim Maletsky [EMAIL PROTECTED] On Sat, 9 Nov 2002 21:45:13 +0100 Georg [EMAIL PROTECTED] wrote: Hi Folks I try to comfortize my webpages using flash.The server part is still PHP implemented. Has anyone experiences on this subjects. Especially trial and errors ;) could be very informativ to me. thanks for your help in advance kind regards Georg -- 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] mbstring and 4.3.0
I think Wez got a point here. Disabling mbstring can make many unhappy. -- Maxim Maletsky [EMAIL PROTECTED] Wez Furlong [EMAIL PROTECTED] wrote... : I see the known-good codeset conversion implementation as a *very* good reason to have mbstring enabled by default. (Just look at all the problems with iconv and recode on different systems out there). I agree that the magic features for lazy programmers (function overloading and transparent encoding) are slightly worrying, but they are disabled by default, and as I have said - I don't use those, but I do use the conversion functions and *that* configuration works just fine. The conversion functions are something that really should be there by default, as it allows people to write portable globalized scripts. Remember that a large majority of users are vhosted and have not control over the build of PHP. By not providing a reliable and portable codeset conversion API, we are holding back the masses from writing (and distributing) killer apps in PHP. Yes, I can enable mbstring at configure time, and yes, the CJK people can do likewise, but what about the rest of the world running from vhosts when they want to use unicode, quoted-printable, uu-encoding, name of your favourite encoding here encodings which are also supported by mbstring? We took the decision to enable it by default; let's not be short-sighted and disable it primarily out of ignorance (no offence intended). I've yet to see someone comment on my suggestions for a practical solution that would shut up both myself and the people advocating disabling it. --Wez. On 11/07/02, Derick Rethans [EMAIL PROTECTED] wrote: On Thu, 7 Nov 2002, Marcus Boerger wrote: To make php be easier usable in non US-ASCII (127chars) environments especially those requiring UCS-2, UTF-8 or other any character mapping other than iso-8859-1 or -15 we should more likly try to integrate mbstring fully in php. As long as we cannot or want not make it a core component such as ext/standard we should enable it by default. If people want it they can use --enable-mbstring. I see no reason why it should be enabled by default as long as it's not fully integrated in the core. -- 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] Return -1
Guys, I have just fixed a few doc files where it was stating that a function returned -1 but the sources had clear RETURN_FALSE. Done that, I took some time to grep my phpdoc and php4 trees for -1 returns and, surprisingly, I found out that there were a few suspicious places where -1 could be better changed to RETURN_FALSE. Some of such places were FTP, pgSQL, LDAP functions. Maybe a dozen or less in total. I don't think this should be done right now, as we would directly break the backwards compatibility. But, shouldn't we be considering such consistency changes for PHP5 releases? My point is that functions behaviour consistency can be very important for many users, and breaking just a few lines of PHP4 code since first PHP5 releases would probably be a small price to pay. What do you all think? Am I saying something strategically logical or this is only my own paranoia? -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
