[PHP-DEV] Re: #20035 [Asn-Opn]: __LINE__ miscounts with #!/path/php scripts
Er...You propably know then where this stripping happens in PHP or Zend ?? (I couldn't find it..) --Jani On 23 Oct 2002 [EMAIL PROTECTED] wrote: ID: 20035 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Open -Bug Type: Documentation problem +Bug Type: Scripting Engine problem Operating System: OpenBSD 3.1 PHP Version: 4.2.3 Assigned To: hholzgra New Comment: The shebang line doesn't get stripped off by the kernel, PHP does that. This is a bug. Previous Comments: [2002-10-23 00:44:20] [EMAIL PROTECTED] Your kernel strips the first line, and so PHP sees the last 3 lines. As it doesn't know that the kernel stripped the first shebang line it's obvious that your line 3 reports line 2. Derick [2002-10-22 20:25:37] [EMAIL PROTECTED] Excuse me, but I don't understand why this isn't a bug. The only reference to __LINE__ I can find in the documentation is here: http://www.php.net/manual/en/language.constants.php I can find nothing that suggests it is reasonable that __LINE__ counts are off by one when used in #! prefixed command line scripts, (but not in other uses) and I can see no reason why this would be considered reasonable behaviour. Can someone give me at least a 1 sentence explanation instead of just hitting the 'quick-fix' RTFM button? [2002-10-22 19:39:04] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2002-10-22 19:34:54] [EMAIL PROTECTED] The built-in variable __LINE__ undercounts by 1 on command-line scripts that begin with a #!path-to-php line. For example: #!/usr/local/bin/php -q ?php echo Line 3 reports .__LINE__.\n; ? This script will output: Line 3 reports 2 This issue also applies to (at least) some other 4.1+ releases. -- - For Sale! - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global
Jon Parise wrote: I still do not understand what magical values in php.ini-dist need to be applied to run-tests.php and why those values, if they are so important, can't be explicitly enabled via ini_set() calls. Glad to explain :) If you install php.ini-recommended as you default php.ini for CLI, the output is buffered since buffering is enabled in php.ini-recommended. This is very frustrating since I see output with 4096 byte chunks. i.e. type make test, then many seconds later, I see first chunk of outputs at once. We should make it execute run-tests.php well with php.ini-recommend, since it's shipped with PHP. The reason why I suggesting to use php.ini-dist is even person who has CVS account don't understand this. AND I'm not confident nor comfortable writing run-tests.php that runs well under any configuration. (Well I may be able to, but it's a waste of time IMO) Therefore, I'm insisting the use of php.ini-dist many times. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:
Alan Knowles wrote:
Im +1 for reverting the patch - (for what it's worth)
Why?
Well - most 'average' (and below) PHP programmers when attempting to do
CLI programming, will get a serious WTF reaction from wondering why when
they 'echo' stuff, it doesnt appear. The more advanced Users can
manually turn off flushing, but for most small, quick scripts (eg.
50%+), this instant flush is going to be perfectly acceptable..
This makes 2+ for having auto flushing :)
BTW, real language (i.e. not shell) don't flush. Please let me
know if there is real language that do automatic flushing by
default.
In addition, is it too difficult to write this kind of code?
function prompt($prefix) {
echo $prefix;
flush();
}
I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)
I probably disable automatic flushing almost always.
Why? My script will process XML and other formatted
text almost always. Auto-flushing is useless.
Let's guess something interesting.
How much % of scripts actually needs automatic flushing?
My guess is less than 1%. What is yours?
That said, does it still worth to have?
--
Yasuo Ohgaki
Anyway Just my 2c
Regards
Alan
It's a very _bad_ default. Fortunately, it's not released yet.
That's why I'm against it strongly.
IMO, flushing on every output by default is stupid setting.
If you ever programmed interactive programs, you should know
that unless you're ignorant about efficiency.
I guess my questions are too hard to be understood by you
compare to the last one. Derick, it seems you're alone so far.
http://news.php.net/article.php?group=php.devarticle=89995
Do you finally realize your argument actually did not make sense?
(Unless you need stupid PHP/CLI shell that requires start/end tag
to do anything, of course ;)
I'm going to fix it again unless many people want to make
PHP/CLI behave like a shell rather than programming language.
Alternatively, could you fix it again? (including Makefile.global)
Thank you and I hope this is the last mail about this.
PS: If you would like to write INI independent scripts, I
suggest you to use php.ini-recommended at least. You don't/
didn't know phps crashing and make test does not work well with
php.ini-recommended, nonetheless, you're insisting there is no
problems.
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP and OCI8
On Wed, Oct 23, 2002 at 06:15:19PM +0200, Roderick Groesbeek wrote: Howdy People, Info: === I am witnessing problems with PHP, Apache and OCI8. We have profiles on our Oracle databases, so sessions get sniped if they hang on to long. what do you mean by hang on to long? you can always fiddle with your apache config to make sure you don't have too many inactive oracle-session (when using plogon). else simply don't use plogon. re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Test suite and user space (Was: Re: [PHP-DEV] I hope this is the last email about this :))
At 00:27 24-10-2002, Yasuo Ohgaki wrote:
PS: If you would like to write INI independent scripts, I
suggest you to use php.ini-recommended at least. You don't/
didn't know phps crashing and make test does not work well with
php.ini-recommended, nonetheless, you're insisting there is no
problems.
This is a totally different issue. If ini settings affect the test suite,
it's a bug in the test suite, period. If you depend on a preset environment,
you are testing how things behave in that environment, you are not testing
how that specific build for the __end user__ will behave once installed.
Test authors, can enforce specific settings they need, in the --INI--
section. If other settings affect the tests behavior, it is a good thing (tm)
to know this. It may be totally unexpected and shed light on why certain
bugs surface.
I also removed your statement in README.TESTING, which stated that if a test
fails, the user can see if it's a real bug. There are no maybe's in a test
suite. It's a bug or it isn't. Putting in maybe's makes it's purpose confusing
and unreliable.
This is one of the reasons, that during QA periods, some major bugs are not
uncovered ('file_exists'). People feel like oh well, the test is probably
bogus, and do not report it.
Current work being done on the testsuite is IMO the right direction. Tests for
every function under whatever environment and the option to post to QA so that
the data can now be collected and analyzed.
If you see that the test suite is not working well, with php.ini-recommended,
than please report the tests affected. You don't adjust the road, just because
certain cars, have questionable steering - you fix the cars.
Met vriendelijke groeten / With kind regards,
Webmaster IDG.nl
Melvyn Sopacua
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20035 [Asn-Opn]: __LINE__ miscounts with #!/path/php scripts
hi, (Zeev and Andi, and other core devlopers are surely familiar with this, but maybe I can help, too) the cause of this problem is something like this: (1) in sapi/cgi/cgi_main.c(1118) or sapi/cli/php_cli.c(643), if the very begginig of the script is '#', PHP strips that line. at that time, CG(zend_lineno) is surely incremented. but after that... (2) in open_file_for_scanning() in Zend/zend_language_scanner.l (main() - php_execute_scripts() - zend_execute_scripts() - zend_compile_file() - open_file_for_scannning()), CG(zend_lineno) is reset to 1. so... uhm, fixing this is not so easy, I think. if PHP does not strip first line, PHP just prints that line, because that line should outside of the script. maybe we need some kind of a flag in CG, but it'll be an ugly hack. hmm, any idea? or leave this as the PHP spec? :) Masaki Fujimoto [EMAIL PROTECTED] On Thu, 24 Oct 2002 09:18:04 +0300 (EEST) Jani Taskinen [EMAIL PROTECTED] wrote: Er...You propably know then where this stripping happens in PHP or Zend ?? (I couldn't find it..) --Jani On 23 Oct 2002 [EMAIL PROTECTED] wrote: ID: 20035 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Open -Bug Type: Documentation problem +Bug Type: Scripting Engine problem Operating System: OpenBSD 3.1 PHP Version: 4.2.3 Assigned To: hholzgra New Comment: The shebang line doesn't get stripped off by the kernel, PHP does that. This is a bug. Previous Comments: [2002-10-23 00:44:20] [EMAIL PROTECTED] Your kernel strips the first line, and so PHP sees the last 3 lines. As it doesn't know that the kernel stripped the first shebang line it's obvious that your line 3 reports line 2. Derick [2002-10-22 20:25:37] [EMAIL PROTECTED] Excuse me, but I don't understand why this isn't a bug. The only reference to __LINE__ I can find in the documentation is here: http://www.php.net/manual/en/language.constants.php I can find nothing that suggests it is reasonable that __LINE__ counts are off by one when used in #! prefixed command line scripts, (but not in other uses) and I can see no reason why this would be considered reasonable behaviour. Can someone give me at least a 1 sentence explanation instead of just hitting the 'quick-fix' RTFM button? [2002-10-22 19:39:04] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2002-10-22 19:34:54] [EMAIL PROTECTED] The built-in variable __LINE__ undercounts by 1 on command-line scripts that begin with a #!path-to-php line. For example: #!/usr/local/bin/php -q ?php echo Line 3 reports .__LINE__.\n; ? This script will output: Line 3 reports 2 This issue also applies to (at least) some other 4.1+ releases. -- - For Sale! - -- 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] I hope this is the last email about this :) (was RFC: CLI behave like SH or PERL/RUBY/PYTHON?)
At 02:51 24-10-2002, Alan Knowles wrote: Im +1 for reverting the patch - (for what it's worth) Why? Well - most 'average' (and below) PHP programmers when attempting to do CLI programming, will get a serious WTF reaction from wondering why when they 'echo' stuff, it doesnt appear. The more advanced Users can manually turn off flushing, but for most small, quick scripts (eg. 50%+), this instant flush is going to be perfectly acceptable.. My thoughts exactly. Defaults should work for the masses - it's not like it's enforced behavior, that is irreversible. With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:
At 08:42 24-10-2002, Yasuo Ohgaki wrote: I think this kind of code will be taught at the first class of programming course. (I could be wrong, since I don't know where people learned programming ;) Why do you assume people learned programming? I think Rasmus has made the case for PHP to be a language that solves problems, not be academically correct, many times on this list. With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:
Melvyn Sopacua wrote: At 08:42 24-10-2002, Yasuo Ohgaki wrote: I think this kind of code will be taught at the first class of programming course. (I could be wrong, since I don't know where people learned programming ;) Why do you assume people learned programming? I think Rasmus has made the case for PHP to be a language that solves problems, not be academically correct, many times on this list. Sure, some people just learn programming by themselves. Are you trying to say it justifies to have useless settings for almost all scripts? I hope not. They should learn such simple thing even to be Sunday programmer. Beside, the knowledge is useful for other popular languages, C/C++, Java, Perl, Python, Ruby, etc. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Test suite and user space (Was: Re: [PHP-DEV] I hope this is the last email about this :))
Melvyn Sopacua wrote:
At 00:27 24-10-2002, Yasuo Ohgaki wrote:
PS: If you would like to write INI independent scripts, I
suggest you to use php.ini-recommended at least. You don't/
didn't know phps crashing and make test does not work well with
php.ini-recommended, nonetheless, you're insisting there is no
problems.
This is a totally different issue. If ini settings affect the test suite,
it's a bug in the test suite, period. If you depend on a preset
environment,
you are testing how things behave in that environment, you are not testing
how that specific build for the __end user__ will behave once installed.
Do you realize php.ini used by run-tests.php and phpt differs?
Nothing to do with between them.
Test authors, can enforce specific settings they need, in the --INI--
section. If other settings affect the tests behavior, it is a good thing
(tm)
to know this. It may be totally unexpected and shed light on why certain
bugs surface.
I'm writing the same thing _number_ of times
Do you realize php.ini used by run-tests.php and phpt differs?
Nothing to do with between them.
I also removed your statement in README.TESTING, which stated that if a
test
fails, the user can see if it's a real bug. There are no maybe's in a test
suite. It's a bug or it isn't. Putting in maybe's makes it's purpose
confusing
and unreliable.
That's fine. When I wrote it, there were more than 30% of failed tests
due to improper maintenance of phpt, etc. It was unrealistic to check
them all at that time. I guess you don't know this fact.
This is one of the reasons, that during QA periods, some major bugs are not
uncovered ('file_exists'). People feel like oh well, the test is probably
bogus, and do not report it.
Current work being done on the testsuite is IMO the right direction.
Tests for
every function under whatever environment and the option to post to QA
so that
the data can now be collected and analyzed.
It should be.
That's why I wrote README.TESTING to make test suite better.
If the more people understood tests, the more people help to
maintain ;)
If you see that the test suite is not working well, with
php.ini-recommended,
than please report the tests affected. You don't adjust the road, just
because
certain cars, have questionable steering - you fix the cars.
Do you realize php.ini used by run-tests.php and phpt differs?
Nothing to do with between them.
The more I get reply, the more I believe we should specify
php.ini-dist for run-tests.php. i.e. People are confused.
We do test with phpt, but we shouldn't test run-tests.php.
It's just a waste of time.
Remember, Derick removed the -c option, yet he does not understand
the problem with it, even if I've clearly mentioned _MANY_ times.
This incident is enough to illustrate that people cannot write ini
dependent script even if one has CVS account.
Sometimes simple things became harder to understand...
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was RFC:
At 16:42 10/24/2002 +0900, Yasuo Ohgaki wrote:
Melvyn Sopacua wrote:
At 08:42 24-10-2002, Yasuo Ohgaki wrote:
I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)
Why do you assume people learned programming?
I think Rasmus has made the case for PHP to be a language that
solves problems, not be academically correct, many times on this
list.
Sure, some people just learn programming by themselves.
Indeed.
Are you trying to say it justifies to have useless settings for
almost all scripts? I hope not.
No, it justifies less academically correct __overridable defaults__, which are
intuitive for beginners.
Let me emphasize overridable defaults again, just to make sure you get
that I mean overridable defaults.
They should learn such simple thing even to be Sunday programmer.
Beside, the knowledge is useful for other popular languages, C/C++,
Java, Perl, Python, Ruby, etc.
Don't assume people ambition a career in programming, just because they use
a tool, to solve a specific problem they're facing.
/MELVYN
void wakeup() {
for(unsigned int cuppajava;drink();cuppajava++);
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was
Melvyn Sopacua wrote: At 02:51 24-10-2002, Alan Knowles wrote: Im +1 for reverting the patch - (for what it's worth) Why? Well - most 'average' (and below) PHP programmers when attempting to do CLI programming, will get a serious WTF reaction from wondering why when they 'echo' stuff, it doesnt appear. The more advanced Users can manually turn off flushing, but for most small, quick scripts (eg. 50%+), this instant flush is going to be perfectly acceptable.. My thoughts exactly. Defaults should work for the masses - it's not like it's enforced behavior, that is irreversible. ? Which mass ? Are you going to insist most scripts need inefficient auto flushing? Have you ever used other programming languages? I don't get it, but this is the 3rd vote. Too few still and reasoning is too weak. BTW, if anyone would like to vote for inefficient/mostly useless auto flushing. Please add your vote to this article. http://news.php.net/article.php?group=php.devarticle=89995 -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was
On Thu, 24 Oct 2002, Yasuo Ohgaki wrote: Melvyn Sopacua wrote: My thoughts exactly. Defaults should work for the masses - it's not like it's enforced behavior, that is irreversible. ? Which mass ? Are you going to insist most scripts need inefficient auto flushing? __ __ \ \ / /__ ___ \ V / _ \/ __| | | __/\__ \ |_|\___||___/ , because it is inituitive for a COMMAND line interface to flush after every outputted character. If you DONT want this inituitive bahavior you _can_ override it _anytime_ you want. Have you ever used other programming languages? Tons of them, starting with pascal about 10 years ago, and did certainly flush after every character. I don't get it, but this is the 3rd vote. Too few still and reasoning is too weak. As you're clearly not listening to other people's comments I'm going to put that line back into php_cli.c as the only flawed reasoning is yours. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ? vs. ?php - a statistic
We have heard a lot of anecdotal evidence about the usage of ? vs. ?php vs. other methods of PHP invocation. In order to clear things up a little, I have asked a friend of mine for more detailed numbers from a real world example. The following tests have been done very much ad hoc, and the numbers are not representative. They have been made across the PHP files found at a very large german provider. The test has been running for a night until he killed it, and the friend estimated that a full run across several million domains would take about 10 days to complete. He did not do anything to filter out standard scripts such as phpMyAdmin, nor did he do anything else to postprocess the numbers. The following numbers have been generated by find and grep for all lines that have something that resembles a PHP opening tag. These lines have then been categorized and counted. The total result set had a size of approx. 1.3 million lines. ?php 84% ?=3% ?12% % 0,3% script... 37ppm If you can come up with a script or a program that a) performs and b) can take the output of find at stdin, I will ask for a more detailed statistic. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ? vs. ?php - a statistic
I don't think that matters that much really. Even if it's 2%, and not 12% or 50%, we're still talking about billions of lines of code... Let's, please, give it a rest. Zeev At 11:13 24/10/2002, Kristian Koehntopp wrote: We have heard a lot of anecdotal evidence about the usage of ? vs. ?php vs. other methods of PHP invocation. In order to clear things up a little, I have asked a friend of mine for more detailed numbers from a real world example. The following tests have been done very much ad hoc, and the numbers are not representative. They have been made across the PHP files found at a very large german provider. The test has been running for a night until he killed it, and the friend estimated that a full run across several million domains would take about 10 days to complete. He did not do anything to filter out standard scripts such as phpMyAdmin, nor did he do anything else to postprocess the numbers. The following numbers have been generated by find and grep for all lines that have something that resembles a PHP opening tag. These lines have then been categorized and counted. The total result set had a size of approx. 1.3 million lines. ?php 84% ?=3% ?12% % 0,3% DEFANGED_script... 37ppm If you can come up with a script or a program that a) performs and b) can take the output of find at stdin, I will ask for a more detailed statistic. Kristian -- 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] I hope this is the last email about this :) (was RFC:
This has nothing to do with academical correctness. Flushing or not flushing is not a matter of right or wrong, it's a matter of choice. There's one 'real language' that does automatic flushing, it's called PHP, and it's going to stay that way. Why other languages chose not to do it (maybe they don't have the facilities to do it?) is beside the point and not all that interesting. Thank you. Zeev At 09:17 24/10/2002, Melvyn Sopacua wrote: At 08:42 24-10-2002, Yasuo Ohgaki wrote: I think this kind of code will be taught at the first class of programming course. (I could be wrong, since I don't know where people learned programming ;) Why do you assume people learned programming? I think Rasmus has made the case for PHP to be a language that solves problems, not be academically correct, many times on this list. With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :) (was
At 10:01 24/10/2002, Yasuo Ohgaki wrote: Melvyn Sopacua wrote: At 02:51 24-10-2002, Alan Knowles wrote: Im +1 for reverting the patch - (for what it's worth) Why? Well - most 'average' (and below) PHP programmers when attempting to do CLI programming, will get a serious WTF reaction from wondering why when they 'echo' stuff, it doesnt appear. The more advanced Users can manually turn off flushing, but for most small, quick scripts (eg. 50%+), this instant flush is going to be perfectly acceptable.. My thoughts exactly. Defaults should work for the masses - it's not like it's enforced behavior, that is irreversible. ? Which mass ? Are you going to insist most scripts need inefficient auto flushing? Have you ever used other programming languages? I don't get it, but this is the 3rd vote. Too few still and reasoning is too weak. Too few? It's 3 times more than the votes in favour, and now it's 4 times more. Too weak? That's your opinion, and it doesn't weigh more than others'. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ? vs. ?php - a statistic
On Thursday 24 October 2002 11:28, Zeev Suraski wrote: I don't think that matters that much really. Even if it's 2%, and not 12% or 50%, we're still talking about billions of lines of code... Yes, we do. I am still offering the opportunity to run a statistical analysis of choice across a very large assembly of real world PHP use for all of you, provided you come up with a script that does the counting. This is not limited to ?-matters at all. Kristian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] running tests with CGI binary
fact #1: some tests *require* cgi sapi (eg. POST stuff)
fact #2: current test suid *does not work* with php-cgi
conclusion: a lot of stuff doesn't get any automatic testing
solution: (see attached patch)
- run-tests.php sets USER_AGENT=run-tests.php
- run-tests.php prepends testcode with chdir()
- php-cgi falls back to argc/argv parsing even
if in cgi mode when USER_AGENT=run-tests.php
with the patch applied the following works again:
export TEST_PHP_EXECUTABLE=sapi/cgi/php-cgi
sapi/cli/php run-tests.php
comments? ;)
-8-
Index: run-tests.php
===
RCS file: /repository/php4/run-tests.php,v
retrieving revision 1.83
diff -u -2 -r1.83 run-tests.php
--- run-tests.php 23 Oct 2002 12:54:57 - 1.83
+++ run-tests.php 24 Oct 2002 09:26:06 -
@@ -83,4 +83,6 @@
}
+$php = realpath($php);
+
// Check whether a detailed log is wanted.
if (getenv('TEST_PHP_DETAILED')) {
@@ -425,4 +427,5 @@
// Reset environment from any previous test.
+ putenv(USER_AGENT=run-tests.php);
putenv(REDIRECT_STATUS=);
putenv(QUERY_STRING=);
@@ -437,7 +440,8 @@
if (trim($section_text['SKIPIF'])) {
save_text($tmp_skipif, $section_text['SKIPIF']);
- $output = `$php $tmp_skipif`;
+ putenv(PATH_TRANSLATED=$tmp_skipif);
+ $output = `$php -q $tmp_skipif`;
@unlink($tmp_skipif);
- if (ereg(^skip, trim($output))){
+ if (ereg(^skip, $output)){
echo SKIP $tested;
$reason = (ereg(^skip[[:space:]]*(.+)\$, trim(
$output))) ? ereg_replace(^skip[[:space:]]*(.+)\$, \\1, trim($output)) : FAL
SE;
@@ -478,5 +482,5 @@
// We've satisfied the preconditions - run the test!
- save_text($tmp_file,$section_text['FILE']);
+ save_text($tmp_file,?php chdir('.getcwd().'); ? . $section_text['F
ILE']);
if (array_key_exists('GET', $section_text)) {
$query_string = trim($section_text['GET']);
@@ -502,6 +506,5 @@
putenv(CONTENT_LENGTH=$content_length);
- $cmd = $php$ini_settings -f $tmp_file 21 $tmp_post;
-
+ $cmd = $php -q $ini_settings -f $tmp_file 21 . realpath($t
mp_post);
} else {
@@ -510,5 +513,5 @@
putenv(CONTENT_LENGTH=);
- $cmd = $php$ini_settings -f $tmp_file$args 21;
+ $cmd = $php -q $ini_settings -f $tmp_file$args 21;
}
@@ -524,6 +527,6 @@
;
- $out = `$cmd`;
-
+ $out = `$cmd`;
+
@unlink($tmp_post);
Index: sapi/cgi/cgi_main.c
===
RCS file: /repository/php4/sapi/cgi/cgi_main.c,v
retrieving revision 1.183
diff -u -2 -r1.183 cgi_main.c
--- sapi/cgi/cgi_main.c 13 Oct 2002 09:40:44 - 1.183
+++ sapi/cgi/cgi_main.c 24 Oct 2002 09:26:06 -
@@ -523,5 +523,5 @@
{
int exit_status = SUCCESS;
- int cgi = 0, c, i, len;
+ int cgi = 0, c, i, len, testmode = 0;
zend_file_handle file_handle;
int retval = FAILURE;
@@ -574,4 +574,8 @@
#endif
+#ifndef PHP_FASTCGI
+ s = getenv(USER_AGENT);
+ if(s !strcmp(s, run-tests.php)) testmode = 1;
+#endif
#ifdef ZTS
@@ -876,9 +880,9 @@
zend_llist_init(global_vars, sizeof(char *), NULL, 0);
- if (!cgi
+ if ( testmode || (!cgi
#ifdef PHP_FASTCGI
!fastcgi
#endif
- ) { /* never execute
the arguments if you are a CGI */
+ )) { /* never execute the arguments if you are a CGI unl
ess in testmode*/
if (SG(request_info).argv0) {
free(SG(request_info).argv0);
--
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe
Email: [EMAIL PROTECTED]
Tel.: +49-711-99091-77
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP usage stats
I think we should listen to Kristian here. It's never bad having some statistics about PHP usage. P.S: changins the subject. Other seem not to work too well. I Wonder why :) -- Maxim Maletsky [EMAIL PROTECTED] www.PHPBeginner.com // PHP for Beginners www.maxim.cx // my Home // my Wish List: ( Get me something! ) http://www.amazon.com/exec/obidos/registry/2IXE7SMI5EDI3 Kristian Koehntopp [EMAIL PROTECTED] wrote... : On Thursday 24 October 2002 11:28, Zeev Suraski wrote: I don't think that matters that much really. Even if it's 2%, and not 12% or 50%, we're still talking about billions of lines of code... Yes, we do. I am still offering the opportunity to run a statistical analysis of choice across a very large assembly of real world PHP use for all of you, provided you come up with a script that does the counting. This is not limited to ?-matters at all. Kristian -- 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] I hope this is the last email about this :)
Zeev Suraski wrote:
At 10:01 24/10/2002, Yasuo Ohgaki wrote:
Melvyn Sopacua wrote:
At 02:51 24-10-2002, Alan Knowles wrote:
Im +1 for reverting the patch - (for what it's worth)
Why?
Well - most 'average' (and below) PHP programmers when attempting to
do CLI programming, will get a serious WTF reaction from wondering
why when they 'echo' stuff, it doesnt appear. The more advanced
Users can manually turn off flushing, but for most small, quick
scripts (eg. 50%+), this instant flush is going to be perfectly
acceptable..
My thoughts exactly. Defaults should work for the masses - it's not
like it's enforced behavior, that is irreversible.
? Which mass ?
Are you going to insist most scripts need inefficient auto flushing?
Have you ever used other programming languages?
I don't get it, but this is the 3rd vote.
Too few still and reasoning is too weak.
Too few? It's 3 times more than the votes in favour, and now it's 4
times more. Too weak? That's your opinion, and it doesn't weigh more
than others'.
I'm mentioning weakness of reasoning. At least, I was tried to ;)
My thoughts exactly. Defaults should work for the masses - it's not
like it's enforced behavior, that is irreversible.
implies most/many scripts/users need additional flushing.
This is obviously wrong.
Only very small portion of scripts need flushing for every outputs.
(I'm guessing, but nobody objects right?)
Even when flushing is needed
function prompt($prefix) {
echo $prefix;
flush();
}
is _TRIVIAL_ to write. People should have this kind of
function instead of enabling inefficient implicit flushing
since it's more efficient and reliable.
Therefore, "enabling it for the *mass*/ intuitive for users"
does not make sense, hence weak reasoning.
If implicit flush is preferred for some scripts, it should be
enabled when it is needed because the needs is obviously fewer.
I agree, it's a choice but there is good and bad even
if it's not clear sometimes.
Why don't we follow simple rule "more needs" = default,
"less needs" = optional especially when it's easy to switch.
(we haven't released it yet :)
BTW, please vote to this thread. It easier to follow who is
voting for.
http://news.php.net/article.php?group=php.devarticle=89995
Anyway, what kind of default we have for implicit flush in
php.ini-dest/recommended now and in the future? We have _OFF_
by default. It also help us to make better decision, IMO.
Default OFF is more intuitive, IMHO.
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
Just wanted to add little more emphasis for the reason why I say "weak reasoning". My thoughts exactly. Defaults should work for the masses - it's not like it's enforced behavior, that is irreversible. Anyway, what kind of default we have for implicit flush in php.ini-dest/recommended now and in the future? We have _OFF_ by default. It also help us to make better decision, IMO. Default OFF is more intuitive, IMHO. I'm talking virtually all current users who are used to implicit_flush=Off by default. This should be called the *MASSES*. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] running tests with CGI binary
On Thu, 24 Oct 2002, Hartmut Holzgraefe wrote:
comments? ;)
sure :)
-8-
Index: run-tests.php
===
RCS file: /repository/php4/run-tests.php,v
retrieving revision 1.83
diff -u -2 -r1.83 run-tests.php
--- run-tests.php 23 Oct 2002 12:54:57 - 1.83
+++ run-tests.php 24 Oct 2002 09:26:06 -
-83,4 +83,6
}
+$php = realpath($php);
+
// Check whether a detailed log is wanted.
if (getenv('TEST_PHP_DETAILED')) {
-425,4 +427,5
// Reset environment from any previous test.
+ putenv(USER_AGENT=run-tests.php);
putenv(REDIRECT_STATUS=);
putenv(QUERY_STRING=);
-437,7 +440,8
if (trim($section_text['SKIPIF'])) {
save_text($tmp_skipif, $section_text['SKIPIF']);
- $output = `$php $tmp_skipif`;
+ putenv(PATH_TRANSLATED=$tmp_skipif);
+ $output = `$php -q $tmp_skipif`;
unlink($tmp_skipif);
- if (ereg(^skip, trim($output))){
+ if (ereg(^skip, $output)){
This trim was added for a reason, did you check if that broke any tests?
echo SKIP $tested;
$reason = (ereg(^skip[[:space:]]*(.+)\$, trim(
$output))) ? ereg_replace(^skip[[:space:]]*(.+)\$, \\1, trim($output)) : FAL
SE;
-478,5 +482,5
// We've satisfied the preconditions - run the test!
- save_text($tmp_file,$section_text['FILE']);
+ save_text($tmp_file,?php chdir('.getcwd().'); ? .
$section_text['FILE']);
This change is going to break some tests, but you just volunteerd to fix
those:
13:07 hartmut oh, yes ... pathes in the phpt files get easier again ... ;)
13:07 Derick you can only do this if you fix all the tests too :)
13:07 hartmut this was intentional, i only forgot it ;)
13:07 hartmut yes, but that makes standalone tests for phpized extensions possible
13:07 Derick I think it's better to cwd() to the php4/ dir then, where
run-tests.php is
13:08 hartmut so i volunteer
furthermore I propose to apply this patch after pre2, so that we have
more time to adjust the affected scripts where needed.
regards,
Derick
--
---
Derick Rethans http://derickrethans.nl/
JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Upload broken?
Hi, is in the cvs tree the file upload currently broken? I miss the $_FILES['myfile'] variables. Regards, Steve -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_2_0) /ext/bcmath/libbcmath/src config.h
Anantha Kesari H Y wrote: hyanantha Thu Oct 24 05:15:12 2002 EDT Modified files: (Branch: PHP_4_2_0) /php4/ext/bcmath/libbcmath/src config.h Log: NetWare related changes/modifications. Why are all these patches committed to the (dead?) PHP_4_2_0 branch? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changing entity charset handlinginext/standard/html.c
Hey Moriyoshi, Sorry for my late entry into the debate, but I run into htmlentities() default charset problem today. I wonder why did you opt to use mbstring ini setting (thus making this nice feature mbstring dependant) when we have default_charset ini setting. It just sounds more logical to me to use SG(default_charset) for the default charset of htmlentities(). Your thoughts? Edin - Original Message - From: Moriyoshi Koizumi [EMAIL PROTECTED] To: Wez Furlong [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, October 17, 2002 7:48 AM Subject: Re: [PHP-DEV] [PATCH] Changing entity charset handlinginext/standard/html.c Yep, as far as I read the archives, I haven't found any discussions on the charset related backwards problems. So I wrote *exactly* about this issue. You may want to redirect me to bug #9392 (http://bugs.php.net/bug.php?id=9392), but it doens't seem to help... In addition, I found determining the internal charset by LC_CTYPE is dangerous because setlocale() is not thread-safe in some libc implementations (glibc seems to be that one). I'm going to read archives more carefully, though I think even handling the charset in phpinfo() will yield the same discussion in the future. Moriyoshi Koizumi Wez Furlong [EMAIL PROTECTED] wrote: Search the archives for the discussion. phpinfo could determine the charset as your patch does at the start, and then pass the info in php_escape_html_entities. Seems easy to me. --Wez. On 10/16/02, Moriyoshi Koizumi [EMAIL PROTECTED] wrote: Wez Furlong [EMAIL PROTECTED] wrote: Unfortunately, we absolutely must remain 100% backwards compatible with htmlentities(), so this patch should not be applied. Were there any discussions exactly about this issue? Though I have to see some historical reason, however I don't understand why 100% backwards compatibility is required for htmlentities(). Because the patched htmlentities() acts in the same way with default configuration, and IMHO defaulting to iso-8859-1 is quite meaningless for the scripts that uses other charsets than it. Hmm... otherwise I would like to suggest a mbstring function like mb_htmlentities(), but it would sound like a reinvention of the same wheel... However, I don't see a problem with making phpinfo determine the charset and passing that on to the internal htmlentities function? The problem is that php_info_html_esc() in ext/standard/info.c calls php_escape_html_entities() with no charset information specified. Without the patch, every character is treated as ISO-8859-1 even if a fetched character is actually a mere first byte of a multibyte character. Moriyoshi Koizumi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] algebra code
does anyone know where I can get the code to solve equations with three unknowns? eg. 2x+4y+3z=234 3x+2y+44z=70 8x+33y+9z= 8 I need the code to solve for x , y and z Thanks -- Ve mis pinturas - See my paintings:: http://www.nvtechnologies.com/hgh/paintingweb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] algebra code
Get a math text book that explains gaussian elimination, learn it, then ask your question on php-general. This list is for development of php itself, not writing programs with PHP. --Wez. On 10/24/02, Diana Castillo [EMAIL PROTECTED] wrote: does anyone know where I can get the code to solve equations with three unknowns? eg. 2x+4y+3z=234 3x+2y+44z=70 8x+33y+9z= 8 I need the code to solve for x , y and z Thanks -- Ve mis pinturas - See my paintings:: http://www.nvtechnologies.com/hgh/paintingweb -- 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] I hope this is the last email about this :) (was
-Original Message- From: Yasuo Ohgaki [mailto:yohgaki;ohgaki.net] Sent: 24 October 2002 09:01 To: [EMAIL PROTECTED]; Melvyn Sopacua Are you going to insist most scripts need inefficient auto flushing? For CLI, yes. Have you ever used other programming languages? Yes -- over 40 at last count! (Even written the odd compiler in my time!) I don't get it, but this is the 3rd vote. Too few still and reasoning is too weak. BTW, if anyone would like to vote for inefficient/mostly useless auto flushing. Please add your vote to this article. http://news.php.net/article.php?group=php.devarticle=89995 I would, but I can't see any way of replying/voting on the page that URL takes me to...! Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] I hope this is the last email about this :) (was RFC:
-Original Message-
From: Yasuo Ohgaki [mailto:yohgaki;ohgaki.net]
Sent: 24 October 2002 07:42
To: [EMAIL PROTECTED]; Alan Knowles
Alan Knowles wrote:
Im +1 for reverting the patch - (for what it's worth)
This makes 2+ for having auto flushing :)
Add one more -- or even more, as I 'd say I'm +1 for this!
BTW, real language (i.e. not shell) don't flush. Please let me
know if there is real language that do automatic flushing by
default.
But PHP-CLI *is* a shell-scripting language, and therefore should behave
like one. Other flavours of PHP aren't, and shouldn't. QED.
In addition, is it too difficult to write this kind of code?
function prompt($prefix) {
echo $prefix;
flush();
}
I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)
At university: learned half-a-dozen languages; *all* of them flushed streams
open on TTY either after every character, or (at line-end or when input
requested from same device). I've been programming now for over 25 years,
and this is *still* the behaviour I expect by default when programming
command-line-executable scripts or programs.
Let's guess something interesting.
How much % of scripts actually needs automatic flushing?
My guess is less than 1%. What is yours?
For PHP-CLI: more than 90%.
For PHP CGI or SAPI: much less than 1%.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
At 12:23 24/10/2002, Yasuo Ohgaki wrote:
function prompt($prefix) {
echo $prefix;
flush();
}
is _TRIVIAL_ to write. People should have this kind of
function instead of enabling inefficient implicit flushing
since it's more efficient and reliable.
You print something, it doesn't print out. How is it trivial to solve
this? If you happen to know that there's IO buffering and that there's a
function called flush() then maybe it trivial, but then there are the other
million users who don't. Hence the idea of setting is to implicit flush
for the masses, who not only don't know about the existence of flush(), but
also don't know why it's even necessary.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ZE2 compile failure with xml-rpc ext
/bin/sh libtool --silent --mode=compile gcc -I/home/jan/software/php4/ext/xmlrpc/libxmlrpc -DVERSION=0.50 -Iext/xmlrpc/ -I/home/jan/software/php4/ext/xmlrpc/ -DPHP_ATOM_INC -I/home/jan/software/php4/include -I/home/jan/software/php4/main -I/home/jan/software/php4 -I/home/jan/software/php4/Zend -I/usr/include/libxml2 -I/usr/include/freetype2 -I/usr/include/imap -I/usr/include/mcal -I/home/jan/software/php4/ext/xml/expat -DEAPI_MM -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHARD_SERVER_LIMIT=2048 -DDYNAMIC_MODULE_LIMIT=128 -DLINUX=22 -DMOD_SSL=208107 -DEAPI -I/home/jan/software/php4/TSRM -g -O2 -prefer-pic -c /home/jan/software/php4/ext/xmlrpc/xmlrpc-epi-php.c -o ext/xmlrpc/xmlrpc-epi-php.lo /home/jan/software/php4/ext/xmlrpc/xmlrpc-epi-php.c: In function `set_zval_xmlrpc_type': /home/jan/software/php4/ext/xmlrpc/xmlrpc-epi-php.c:1348: structure has no member named `properties' /home/jan/software/php4/ext/xmlrpc/xmlrpc-epi-php.c:1349: structure has no member named `properties' make: *** [ext/xmlrpc/xmlrpc-epi-php.lo] Fehler 1 Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_2_0)/ext/bcmath/libbcmath/src config.h
Hi, NetWare has a very old PHP, version 4.0.8! We are moving to a later stabler version for release on NetWare next month. In that connection Zeev Suraski suggested that we move to 4.2 branch which is significantly more stabler than 4.3 branch. So, I am checking in files for the 4.2 branch so that our sources are in synch there for any possible future releases from that branch. I mentioned this to this group earlier and the mail is attached. We have checked-in most of the files already for the 4.3 branch as well. We will be completing that also soon. Thanks, Ananth. Sebastian Bergmann [EMAIL PROTECTED] 10/24/02 05:22AM Anantha Kesari H Y wrote: hyanantha Thu Oct 24 05:15:12 2002 EDT Modified files: (Branch: PHP_4_2_0) /php4/ext/bcmath/libbcmath/src config.h Log: NetWare related changes/modifications. Why are all these patches committed to the (dead?) PHP_4_2_0 branch? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php ---BeginMessage--- Hi all, I am working on porting PHP onto NetWare. Currently, we are shipping the older version 4.0.8 on NetWare. We are moving to the latest stable version. Zeev Suraski suggested that we move to 4.2 branch since it is significantly more stable than 4.3 branch. So, I would be checking in NetWare patches into the 4.2 source code branch in a few days from now. This is for your information. Thanks, Ananth. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php ---End Message--- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changing entity charset handlinginext/standard/html.c
Hello Edin, I don't know if your proposal is logical or not, I figured the problem in the historical context, that it shouldn't rely on mbstring ext too much because it's been there since mbstring(formerly called as jstring) was introduced. But, It's a problem that the internal encoding is not necessarily the same as the output encoding when mb_output_handler is enabled. So in this sense, giving more priority to mbstring.internal_encoding is quite natural to me. In addition there's a hack in mbstring.c that overrides the Content-Type header whatever the SAPI setting is, when output handler is enabled by the ini setting. I think the real issue is we have two similar options that seem to stay different as long as the ZE's parser doens't support various charsets, at least those which can be handled by the current version of mbstring. You may want to point me out that we already have --enable-zend-multibyte, but it's virtually a hack IMO, and it should be integrated to the core at lower level in the future version. BTW, the temporary solution is to give a priority to each setting, like 1. MBSTRG(internal_encoding) 2. SG(default_charset) 3. System's locale setting How about this option? Moriyoshi Edin Kadribasic [EMAIL PROTECTED] wrote: Hey Moriyoshi, Sorry for my late entry into the debate, but I run into htmlentities() default charset problem today. I wonder why did you opt to use mbstring ini setting (thus making this nice feature mbstring dependant) when we have default_charset ini setting. It just sounds more logical to me to use SG(default_charset) for the default charset of htmlentities(). Your thoughts? Edin - Original Message - From: Moriyoshi Koizumi [EMAIL PROTECTED] To: Wez Furlong [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, October 17, 2002 7:48 AM Subject: Re: [PHP-DEV] [PATCH] Changing entity charset handlinginext/standard/html.c Yep, as far as I read the archives, I haven't found any discussions on the charset related backwards problems. So I wrote *exactly* about this issue. You may want to redirect me to bug #9392 (http://bugs.php.net/bug.php?id=9392), but it doens't seem to help... In addition, I found determining the internal charset by LC_CTYPE is dangerous because setlocale() is not thread-safe in some libc implementations (glibc seems to be that one). I'm going to read archives more carefully, though I think even handling the charset in phpinfo() will yield the same discussion in the future. Moriyoshi Koizumi Wez Furlong [EMAIL PROTECTED] wrote: Search the archives for the discussion. phpinfo could determine the charset as your patch does at the start, and then pass the info in php_escape_html_entities. Seems easy to me. --Wez. On 10/16/02, Moriyoshi Koizumi [EMAIL PROTECTED] wrote: Wez Furlong [EMAIL PROTECTED] wrote: Unfortunately, we absolutely must remain 100% backwards compatible with htmlentities(), so this patch should not be applied. Were there any discussions exactly about this issue? Though I have to see some historical reason, however I don't understand why 100% backwards compatibility is required for htmlentities(). Because the patched htmlentities() acts in the same way with default configuration, and IMHO defaulting to iso-8859-1 is quite meaningless for the scripts that uses other charsets than it. Hmm... otherwise I would like to suggest a mbstring function like mb_htmlentities(), but it would sound like a reinvention of the same wheel... However, I don't see a problem with making phpinfo determine the charset and passing that on to the internal htmlentities function? The problem is that php_info_html_esc() in ext/standard/info.c calls php_escape_html_entities() with no charset information specified. Without the patch, every character is treated as ISO-8859-1 even if a fetched character is actually a mere first byte of a multibyte character. Moriyoshi Koizumi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] -=
What does it mean in the code when it says - = for instance a[k][j] -= a[k][i] * a[i][j] / a[i][i]; thanks, Diana -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] -=
Can you please direct questions like this to the [EMAIL PROTECTED] mailing list, this list is for development _of_ PHP, not for developing _with_ PHP. Thank you, Derick On Thu, 24 Oct 2002, Diana Castillo wrote: What does it mean in the code when it says - = for instance a[k][j] -= a[k][i] * a[i][j] / a[i][i]; thanks, Diana -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] -=
current value minus this. int a = 10; int b = 6; a -= b; now a is 4; But, this is not PHP-DEV question. -- Maxim Maletsky [EMAIL PROTECTED] www.PHPBeginner.com // PHP for Beginners www.maxim.cx // my Home // my Wish List: ( Get me something! ) http://www.amazon.com/exec/obidos/registry/2IXE7SMI5EDI3 Diana Castillo [EMAIL PROTECTED] wrote... : What does it mean in the code when it says - = for instance a[k][j] -= a[k][i] * a[i][j] / a[i][i]; thanks, Diana -- 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] Changing entity charset handlinginext/standard/html.c
BTW, the temporary solution is to give a priority to each setting, like 1. MBSTRG(internal_encoding) 2. SG(default_charset) 3. System's locale setting How about this option? This sounds fine. This way people who compile php without mbstring support can alter the default charset. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_2_0) /ext/bcmath/libbcmath/src config.h
On Thu, Oct 24, 2002 at 07:06:43AM -0600, Ananth Kesari wrote : We have checked-in most of the files already for the 4.3 branch as well. We will be completing that also soon. Congratulations on the work! -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc $ grep docref_root php.ini docref_root = http://landonize.it/?how=urltheme=classicfilter=RichyHuser=imajesurl=http%3A%2F%2Fphp.net%2F/; -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] from one hash to another, in an extension
Andrei Zmievski [EMAIL PROTECTED] writes: On Wed, 23 Oct 2002, Tim Daly, Jr. wrote: You don't need to SEPARATE_ZVAL() in this case. I don't need to, or I need not to? Don't use SEPARATE_ZVAL() when copying zval from one hash to another. -Andrei http://www.gravitonic.com/ Thanks. -Tim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Unsigned Problems Revisited
On Thu, 24 Oct 2002, Andi Gutmans wrote: At 02:49 PM 10/23/2002 -0500, David M. Lloyd wrote: The reality of twos-complement, bitwise arithmatic is that there are three basic shift operations: shift left, bitwise shift right, and arithmetic shift right. This simple fact is one of the basic ideas of dealing with twos-complement integers. I know that but I still wanted the opposite to be available to keep things symmetrical. I'm not sure but I think CPU's do support both logical and arithmetic shifts and just do the same with both (I might be wrong though). Generally no, it's a waste of opcode space for modern CISC processors. RISC processors often have integrated barrel-shifters, so they don't need shift instructions at all. Intel carries over arithmetic shift right instructions from older architetures for backwards-compatibility with x86, but their RISC implementation (Itanium) does not contain support for the operation. One RISC example is ARM. They give you four shift options: Logical left, logical right, arithmetic right, and rotate right. Making the operation symmetrical is a waste of precious bit combinations, and would have meant either losing another shift operation or else adding another bit to the shift operation specifier, which means that another bit would have to be sacrificed elsewhere. Another example is SPARC, which implements shifting with discrete instructions, only implents one left shift operator. PowerPC does not implement it either. Given this fact, there is no reason to have a bogus fourth operator in the name of symmetry. Mathematical operaters are simply not always symmetrical. There is no such thing as 'arithmetic shift left' or 'logical shift left' in terms of twos-complement integers, so why invent it? I agree that they don't *have* to be symmetrical but I think it's better. Better why? Anyone who understands twos-complement will understand (and expect) the ability to do those three operations, and will not be surprised by the lack of two left shifts. I argue that they *should NOT* be symmetrical because it is wrong. Second of all, my understanding of the here-doc operator is that it acts as a unary operation. I don't see the conflict with the binary application of , given the example of unary and binary -, if it is absolutely neccessary to fulfill the (somewhat psychotic) need for symmetry where it is not realy needed, or even strictly correct. psychotic? Can we please have discussions on a professional and not personal level? It is true though, unless you can give me a sound mathematical reason that the ops should exist... and saying it looks right or it is easier is not a valid reason, becuase to those with even basic twos-complement math background, it looks wrong and is not easier. As far as I remember it does clash with here-docs. I'm pretty sure I thought of an example a while back. I can try and think of one again. In any case, I wouldn't want an overloaded operator. We try and keep away of that kind of stuff with PHP. Very well... then let's not put in the nonsense operator, and just have three shift operations: , , and . - D [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Can't build HEAD on Linux
/usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14. /usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14. ext/mysql/libmysql/my_tempnam.lo: In function `my_tempnam': /usr/src/php4/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build HEAD on Linux
Upgraded your GCC? Googles first hit reads something like: FORM 14 is DW_FORM_strp, recently added to GCC. You need a newer binutils. On Thu, Oct 24, 2002 at 11:18:15PM +0200, Sebastian Bergmann wrote : /usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14. /usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14. ext/mysql/libmysql/my_tempnam.lo: In function `my_tempnam': /usr/src/php4/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc $ grep docref_root php.ini docref_root = http://landonize.it/?how=urltheme=classicfilter=RichyHuser=imajesurl=http%3A%2F%2Fphp.net%2F/; -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build HEAD on Linux
Markus Fischer wrote: Upgraded your GCC? Googles first hit reads something like: FORM 14 is DW_FORM_strp, recently added to GCC. You need a newer binutils. Interesting. I updated to gcc 3.2 a while ago and it worked fine. This morning, for instance, I was able to build HEAD without problems. Just now I was able to build httpd-2.0 HEAD without problems. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] linking php code to html link
Hi there, I'm wondering if there is a way to attach a php function to an html a href tag. I basically want to have a button, that when clicked, will execute some PHP code. Thanks, Alan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] cannot read /repository/php4/ext/overload/CVS/fileattr
During a fresh CVS checkout I got the following message cvs server: cannot read /repository/php4/ext/overload/CVS/fileattr: Operation not supported What does this mean? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] linking php code to html link
Alan, PHP-DEV(Internals) is the list for the development OF the PHP Language not WITH the PHP language. The PHP-GENERAL list is what you want. Before emailing this particular question, I would highly suggest you read the documentation available on PHP's website (http://www.php.net), and possibly buy a book. -Jason -- Jason T. Greene [EMAIL PROTECTED] [EMAIL PROTECTED] On Thu, 2002-10-24 at 17:10, Alan Rawkins wrote: Hi there, I'm wondering if there is a way to attach a php function to an html a href tag. I basically want to have a button, that when clicked, will execute some PHP code. Thanks, Alan -- 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] PHP and Java
Hi, I am looking for any info or documentation on using PHP in a servlet environment. I read what I could find on php.net, and found a couple things using google, but not enough to answer my questions. If someone could tell me where to look that would be great. I am very interested in seing PHP more tightly integrated with J2EE as I think that it would add the reliabilty and scalability of the J2EE platform to the ease of use of PHP, and allow a smooth transition for the existing PHP user base, who need to do things with Java. These are the type of questions I have right now: 1) Is this a pure Java version of PHP? 2) What functionality is available? (only core functions? Some extention libraries) 3) How does it all work? (pass thru mechanism? are pages compiled as classes?) 4) Does this make it eiasier to access Java servlets or EJBs? Does it increse performance? 5) Who is responsible for development of this extension? 6) When do you expect a non experimental version will be available Any help would be appreciated. Marc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP and Java
--- Marc Richards [EMAIL PROTECTED] wrote: Hi, I am looking for any info or documentation on using PHP in a servlet environment. I read what I could find on php.net, and found a couple things using google, but not enough to answer my questions. If someone could tell me where to look that would be great. I am very interested in seing PHP more tightly integrated with J2EE as I think that it would add the reliabilty and scalability of the J2EE platform to the ease of use of PHP, and allow a smooth transition for the existing PHP user base, who need to do things with Java. These are the type of questions I have right now: 1) Is this a pure Java version of PHP? No. And why would there be ;) 2) What functionality is available? (only core functions? Some extention libraries) There are 2 things you can do with ext/java 1) create instances of java objects thru the php's java class, You should have access of all the methods available for that object ex. $java = new Java(java.util.Hashtable); $java-put(Key, Value); echo $java-toString(); 2) php will run as a servlet engine, meaning you can run php scripts inside Tomcat. This is done all thru native methods. 3) How does it all work? (pass thru mechanism? are pages compiled as classes?) Pages are not compiled as classes they still exists as php scripts. 4) Does this make it eiasier to access Java servlets or EJBs? Does it increse performance? Well not sure exactly what you mean by accessing java servlets, You can access a java servlet by simply file(http://someserver.com/servlet/SomeJava.jsp?param=go;); That would make the servelet execute but I might not know what you mean by access. I guess if you wanted to you could use the Java() class to create an instance of a servlet class and invoke its methods directly. Accessing a EJB from a php script should be fine, (this is purely theory never tried it or even fully thought it thru). If you take the steps that you would to create a refrence of an EJB from java and replicate it using ext/java it should work. Here is a quick example from OpenEJB HelloWorld example http://openejb.sourceforge.net/hello-world.html ? $p = new Java(java.utils.Properties); //The JNDI properties you set depend //on which server you are using. $p-put(java.naming.factory.initial, org.openejb.client.JNDIContext); $p-put(java.naming.provide.url, 127.0.0.1:4201); $p-put(java.naming.security.principal, myuser); $p-put(java.naming.security.credentials, mypass); //Now use those properties to create //a JNDI InitialContext with the server. $ctx = new Java(javax.naming.InitialContext, $p ); //Lookup the bean using it's deployment id $obj = $ctx-lookup(/Hello); //Be good and use RMI remote object narrowing //as required by the EJB specification. //** This may not work with ext/java extension *** $pro = new Java(javax.rmi.PortableRemoteObject); $helloHome = new Java(HelloHome); $ejbHome = $pro-narrow( $obj, $helloHome-class); //** This may not work with ext/java extension *** //Use the HelloHome to create a HelloObject $ejbObject = $ejbHome-create(); //The part we've all been wainting for... $message = $ejbObject-sayHello(); //A drum roll please. echo $message; ? So except for the static access to class from helloHome It should work. Maybe if I get borred some time i'll try it. 5) Who is responsible for development of this extension? Sam Ruby was the orig developer. I've played with it. I don't think anyone has done any new development in awhile. 6) When do you expect a non experimental version will be available When more intrest becomes of it and someone wants to claim any new development. - Brad __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / Makefile.global
Sander Roobol wrote: On Thu, Oct 24, 2002 at 11:59:19AM -0400, Jon Parise wrote: - Change the compiled default value for output_buffering to 0. - Allow output_buffering to be set by ini_set(). - Specify 'output_buffering = 0' via the -D command line option for run-tests.php. - Pass a php.ini configuration file to run-tests.php using -C. Can't we just flush all the open output buffers? Something like this: while(ob_get_level()) ob_end_clean(); Of course, I know that. But my points are - run-tests.php itself is not test script, but phpt is. - with specific ini, we can get rid of code aren't needed - we don't have to care about careless patches, and say 'Hey your patch does not work with my php.ini. - things are easier with certain ini. - etc, etc. So far, I didn't see any good point using various php.ini settings for run-tsets.php. Person, who get rid of the setting and insist specifying php.ini is not worth, even cannot find and fix problem with php.ini-recommended. Better choice is obvious, isn't? -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP and Java
On Thursday, October 24, 2002, at 09:46 PM, Marc Richards wrote: 5) Who is responsible for development of this extension? Sam Ruby wrote it originally, but alas he seems to have disappeared from maintaining it. A few people have done matiaince on it, you can see the bonzai tree, or cvs logs for this. --- Dan KalowskyI've learned to fake it, http://www.deadmime.org/~dankand just smile along. [EMAIL PROTECTED]- Candy, [EMAIL PROTECTED] Iggy Pop -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
