The first release candidate of 5.2.12 was just released for testing
and can be downloaded here:
http://downloads.php.net/ilia/php-5.2.12RC1.tar.bz2 (md5sum:
d15a7f311b1fc08830f0580d44777153)
The windows binaries are available at: http://windows.php.net/qa/
This is a bug-fix only release so t
(Sorry if you receive this multiple times - had some trouble with my network
...)
The fourth release candidate of 5.3.1 was just released for testing
and can be downloaded here:
http://downloads.php.net/johannes/php-5.3.1RC3.tar.bz2
MD5 (php-5.3.1RC3.tar.bz2) = 9747f89ed9962e1f9c4d1c5ed3f8757f
On Thu, Nov 12, 2009 at 11:54:55AM -0800, Rasmus Lerdorf wrote:
> A couple of notes.
>
> You make it sound like this happens on all includes. It is only
> include_once/require_once that have this problem. Regular
> include/require do not.
Sorry for making it confusing. I meant only for include_o
A couple of notes.
You make it sound like this happens on all includes. It is only
include_once/require_once that have this problem. Regular
include/require do not.
This has been addressed in APC by overriding the opcode and providing
our own opcode handler for this case. See
http://svn.php.ne
Hi,
When php script includes a script, php engine compiles the included file.
When opcode caching extensions e.g apc are used, re-compilation is avoided by
apc. But there is a performance problem here. Since php code uses
zend_stream_open to open the included file, open/close system call is s
On 12.11.2009, at 15:27, Ralph Schindler wrote:
There is one key piece of information to keep in mind about this
proposal. This is based on the assumption that all autoloaders need
to do this type of include_path check. I (now) feel this is
questionable concerning that particular use cas
There is one key piece of information to keep in mind about this
proposal. This is based on the assumption that all autoloaders need to
do this type of include_path check. I (now) feel this is questionable
concerning that particular use case.
The best practice should be to only have autoload
IIRC, Sara created this as a proof of concept to a reoccurring question
of why filesystem functions don't have an include include_path argument.
Many members argued (and for good merit), that any fs operations
should not include the include_path. It was put into trunk and
forgotten about, but
When running 'gmake test' on my PHP6 tree on Solaris 10 (SPARC), I
noticed that a number of test failures were caused by the presence of
non-ASCII characters in function names etc.
For example:
sapi/cli/php tests/classes/__set__get_001.php
Setting [a] to 100
OK!
Getting [a]
Returning: 100
Setting
