Source distro ::

http://www.php.net/~sterling/php5/

Win32 binaries ::

http://www.php.net/~edink/php-5.0.0b1-Win32.zip

Download, compile, test.

i've got a problem with sqlite....
./configure --with-sqlite=shared

make:
/bin/sh /home/Allowee/PHP/pack/php5b1/libtool --silent --preserve-dup-deps
--mode=compile gcc -I/home/Allowee/PHP/pack/php5b1/ext/sqlite/libsqlite/src
-Iext/sqlite/ -I/home/Allowee/PHP/pack/php5b1/ext/sqlite/ -DPHP_ATOM_INC
-I/home/Allowee/PHP/pack/php5b1/include -I/home/Allowee/PHP/pack/php5b1/main
-I/home/Allowee/PHP/pack/php5b1 -I/home/Allowee/PHP/pack/php5b1/Zend
-I/usr/include/libxml2 -I/usr/X11R6/include -I/usr/include/freetype2
-I/usr/include/mysql -I/home/Allowee/PHP/pack/php5b1/TSRM -g -O2
-prefer-pic -c /home/Allowee/PHP/pack/php5b1/ext/sqlite/libsqlite/src/parse.c
-o ext/sqlite/libsqlite/src/parse.lo
In file included from
/home/Allowee/PHP/pack/php5b1/ext/sqlite/libsqlite/src/sqliteInt.h:16,
from
/home/wez/src/php/php4.3-cvs/ext/sqlite/libsqlite/src/parse.y:36: <- !!!!!!!

/home/Allowee/PHP/pack/php5b1/ext/sqlite/libsqlite/src/config.h:1:50:
/home/Allowee/PHP/pack/php5b1/config.h: No such file or directory <- !!!!!!
make: *** [ext/sqlite/libsqlite/src/parse.lo] Fout 1

I don't seem to have /home/wez/
and I also don't have the config.h file in /home/Allowee/PHP/pack/php5b1

What should I do??

.: Allowee

Zitat von Sterling Hughes sterling@bumblebury.com:

Source distro ::

http://www.php.net/~sterling/php5/

Win32 binaries ::

http://www.php.net/~edink/php-5.0.0b1-Win32.zip

Download, compile, test.

Just something that doesn't have something to do with the pre-beta, but this
HEAD generally: I think the register globals warning can safely be removed
from the configure script now.

Btw, compiles and tests fine.

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft

URLs for the downloads have been changed:

Source:

http://downloads.php.net/sterling/

Win32 binaries:

http://downloads.php.net/edink/

Edin

Source distro ::

http://www.php.net/~sterling/php5/

Win32 binaries ::

http://www.php.net/~edink/php-5.0.0b1-Win32.zip

Download, compile, test.

The following tests should fail on make test for a stock php build::

=====================================================================
FAILED TEST SUMMARY

Methods via variable name, bug #20120 [tests/classes/bug20120.phpt]
Bug #22367 (weird zval allocation problem) [tests/lang/bug22367.phpt]
Bug #23624 (foreach leaves current array key as null)
[tests/lang/bug23624.phpt]
aggregating everything [ext/standard/tests/aggregation/aggregate.phpt]
aggregating all methods
[ext/standard/tests/aggregation/aggregate_methods.phpt]
aggregating methods specified in the list
[ext/standard/tests/aggregation/aggregate_methods_by_list.phpt]
aggregating methods matching regular expression
[ext/standard/tests/aggregation/aggregate_methods_by_regexp.phpt]
date_sunrise() and date_sunset() functions
[ext/standard/tests/general_functions/sunfuncts.phpt]
XML parser test, function callbacks [ext/xml/tests/xml001.phpt]
XML parser test, object tuple callbacks [ext/xml/tests/xml002.phpt]
XML parser test, xml_set_object callbacks [ext/xml/tests/xml003.phpt]

Let me know if something goes terribly wrong on your system. This is
just meant as a sanity check, not a QA cycle. Ie, if your processor
doesn't blow up and take at least one arm with it, all is assumed well.
;-)

-Sterling

Hi all!

There are some troubles with PHP5-beta-1:

With simple code like this:
<?
class Test {
var $array_var = Array();
function test() {
$this->array_var[0][0][0] = "test_method";
}
function test_method($echo_var) {
echo $echo_var;
}
}

$test_obj = new test;
$test_obj->array_var[0][0][0]("simple test"); //line 15
?>
I get "Fatal error: Method name must be a string in /www/index.php on line 15".
But $test_obj->array_var[0][0][0] is definitely a string.

Sorry if it's a known bug.

WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net

I've been doing some thinking about how to write error handling code
that can run in both PHP 4 and PHP 5. Under the current situation, it
looks like you have to resort to the lowest common denominator of PHP 4
to make error handling code that works under both versions.

Here is a proposal for changing that:

1. Change built in functions to raise exceptions.

There was a thread on this. This would let you do the standard modern
error handling in PHP 5:

try {
db_connect ( 'foo' );
} catch (exception e) {
}

2. Change php 5 to convert uncaught exceptions into standard PHP 4 style
   errors and pass them to the current error_handler.

uncaught exceptions raised by the built in functions would be converted
into exactly the same parameters to the error_handler that they would
have
triggered in PHP 4.

This maintains backward compatibility without requiring any
configuration parameters. Unmodified PHP 4 code running under PHP 5
would perform exactly the same as long as no try .. catch statements
were used.

This PHP 4 style code would still work the same in PHP 5 even when
db_connect raises an exception:

set_error_handler("myErrorHandler");
db_connect('foo');

3. Change the suppress errors operator (@) to also suppresses
   exceptions.

This is also required for backward compatibility, so that things like
this still work the same way:

@db_connect('foo');

4. Change trigger_error to raise an exception.

This allows PHP 4 compatible code to communicate with PHP 5 code via
exceptions.

For unmodified PHP 4 code, the uncaught exception would be changed back
into a standard error_handler style error. Thus, the code would run the
same under PHP 4.

PHP 5 code could catch the exception.

A good example of this would be calling a PHP 4/PHP 5 compatible library
from either a PHP 4 or a PHP 5 program. The library can simply call
trigger_error. Any caller can then handle the error in the way that
is appropriate:

function MultiVersionCompatableLibraryFunction() {
if ($Problem) trigger_error("Message");
}

function PHP4Caller() {
set_error_handler("myErrorHandler");
MultiVersionCompatableLibraryFunction();
}

function PHP5caller() {
try {
MultiVersionCompatableLibraryFunction();
} catch (exception e) {
}
}

5. Add a call_error_handler() function

This function takes an exception as a parameter and converts it to a
valid call on a PHP 4 style error_handler.

call_error_handler($exceptionObj, $handlerName)

The second parameter would default to the current error handler.

This would be used for explicitly converting between the different error
models:

try {
	...
} catch (exception e) {
	call_error_handler($e);
}

This proposal is intended to give an intermediate solution for
errorhandling during the transition from PHP 4 to PHP 5. Without this,
the jump from using an error_handler to using exceptions is too harsh.
As soon as you start using exceptions, you have to abandon PHP 4. This
won't be realistic for libraries (such as smarty) that have to support
the version of PHP that people are actually using. Without the
capability to mix error models, library authors will have to delay using
exceptions until the majority of installations are using PHP 5. With the
described changes, library authors can migrate to an transitional
solution
that works with both PHP 4 and PHP 5.

Comments? Is this possible? Am I missing something?

This proposal is a bit half-baked, but I wanted to get it out as soon
as I
could.

The

date_sunrise() and date_sunset() functions
[ext/standard/tests/general_functions/sunfuncts.phpt]
test failure was the result of <? being used in the test rather then <?php. A
patch correcting this problem is now in the CVS.

Ilia

Source distro ::

http://www.php.net/~sterling/php5/

Win32 binaries ::

http://www.php.net/~edink/php-5.0.0b1-Win32.zip

Download, compile, test.

The following tests should fail on make test for a stock php build::

=====================================================================
FAILED TEST SUMMARY

Methods via variable name, bug #20120 [tests/classes/bug20120.phpt]
Bug #22367 (weird zval allocation problem) [tests/lang/bug22367.phpt]
Bug #23624 (foreach leaves current array key as null)
[tests/lang/bug23624.phpt]
aggregating everything [ext/standard/tests/aggregation/aggregate.phpt]
aggregating all methods
[ext/standard/tests/aggregation/aggregate_methods.phpt]
aggregating methods specified in the list
[ext/standard/tests/aggregation/aggregate_methods_by_list.phpt]
aggregating methods matching regular expression
[ext/standard/tests/aggregation/aggregate_methods_by_regexp.phpt]
date_sunrise() and date_sunset() functions
[ext/standard/tests/general_functions/sunfuncts.phpt]
XML parser test, function callbacks [ext/xml/tests/xml001.phpt]
XML parser test, object tuple callbacks [ext/xml/tests/xml002.phpt]
XML parser test, xml_set_object callbacks [ext/xml/tests/xml003.phpt]

Let me know if something goes terribly wrong on your system. This is
just meant as a sanity check, not a QA cycle. Ie, if your processor
doesn't blow up and take at least one arm with it, all is assumed well.
;-)

-Sterling

"Whether you think you can or think you can't -- you are right."
- Henry Ford