Re: [PHP-DEV] [PATCH] Redirect on Error
On Mon, 25 Nov 2002, Alexander Wagner wrote: On Monday 25 November 2002 23:29, Daniel Lorch 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.. I don't think this would work. But if it did, it's place wouldn't be inside the language. Either in an IDE or in a PHP-application. PHP often is used for skinning a website, btw. It was a _joke_. But if there were a good idiot-proof IDE, it would definately help these people. It would have to be free (beer), of course. People who spend 2,50€ a month on webspace won't spend a fortune on an IDE. On the other hand, you lose a lot of flexibility this way. At some point, people will have to touch the code. And there should be as few obstacles as possible. 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? You'd have to put a href in every single error-message. Ugly. Either this, or people won't find it. We already do that anyway. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Alexander Wagner wrote: On Tuesday 26 November 2002 00:07, Jani Taskinen wrote: Remember. I'm talking about the people that have to be spoon-fed. Well..to be quite honest: I don't care about such people. To be honest, they tend to piss me off a little (at least some do). Getting rid of these stupid questions... ah... dreaming again... They're not working with PHP, they just use it for fun. Every _serious_ developer definately knows enough english.. Not necessarily. There are still those that are too young, and those that are too old. PHP has a very wide userbase. But you're not that wrong... anybody who is serious will find a way to understand it. But PHP is very popular among people who are _not_ serious. Some become serious. After the got in touch with programming. After they got their first site to work. Removing obstacles is mostly a good thing. PHP is very easy to use already. This is just one point where it still can improve. 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 -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, 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. Sets the language to what you speak and you will develop faster wherever you're coming from. I don't agree with that, I had no idea what a 'afrolmenu' was when I got a weird error message in Word; after all it just seemed to be a dropdown box. 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? Did you think on how to manage all those error codes in internal (php4/ext) extensions, external (pear/pecl) and third party extensions? It would be a hell to maintain it all; it's just not practical. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: 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. The same would be try for the italian or dutch localized error, it would be as arabic for them as the english version. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
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 Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Marcus Börger wrote: 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. Bloat alert! Do you have any idea how expensive those hash looks ups are? And I would _never_ want to maintain that for any code I write. And how would you handle clashes in here? It's a bad idea. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
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
Re: [PHP-DEV] [PATCH] Redirect on Error
On Mon, 25 Nov 2002, Ilia A. wrote:
On November 25, 2002 08:24 pm, Maxim Maletsky wrote:
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.
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.
Same is true for 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
Re: [PHP-DEV] Error Codes, Langs, etc
On Mon, 25 Nov 2002, John Coggeshall 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 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. I'm a big -1 on introducing XML bloat for error codes/descriptions 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. But those _users_ expect us to support PHP for free. I think it's totally different. What I propose is based off of my first proposal of Error codes based on Maxim's suggestions. Basically, I'd like to see errors broken down into three separate code constants: TYPE, MODULE, AND ERROR... Where TYPE would be E_ERROR, etc, MODULE would be the extension causing the error (M_PHP_CORE, etc) and ERROR would be the actual error that occurred (i.e. E_PHP_CORE_PARSE). Notice that I am using descriptive names for the error constants. This is because I suggest that although each individual error message is localized to german, french, etc, every error message displays this descriptive errorcode... Ie.. Error (module: E_ERROR, M_PHP_CORE): A parse error occurred at line 34 of file foobar.php (E_PHP_CORE_PARSE) Störung (Modul: E_ERROR, M_PHP_CORE): Eine Satzgliederung Störung trat an Linie 34 der Akte foobar.php auf (E_PHP_CORE_PARSE) Erreur (modules: E_ERROR, M_PHP_CORE): A erreur parse occurred AT ligne 34 of fichier foobar.php (E_PHP_CORE_PARSE) This would be simple to implement, and no more of a hassle to maintain that what already exists however still provides enough information to the development/QA teams (we know the type, the module, and the actual error which occurred) yet still allows the developers who aren't english-speaking to still have some clue as to what the heck happened with their script. But for all I know nobody on the QA team will do any effort to look at it, but just press the in-english quickfix; and I can assure you that that will be added right away IF this stupid localization idea is implemented. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Mon, 25 Nov 2002, George Schlossnagle 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? imagine registering 20 extensions * 40 (that's about the average) functions * 5 error messages per function, that's 1600 inserts into a hash table on every MINIT. (Atleast in the way that was proposed here) Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Sascha Schumann wrote: Also please think about the billions of people who are not in such a privileged situation of having Internet access all the time. Think of school labs which are not permanently connected; think of poor countries where access is not easily available; think of home users with time-metered dial-up access. For all of those, relying on the online documentation might not be an option. http://www.php.net/download-docs.php Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Derick Rethans wrote: On Mon, 25 Nov 2002, George Schlossnagle 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? imagine registering 20 extensions * 40 (that's about the average) functions * 5 error messages per function, that's 1600 inserts into a hash table on every MINIT. (Atleast in the way that was proposed here) Either a) registration happens on-the-fly = no penalty for standard performance b) registration is not necessary and we just perform a cdb lookup - Sascha -- 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 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 -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
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. Andrey -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
PO Just to defend phpdoc a bit, this statistic is based on PO a php manual generated on April 25, 2002, which is when PO zend.com/manual/ was last updated. Also, missing functions That's not exactly true. The phpfunc is updated much more frequently than the manual (since it takes _a real lot_ of time to build the full manual...) - usually, daily. Also, as far as I understand, the numbers are taken from manual/PHP sources, not from generated manual. So if something is not correct, it's because I messed something up or something changed in the manual and phpfunc script no longer catch it - but not because it's not updated. Can you point to some function that is defined but listed as not defined? Did the manual structure change substantially? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Error Codes, Langs, etc
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 marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] radius extension
Hi, I made a radius extension for PHP. This extension is just a wrapper for the libradius of FreeBSD, but I imported this lib into the extension-dir and therefore it doesen't need external libs, its just --enable-radius. My questions are: - Is this extension welcome in the PHP-Project? - How to proceed, where should I send my extension? - Windows: It should also build under windows with some modifications, but I have nothing found in the documentation about the build-process under windows = HowTo? bye, -- --- -- Michael Bretterklieber - [EMAIL PROTECTED] JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200 -- privat A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED] Fax: ++43-(0)316-403274-10 http://www.inode.at/mbretter --- -- ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] radius extension
On Tue, 26 Nov 2002 10:33:02 +0100 Michael Bretterklieber [EMAIL PROTECTED] wrote: - Windows: It should also build under windows with some modifications, but I have nothing found in the documentation about the build-process under windows = HowTo? I suppose you need to read this: http://www.php.net/manual/en/install.windows.php --- Wbr, Antony Dovgal aka tony2001 mailto:[EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] radius extension
Antony Dovgal schrieb: On Tue, 26 Nov 2002 10:33:02 +0100 Michael Bretterklieber [EMAIL PROTECTED] wrote: - Windows: It should also build under windows with some modifications, but I have nothing found in the documentation about the build-process under windows = HowTo? I suppose you need to read this: http://www.php.net/manual/en/install.windows.php but this is for the end-user and not for a developer. I found in each extension .dsp files, this are files from MS-Visual-Studio. Before I can start building my extension I must have this file and I have no idea how to make such file. bye, -- --- -- Michael Bretterklieber - [EMAIL PROTECTED] JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200 -- privat A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED] Fax: ++43-(0)316-403274-10 http://www.inode.at/mbretter --- -- ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 -- 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, Stanislav Malyshev wrote:
PO Just to defend phpdoc a bit, this statistic is based on
PO a php manual generated on April 25, 2002, which is when
PO zend.com/manual/ was last updated. Also, missing functions
That's not exactly true. The phpfunc is updated much more frequently than
the manual (since it takes _a real lot_ of time to build the full
manual...) - usually, daily. Also, as far as I understand, the numbers are
taken from manual/PHP sources, not from generated manual.
So if something is not correct, it's because I messed something up or
something changed in the manual and phpfunc script no longer catch it -
but not because it's not updated. Can you point to some function that is
defined but listed as not defined? Did the manual structure change
substantially?
Yes, phpfunc updates daily and that is good (although it continues
to say last updated sept. 22). There are documented functions
listed as not documented but your last comment seems to decipher
why. Sorry to assume where those statistics are based although
this looks related as April 25 is close to April 17, which
is around when the big change happened.
The manual structure did substantially change at around April
17, 2002. Now the functions are in their own xml files, and
they all live in the reference/ directory. The old xml files
still exist but aren't updated anymore. So:
Old: en/functions/{extension}.xml
New: en/reference/{extension}/functions/{function}.xml
It sounds like this is where the problem lives. As a reference,
glob() was initially documented about six months ago and sha1()
about six days.
Regards,
Philip
--
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] [PATCH] Redirect on Error
PO Yes, phpfunc updates daily and that is good (although it continues
PO to say last updated sept. 22). There are documented functions
Sept. 22 is code update date (i.e., that's the last time the file
structure, etc. changed). I think there indeed needs to be something more
clear to state this.
PO Old: en/functions/{extension}.xml
PO New: en/reference/{extension}/functions/{function}.xml
PO
PO It sounds like this is where the problem lives. As a reference,
PO glob() was initially documented about six months ago and sha1()
PO about six days.
Oh. Now I see. So each function now has one individual file? I guess that
requires update to phpfunc module. I will check into this.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109
--
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] [PATCH] Redirect on Error
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
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
At 11:22 26.11.2002, Maxim Maletsky wrote: 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! -MAX_LONG on this. I assume none of the php-dev coders will loose connection between the error message and the source where the error happens. And why if you would do as i wrote before no one forbids you to even overwrite the english error message. And for me it is a requirement before accepting i18n error messages that you can still have error message in english text without any external data file. marcus 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 -- 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
And, most importantly, what the hell doi I care of losing 0.12 secs for a Fatal Error dysplay? I don't like the whole idea of having localized error messages. People have to use English when programming PHP anyway, and nobody is insane enough (yet) to suggest to translate function names. I don't think Parse error is any more difficult to understand than register_shutdown_function(). People use manual for understanding things like this. And I do care about unnecessary performance loss. But most of all I care about maintenance nightmare that this localization would put us in. If some of the pro-localization ever bother to read the php-bugs you would know that even a simple matter of using the correct .ini or .dll file can be too much for your target audience. Adding some CDB file to it is not going to help. The other side is maintaining the translation in the PHP code itself. This is just too large a task for the current team. I think it would be far more useful that some energy is spent on keeping PHP manual up to date so say our Italian users would have some clue about streams once PHP 4.3.0 hits the street. 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 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. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [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
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. Billy tried localizing programming languages as well. Remember Excel 95? It ended up in complete disaster and was removed in the next office version. Edin -- 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
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. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
At 11:55 26.11.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); Tht is silly because there is no connection between 354 and the comment above. And then what am i presented if i do not have a message file. And a greater problem would be startup errors - those that occur before the message file could be loaded. Can save the whole thing. Naming conventions and coding style used commonly can be the solution. -- 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
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: 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. 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. Can you please also reply _below_ the other comments, it's annoying to following discussions when you quote above. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [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
On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: ERROR STRINGS **OUT** OF THE C CODE! NO WAY. And don't shout on the mailinglist. 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. I know that you wanted to say that; it just does make things even harder. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : 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. 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. We didn't suffer from this at all, and why is PHP not usable enough? We have tenth of thousand users. 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. Then why care if you don't need it? Why do more work because only others want/need it? IMO that's just plain dumb. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
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. MS made localization of WinXP and Office(wo documentation translated AFAIK). The .bg goverment spent $13mil for 30,000 licenses over 3 years. This is why MS they translated the GUI. They claimed that they spent several millions of US $ to do that. However a 16 year old boy here made a translation pack (translates about 80% of win98) without the need of several millions. The reason for buying these 30,000 licenses was that XP is on bulgarian and the workers in the goverment will work better. The question is how these workers worked before. Maybe they used abacuses. When there is a need people _learn_. The process is maybe slow but..that's the way. Anyway. Let's return on the localization of php. I am not on php-general ever more but when I was there were plenty of people that like to ask on the forum instead of reading the documentation which is quite clear. After that localization the same people will start to ask questions with errors in language other than english. When this time comes many people will stop to help because they don't know french,italian, spanish, chinese, etc. Andrey -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
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? 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. Zeev At 13:01 26/11/2002, Maxim Maletsky wrote: 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] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
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. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
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] Error Codes, Langs, etc
Billy tried localizing programming languages as well. Remember Excel 95? It ended up in complete disaster and was removed in the next office version. The language won't chance. Stop the FUD. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: 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. The default messages must stay; there is no need to _always_ install a message catalogue. PHP should work fine without it. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : On Tue, 26 Nov 2002, Maxim Maletsky wrote: 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. It sure does sound like that, but what is wrong with that? 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. Absolutely it should. We're not making it any less usable anyway by not adding localized errors. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
At 13:05 26/11/2002, Maxim Maletsky wrote: 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. That's quite arguable, Maxim. I personally find error internationalized error messages as very annoying, and I have quite a bit of experience in that. Fact is, especially in a technical area such as PHP, lots of information is lost or gets degraded when you translate it. I'm sure that there are people who would prefer localized error messages, but my guess is that they won't be the majority of users. Zeev -- 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, 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. 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
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. Zeev -- 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 Tue, 26 Nov 2002, Sascha Schumann wrote: Billy tried localizing programming languages as well. Remember Excel 95? It ended up in complete disaster and was removed in the next office version. The language won't chance. Stop the FUD. This is not FUD. He brought up the issue of M$ practises. And I didn't hear you answer the question about why is parse error more difficult to understand than register_shutdown_function? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] radius extension
Hi Michael, On Tue, Nov 26, 2002 at 10:33:02AM +0100, Michael Bretterklieber wrote : My questions are: - Is this extension welcome in the PHP-Project? It is, and I think it perfectly fits into PECL, see http://pear.php.net/manual/en/introduction.php#about-pecl - How to proceed, where should I send my extension? People at [EMAIL PROTECTED] will get you on the track. - Windows: It should also build under windows with some modifications, but I have nothing found in the documentation about the build-process under windows = HowTo? The usual thing is to copy over the *.dsp file from an already existing extension and just add the necessary changes. - Markus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
At 12:05 26.11.2002, Zeev Suraski wrote: At 13:05 26/11/2002, Maxim Maletsky wrote: 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. That's quite arguable, Maxim. I personally find error internationalized error messages as very annoying, and I have quite a bit of experience in that. Fact is, especially in a technical area such as PHP, lots of information is lost or gets degraded when you translate it. That is the exact reason why i always buy books in english and no german translations. I'm sure that there are people who would prefer localized error messages, but my guess is that they won't be the majority of users. Zeev -- 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
[PHP-DEV] Concrete suggestion re: i18n messages
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. There, simple and straight-forward. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
This is not FUD. He brought up the issue of M$ practises. And I didn't hear you answer the question about why is parse error more difficult to understand than register_shutdown_function? You need to learn a bit about writing good compilers. It is easy to write a compiler; it is hard to write a compiler with good diagnostic output. Yes, parse error is never a good error message, regardless of the language it is presented in. Fortunately, most error messages in PHP are easier to digest and actually provide some clue. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] radius extension
Hi, - How to proceed, where should I send my extension? People at [EMAIL PROTECTED] will get you on the track. of course I have also to write wrapper classes (PEAR-Package), because the API of libradius is at very low-level. - Windows: It should also build under windows with some modifications, but I have nothing found in the documentation about the build-process under windows = HowTo? The usual thing is to copy over the *.dsp file from an already existing extension and just add the necessary changes. ok, will try it bye, -- --- -- Michael Bretterklieber - [EMAIL PROTECTED] JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200 -- privat A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED] Fax: ++43-(0)316-403274-10 http://www.inode.at/mbretter --- -- ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
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
Re: [PHP-DEV] [PATCH] Redirect on Error
At 09:47 26.11.2002, Derick Rethans wrote: On Tue, 26 Nov 2002, Marcus Börger wrote: 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. Bloat alert! Do you have any idea how expensive those hash looks ups are? And I would _never_ want to maintain that for any code I write. And how would you handle clashes in here? It's a bad idea. Derick You pointed me to my failure here :-) php_error_docref(NULL TSRMLS_CC, E_WARNING, Error %d, error) should convert to php_error_docref(NULL TSRMLS_CC, E_WARNING, PHP-42, Error %d, error) and now loading any external data is optional and registering error messages is no longer needed. And such conversion can easily be done automagically by a sed script. Some people already accepted bundeled cdb as a good message storage. This would require 2 or 3 file lookups per message. And again you shouldn't have one single error message in setups where time is money. In those scenarios you are expected to have *no* error. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
hi, Some thoughts that were brought up: Oh, another one: - Localization is stupid and we might lose our existing userbase, namely more proficient PHP developers- -daniel -- 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] [PATCH] Redirect on Error
On Tue, 26 Nov 2002, Maxim Maletsky wrote: 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. wha? I don't see any reason why it should be redesigned at all, it's just fine as it is. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Can you guys please quit bickering and focus on the concrete proposal which is on the table. - Sascha -- 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
ext/session/errors/en.cat Sounds good. Also, a logic to always use english error as default. Note that the English format messages stay in the source code. This does not cover message catalogues for extensions yet -- similar to the ini-directory, the php_error_ex function could try a number of message catalogues in a defined msg-catalogue directory, before falling back to the English format message. - Sascha -- 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
This does not cover message catalogues for extensions yet -- similar to the ini-directory, the php_error_ex function could try a number of message catalogues in a defined msg-catalogue directory, before falling back to the English format message. (I'm referring to separately installed extensions here, e.g. from PECL.) - Sascha -- 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
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. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
At 12:46 26.11.2002, Maxim Maletsky wrote: 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. Then why strip the module from the error code. I like that hint in the oracle messages much. 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. I could have done without but wanted to add more flexibility (show important function parameters and allo to use another link) and pass around TSRM parameter for speed reasons. 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] There were some good points to consider in these threads but i disagree that we need a complete redesign. As myself and even more Sascha showed i18n messages can easiliy be added to the current system. When it is up to add error code more work is needed without a question. The thing i fear most about further changes is that we either need new API functions to handle the error codes or we end up in endlessly bugs about php not compileable because some errors need to be changed. That is one of the reason i left the change from php_error() to new php_error_docref() to the authors of the modules and gave them a nice tool to aid them. marcus -- 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, Sascha Schumann wrote: Can you guys please quit bickering and focus on the concrete proposal which is on the table. I think starting with a concrete proposal before it's not clear if we even want this localized errors thing seems rather time-wasting. What you call bickering, I call discussing, and IMO we're not yet done discussing if we want this at all. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
PO It sounds like this is where the problem lives. As a reference, PO glob() was initially documented about six months ago and sha1() PO about six days. OK, I have updated the phpfunc to use new manual structure. The number of undocumented functions is down to 12% now :) -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- 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
On Tue, 26 Nov 2002, Derick Rethans 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. Agreed.. The default messages stay in the source code and are easily reachable for the developer. (That is something I very much dislike about the current phpdoc organization. Every time I want to change something in the main English documentation, I need to hunt around for remote, well-hidden xml files. The docs were more up-to-date, if these files were easier to access.) - Sascha -- 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] [PATCH] Redirect on Error
I think starting with a concrete proposal before it's not clear if we even want this localized errors thing seems rather time-wasting. What you call bickering, I call discussing, and IMO we're not yet done discussing if we want this at all. Well, there won't be a consensus regarding i18n facilities any time soon on php-dev. I can post some hilarious quotes from your funny IRC channel to demonstrate that point. Hence, the only way to move this forward is to actually code something up and enable extension authors to provide i18n error messages. The first step consists of adding the necessary look-up code to PHP itself; the second step is building the infrastructure for maintaining and generating message catalogues; the third step consists of assigning error codes to extensions; and as the final step, translators can actually commence to build the message catalogues. - Sascha -- 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 Tue, 26 Nov 2002, Sascha Schumann wrote: This is not FUD. He brought up the issue of M$ practises. And I didn't hear you answer the question about why is parse error more difficult to understand than register_shutdown_function? You need to learn a bit about writing good compilers. It is easy to write a compiler; it is hard to write a compiler with good diagnostic output. You missed my point: you cannot write PHP code without using English. Function names, reserved words, etc. are all in English. So does this mean that non-English speaking people are unable to write PHP code? Of course not. With a good manual this is perfectly possible. IMHO error messages are no different. Edin -- 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
If I wanted localized error messages, then this would be the way to do it. Perhaps merging this with the php_error_docref might be slightly better. However, I'm personally -1000 on such things; there are many reasons, most of them have already been raised here, so I won't repeat them now, but the main issue is with the maintainability of such a thing; localization is very hard to maintain on a volunteer basis (just look at our manual). For something as important as error messages, it is better to have the definitive error message in english and then take advantage of the hyperlink generated by php_error_docref which will display more detailed information in the localized manual. --Wez. On Tue, 26 Nov 2002, Sascha Schumann 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. There, simple and straight-forward. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Help requested: Memory leak in PHP for NetWare
Hi, We are seeing a large memory leak in PHP 4.2.3 for NetWare. We just load mod_php alongwith apache 1.3 and then unload apache without executing any script. We find that there is a memory leak of about 14KB. The same is observed when we load the command line version of PHP also and unload it. In fact, it was earlier leaking about 55KB. We added the following code in the zend_shutdown function in zend.c. These release about 21KB. destroy_zend_class(zend_standard_class_def); zend_hash_destroy(EG(persistent_list)); zend_hash_destroy(EG(zend_constants)); free(EG(zend_constants)); zend_hash_destroy(GLOBAL_CONSTANTS_TABLE); free(GLOBAL_CONSTANTS_TABLE); Can you throw some light on how we can go about releasing the other 14KB? I feel the extra is also in Zend. Or is it that Apache may be caching some memory and freeing it after some time. But this doesn't explain why the command line PHP (cli) is also leaking memory. This is quite a critical issue with NetWare customers and so your help in this is deeply appreciated. Thanks, Ananth. -- 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, 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. -Andrei http://www.gravitonic.com/ * The best source is the source code. * -- 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 08:57:33 -0500 Andrei Zmievski [EMAIL PROTECTED] wrote: Don't forget that there seem to be many who strongly opose your suggestion. Myself included. Same here (strongly oppose). pierre -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Object reference
Hello php-dev,
PHP4.3.0RC1
Source
?
$globalref_foo = array();
$globalref_bar = null;
class Foo {
function Foo()
{
global $globalref_foo;
$globalref_foo[] = $this;
}
}
class Bar {
function Bar()
{
global $globalref_bar;
$globalref_bar = $this;
}
}
$o1 = new Foo();
$o2 = new Bar();
var_dump($globalref_foo);
var_dump($globalref_bar);
var_dump($o1);
var_dump($o2);
?
Output:
array(1) {
[0]=
object(foo)(0) {
}
}
NULL
object(foo)(0) {
}
object(bar)(0) {
}
Question:
Why $globalref_bar===NULL after $o2 = new Bar(); ?
Why
Best regards,
Andrew Sitnikov
e-mail : [EMAIL PROTECTED]
GSM: (+372) 56491109
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #20638 [Opn-Fbk]: Apache cannot start
I'm experiencing the same problem. OS: Windows XP Apache 1.3.27 for Windows MySQL 3.23.53-win PHP 4.2.3 for Windows (php-4.2.3-Win32.zip) After I successfully installed Apache and MySQL, I tried to install PHP as module. Following the instructions of install.txt I got this result: Cannot load [path]/psp/sapi/php4apache.dll into server: module not found. The problem lies somewhere within the line 'LoadModule php4_module c:/[path]' - but if I look into the .dll the module is there.. Regards, Jan 'Mac' Maska P.S. No 'RTFMs', please.. this error was generated using your installation notes. M. __ ..::jan maska::.. +420 608 453492 web developer Systinet, Prague -- [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... ID: 20638 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Win2K Advanced Server PHP Version: 4.2.3 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Previous Comments: [2002-11-26 02:18:16] [EMAIL PROTECTED] After I configured PHP as a module in Apache, Apache cannot restart or start. But when I configured PHP as a CGI binary, Apache worked well. I installed PHP following INSTALL.TXT in php package. -- Edit this bug report at http://bugs.php.net/?id=20638edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20638 [Opn-Fbk]: Apache cannot start
On Tue, 26 Nov 2002, Jan Maska wrote: I'm experiencing the same problem. OS: Windows XP Apache 1.3.27 for Windows MySQL 3.23.53-win PHP 4.2.3 for Windows (php-4.2.3-Win32.zip) After I successfully installed Apache and MySQL, I tried to install PHP as module. Following the instructions of install.txt I got this result: Cannot load [path]/psp/sapi/php4apache.dll into server: module not found. The problem lies somewhere within the line 'LoadModule php4_module c:/[path]' - but if I look into the .dll the module is there.. Regards, Jan 'Mac' Maska P.S. No 'RTFMs', please.. this error was generated using your installation notes. M. The exact same setup works for me, so you probably missed something. Probably the part about putting php4ts.dll and the rest of files in the dlls folder into some directory in path (c:\windows\system32 for example). Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/dba config.m4
I guessed both of you are the right persons to ask: this patch prohibits users from missconfiguration. For example you can compile with --with-db2 and --with-db3 and think you may work with both file formats. Unfortuanetly you can only have one of the dbn sub modules. The problem i have commiting this to the branch is that i have nearly completley rewritten the configure file. Especially it works different from the original version. But it does not need .h or .c changes. So i ask you wait for next major release or commit? marcus actually At 13:00 26.11.2002, Marcus Boerger wrote: helly Tue Nov 26 07:00:26 2002 EDT Modified files: /php4/ext/dba config.m4 Log: -Disallow combining db2 with db3 which are conflicting. -Stop searching for headers and libraries when found. -Check version for Berkeley DB library headers. -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Redirect on Error
Alrighty :) I'm not going to force-feed localization down anyone's throat myself, and since there are some who seem almost pissed at the idea... Well :) Looks like there's just not a need for it. Anyway... So what of my actual patch we were discussing at some point? I never got a real answer as to if it would be suitable to commit. John -Original Message- From: James Aylett [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 6:36 AM To: 'PHP Developers Mailing List' Subject: RE: [PHP-DEV] [PATCH] Redirect on Error From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On What is so hard to understand in word 'FATAL'? If your script doesn't work, what use is it to make it show the cryptic 500 error?? I'm -10 for adding anything like this, even if and even more then if it's optional. Returning a 500 is one of the easiest ways to automatically audit of fatal problems in your script, because it is (usually) pretty trivial to grab such status codes out of the access log. This is incredibly useful in build and test environments (we have automated processes trawling the logs on our dev, stage and production servers looking for problems). Indeed, you could go a step further with an ISAPI or Apache custom error handler (and presumably NSAPI, which I don't have experience of) to have immediate notification (useful if you've got a bunch of non-technical people testing out an interface). From a user point of view, you can return an entity (say, an HTML page) with a 500 error. Yes, this requires output buffering, but since this is all being mooted as an optional variant on error handling, that really shouldn't be counted against it. From the point of view of a non-human agent accessing such a page, you really /should/ return 500 so it's obvious that the request wasn't serviced properly. Returning an unparseable mess of pseudo-HTML really isn't useful in that many circumstances. I'm not qualified to comment on how feasible this sort of thing is for PHP, especially on all the SAPIs it supports, but as a user of PHP it is an option I'd be interested in. Cheers, James --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.370 / Virus Database: 205 - Release Date: 05/06/2002 ___ _ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ _ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Concrete suggestion re: i18n messages
On Tue, 26 Nov 2002, Wez Furlong wrote: If I wanted localized error messages, then this would be the way to do it. Perhaps merging this with the php_error_docref might be slightly better. However, I'm personally -1000 on such things; there are many reasons, most of them have already been raised here, so I won't repeat them now, but the main issue is with the maintainability of such a thing; localization is very hard to maintain on a volunteer basis (just look at our manual). For something as important as error messages, it is better to have the definitive error message in english and then take advantage of the hyperlink generated by php_error_docref which will display more detailed information in the localized manual. +insert very big number here for this. It's already there, so let's use it and forget this nonsense of adding some extra work for developers. --Jani --Wez. On Tue, 26 Nov 2002, Sascha Schumann 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. There, simple and straight-forward. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- - For Sale! - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: V API Ä
what's this? :)
Did you get interested?
Hmm, it went on like following...
p.s. please keep quiet on this for now though I guess you'll find a lot to
say about :)
Moriyoshi
- translated message begins here -
Hi,
I'm now planning on a new mbstring API as referencing to HEAD on
cvs.php.net and that on sourceforge.jp.
I hope this helps us determine the final API spec so that we can
integrate those two different code bases, though I doesn't mean a faster
development without consensus should come first.
The most significant change you may find is that error number values are
no longer stored in a thread-local structure (tsrm resource). IMO this
could improve code readabilities while it would also make debugging harder.
Besides, I'm trying to add to each API function an argument that is a
pointer to the error reporting function specified by the caller.
The purpose is that we can choose the way in which the error messages
are shown since we cannot invoke a kind of php_error_docref() from
everywhere, as I mentioned.
Your comments will be greatly appreciated.
Regards,
Moriyoshi
- translated message ends -
/*
+--+
| PHP Version 4|
+--+
| Copyright (c) 1997-2002 The PHP Group|
+--+
| This source file is subject to version 2.02 of the PHP license, |
| that is bundled with this package in the file LICENSE, and is|
| available at through the world-wide-web at |
| http://www.php.net/license/2_02.txt. |
| If you did not receive a copy of the PHP license and are unable to |
| obtain it through the world-wide-web, please send a note to |
| [EMAIL PROTECTED] so we can mail you a copy immediately. |
+--+
| Author: Moriyoshi Koizumi [EMAIL PROTECTED]|
+--+
*/
/* $Id$ */
#ifndef _PHP_MB_API_H
#define _PHP_MB_API_H
#include php.h
#if HAVE_MBSTRING
/* {{{ includes */
#ifdef USE_MBSTRING1
# include mbfilter.h
#endif /* USE_MBSTRING1 */
/* }}} */
/* {{{ type definitions */
/* {{{ typedef enum php_mb_err_t */
typedef enum _php_mb_err_t {
PHP_MB_FAILURE = -1,
PHP_MB_SUCCESS = 0,
PHP_MB_ERR_NO_MEMORY,
PHP_MB_ERR_NULL_POINTER,
PHP_MB_ERR_BUFFER_OVER_FLOW,
PHP_MB_ERR_UNSUPPORTED_ENCODING,
PHP_MB_ERR_UNSUPPORTED_LANGUAGE,
PHP_MB_ERR_UNSUPPORTED_CONVERT,
PHP_MB_ERR_UNSUPPORTED_IDENTIFY,
PHP_MB_ERR_ILLEGAL_ARGUMENT,
PHP_MB_ERR_MISSING_PROPERTY,
PHP_MB_ERR_INDEX_OUT_OF_BOUNDS,
PHP_MB_ERR_ENCODING_DETECT_FAILURE,
PHP_MB_ERR_NOT_FOUND,
PHP_MB_ERR_NOT_IMPLEMENTED
} php_mb_err_t;
/* }}} */
#ifdef USE_MBSTRING1 /* compatibility stuff */
typedef mbfl_no_encoding php_mb_encid;
typedef mbfl_encoding php_mb_enc;
typedef mbfl_language php_mb_lang;
#define php_mb_langid_invalid mbfl_no_language_invalid
#define php_mb_langid_neutral mbfl_no_language_neutral
#define php_mb_langid_jajp mbfl_no_language_japanese
#define php_mb_langid_enuk mbfl_no_language_english
#define php_mb_langid_enus mbfl_no_language_english
#define php_mb_langid_kokr mbfl_no_language_korean
#define php_mb_langid_zhcn mbfl_no_language_simplied_chinese
#define php_mb_langid_zhtw mbfl_no_language_traditional_chinese
#define php_mb_encid_invalidmbfl_no_encoding_invalid
#define php_mb_encid_pass mbfl_no_encoding_pass
#define php_mb_encid_auto mbfl_no_encoding_auto
#define php_mb_encid_wchar mbfl_no_encoding_wchar
#define php_mb_encid_byte2bembfl_no_encoding_byte2be
#define php_mb_encid_byte2lembfl_no_encoding_byte2le
#define php_mb_encid_byte4bembfl_no_encoding_byte4be
#define php_mb_encid_byte4lembfl_no_encoding_byte4le
#define php_mb_encid_base64 mbfl_no_encoding_base64
#define php_mb_encid_uuencode mbfl_no_encoding_uuencode
#define php_mb_encid_qprint mbfl_no_encoding_qprint
#define php_mb_encid_7bit mbfl_no_encoding_7bit
#define php_mb_encid_8bit mbfl_no_encoding_8bit
#define php_mb_encid_ucs4 mbfl_no_encoding_ucs4
#define php_mb_encid_ucs4be mbfl_no_encoding_ucs4be
#define php_mb_encid_ucs4le mbfl_no_encoding_ucs4le
#define php_mb_encid_ucs2 mbfl_no_encoding_ucs2
#define php_mb_encid_ucs2be mbfl_no_encoding_ucs2be
#define php_mb_encid_ucs2le mbfl_no_encoding_ucs2le
#define php_mb_encid_utf32 mbfl_no_encoding_utf32
#define php_mb_encid_utf32bembfl_no_encoding_utf32be
#define php_mb_encid_utf32le
Re: [PHP-DEV] php bugs (Chinese word display problem)-help
Hi, Samuel As far as I know, CP936 characters which is commonly used in MS products are basically not allowed to use in PHP scripts. You have to use UTF-8 encoding in such case. Anyway, this is wrong list for this kind of question, so better ask this at [EMAIL PROTECTED] Regards, Moriyoshi [EMAIL PROTECTED] wrote: Hi, everyone: I am a Chinese, I am a programmer. I encounter a problem about php. Attachment is 1.php, when i open this file (this file is saved at linux server, apache and php 4.2.3 are installed on this server) in Internet Explorer, error displays: Parse error: parse error, expecting `','' or `';'' in /usr/3give/test/1.php on line 5 (If your computer is windows 2000, and Simplify Chinese and Traditional chinese language are installed) you will read the Chinese word. I found that if the hex code for Chinese word ends with '5C', then the error will exist. Anymore, if I input a Chinese word which hex code ends with '5C' in the database field, then the display result will add a suffix '\', for example, if i input Î , it will display Î \ at the browser (Internet explorer). I don't know why this problem exist, can you solve this problem for us? Contact me by: [EMAIL PROTECTED]; (86)755-27232311-samuel Best regards Thanks. Samuel -- 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] CVS Account Request: xnoguer
Maintaining PEAR::Spreadsheet_Excel_Writer package -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] radius extension
Hi, Chandler, Jacob R schrieb: Is this to connect to a radius server? If so, there is no need to write yes. an extension for this. I have written one that will use all built in php functions so that there are no additional libraries necessary. Currently, it only connects to the specified server and authenticates, but it is written as a class and could be easily extended. My idea was to write just a wrapper for an existing implementation and not to spend so much time for re-implementing a radius-client-lib. The quality of this library is very good (its a part of FreeBSD) and it implements radius with all features (auth, accounting), also vendor-specific (MSoft, ...) parts are implemented. Implementing a full featured radius-lib is a very time expensive task. I imported the lib into the extension dir, therefore no external libs are used. I also can easy re-import the lib if changes (bugfixes) has been made. Of course having a class just written in php has also his advantages. Why can't exist both together? bye, -- --- -- Michael Bretterklieber - [EMAIL PROTECTED] JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200 -- privat A-8041 GRAZ GSM: ++43-(0)676-93 96 698 Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED] Fax: ++43-(0)316-403274-10 http://www.inode.at/mbretter --- -- ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 -- 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
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.
Agreed.. The default messages stay in the source code and
are easily reachable for the developer.
(That is something I very much dislike about the current
phpdoc organization. Every time I want to change something
in the main English documentation, I need to hunt around for
remote, well-hidden xml files. The docs were more
up-to-date, if these files were easier to access.)
Please explain this a little more with a few specific
examples. And please write the phpdoc list with these
concerns. Maybe the structure can be further explained
in the doc HOWTO. Sometimes I find going to the URL of
the manual page helps figure out the location:
www.php.net/manual/en/language.variables.predefined.php
en/language/variables.xml
www.php.net/manual/en/tokens.php
en/appendices/tokens.xml (note it's in appendix in manual)
Finding functions and extension information is easy since the
big change about seven months ago, for example:
www.php.net/manual/en/function.{functionname}.xml
en/reference/{extensionname}/functions/{functionname}.xml
www.php.net/manual/en/ref.{extensionname}.php
en/reference/{extensionname}/reference.xml
Adding functions is simple, just go into the appropriate
extensions function directory and add the xml file. On
a related note, the change/split that happened awhile back:
Old: en/functions/{extension}.xml
New: en/reference/{extension}/functions/{function}.xml
/ini.xml
/reference.xml
/constants.xml
/functions.xml (autogenerated)
Don't edit functions.xml as it's an autogenerated list. Also
note that the Old files are still in CVS for historical and
archival purposes (the changelogs).
It does take a little getting used to but let's discuss it
a little so php-dev people will feel more comfortable. It
now seems intuitive to me although it's not perfect and
changes are still in progress. For example finding some
of the configuration directives can be difficult...
Regards,
Philip
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[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-DEV] apache/cgi problems with path_info and discard-path
I ran into a problem with path_info using apache2/mod_fastcgi, so I configured apache to use php as regular cgi, and have the same exact problems. There are basicly two problems, first, --discard-path causes PHP to parse itself rather than the script, so I think discard-path is basicly a bad idea. You cannot use --discard-path with apache and cgi. The second is that (after compiling without --discard-path) path_info does not work: works: http://localhost/info.php fails with 500 error: http://localhost/info.php/test My apache config is: ScriptAlias /php/ /path/to/php/bin/ AddType application/x-httpd-php .php Action application/x-httpd-php /php/php-cgi What happens is that php tries to parse the file /info.php/test rather than /info.php. Basicly, mod_cgi and mod_fastcgi do not provide the correct information for several environment variables to php when configured this way. path_info, path_translated, script_name and script_filename are all wrong. According to CGI specs (linked to from apache docs), with the url http://localhost/info.php/test?a=b I *should* get: PATH_INFO=/test PATH_TRANSLATED=/docroot/test SCRIPT_NAME=/info.php REQUEST_URI=/info.php/test?a=b SCRIPT_FILENAME=/docroot/info.php QUERY_STRING=a=b REQUEST_URI and SCRIPT_FILENAME are not part of CGI spec, but are apache specific. What I *really* get is: PATH_INFO=/info.php/test PATH_TRANSLATED=/docroot/info.php/test SCRIPT_NAME=/php/php-cgi (from the Action setting I suppose) REQUEST_URI=/info.php/test?a=b SCRIPT_FILENAME=/path/to/php/bin/php-cgi (Action setting translated) QUERY_STRING=a=b Further, PATH_INFO should always be empty if no extra path info is used in the request (ie. http://localhost/info.php). PHP_SELF is also quite wrong since it is basicly PATH_INFO. Now, if I set up PHP to use the CGI handler in this way: Options +ExecCGI AddHandler cgi-script .php And add a bang line to my script: #!/path/to/php-cgi I get the correct settings (well, I did that with perl and it gets the correct stuff, so php should as well). However having to do this is evil, since PHP apps typically do not have the bang line, we keep changing the executable names, people install php to different locations, and so forth. I also beleive this is the same reason path_info has never worked in cgi under IIS. So, unless anyone has a better idea, or my apache config is extremely wrong, I'm going to rip apart the whole file handling situation in php-cgi and fix it to work right, and provide the correct CGI spec'd values. This will involve parsing the above variables, figuring out what the right settings are, doing at least one stat() call (more if extra path_info is used), and modifying the environment prior to calling php_request_startup. This will also fix my fastcgi problem as they are the same. I already have part of the patch done that fix path_info and path_translated. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Redirect on Error (not localisation)
Unless told otherwise, I'm already planning on making a few changes and committing. John -Original Message- From: Ivan Ristic [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 26, 2002 2:50 PM To: [EMAIL PROTECTED] Cc: 'James Aylett'; 'PHP Developers Mailing List' Subject: [PHP-DEV] Redirect on Error (not localisation) Anyway... So what of my actual patch we were discussing at some point? I never got a real answer as to if it would be suitable to commit. I have changed the subject of the message in an effort to separate the discussion on the Redirect on Fatal Error feature (the subject of this email) from the localisation discussion. ... As a reminder, we are discussing a patch that will redirect the user to another page when a fatal or a parse error occurs (parse errors can be caught with lint, fatal can't). The redirection will allow developers to: * Show a decent page to the user (instead of letting them see a blank or incomplete page) * Send a message to themselves that something strange has happened (allowing them to react quickly, instead of having to install log watch software for notification purposes (and many people cannot do that as they do not have control over the servers)) As far as I am aware, there is not a single reason not to have this feature. Some people seem not to like it, but that is fine; with no performance or stability risks, if you don't want to use the feature - you won't be affected. On the other hand, I will be extremely happy to have it under my belt as yet another tool I can use to make my software run better. Please don't tell me that I wouldn't need this feature if I programmed perfectly. Errors happen all the time, no matter what you do trying to prevent them. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
