[PHP-DEV] Load extensions for .user.ini files

Hello all, My team is interested in permitting .user.ini files to load extensions. We believe this to be a simple fix: add an invocation of php_ini_register_extensions to the end of sapi/cgi/cgi-main.c. I don't believe this steps on any invariants, since extensions can usually be loaded arbitrar

Re: [PHP-DEV] Load extensions for .user.ini files

On 11/08/2011 12:23 AM, Edward Z. Yang wrote: > Hello all, > > My team is interested in permitting .user.ini files to load > extensions. We believe this to be a simple fix: add > an invocation of php_ini_register_extensions to the end > of sapi/cgi/cgi-main.c. > > I don't believe this steps on a

[PHP-DEV] Right of vote

Hi, I wonder how to get a right to vote on the wiki. I read the dedicated page which mentions that lead developers of representative PHP librairies are eligibles and can get a right to vote. I'm leading the Propel ORM project (http://www.propelorm.org/) which is almost 10 years old, so I wonde

Re: [PHP-DEV] Load extensions for .user.ini files

Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011: > You are aware that these extensions can't be unloaded, right? So one > user loading an extension will potentially be stepping on another user > and breaking their code. Yep. If you like, I can make it so that it only appli

Re: [PHP-DEV] Load extensions for .user.ini files

On 11/08/2011 12:46 AM, Edward Z. Yang wrote: > Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011: >> You are aware that these extensions can't be unloaded, right? So one >> user loading an extension will potentially be stepping on another user >> and breaking their code. >

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

On 11/08/2011 10:43 AM, Rasmus Lerdorf wrote: Indeed, valgrind says: ==47112== Warning: ignored attempt to set SIGUSR2 handler in sigaction(); ==47112== the SIGUSR2 signal is used internally by Valgrind So it looks like it won't allow PHP to override signal handlers. The questions

Re: [PHP-DEV] Load extensions for .user.ini files

Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:54:56 -0500 2011: > It should match the dl() SAPI availability. OK, can do! Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Load extensions for .user.ini files

It seems working on my MacBook. I just tried php-src-5.4 with $ uname -a Darwin esi-yasmc1.esi.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 $./configure && make and got following result. $ USE_ZEND_ALLOC=0 valgrind ./sapi/cli/ph

Re: [PHP-DEV] unsolved issues

Fixed that one. https://bugs.php.net/patch-display.php?bug_id=55475&patch=final_patch_for_5_4_and_HEAD_v2&revision=latest The alternative patch was to use the argument to enable/disable

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

Sorry I replied to wrong thread. I haven't used to new gmail UI... It seems working on my MacBook.I just tried php-src-5.4 with $ uname -aDarwin esi-yasmc1.esi.local 10.8.0 Darwin Kernel Version 10.8.0: TueJun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386$./configure && make and go

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

It seems copy&paste from a message don't work well. yohgaki@esi-yasmc1$ uname -a Darwin esi-yasmc1.esi.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 yohgaki@esi-yasmc1$ ./sapi/cli/php -v PHP 5.4.0RC1-dev (cli) (built: Nov  8 2011 1

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

On 11/08/2011 06:23 AM, Stas Malyshev wrote: > Indeed, valgrind says: > ==47112== Warning: ignored attempt to set SIGUSR2 handler in sigaction(); > ==47112== the SIGUSR2 signal is used internally by Valgrind > > So it looks like it won't allow PHP to override signal handlers. The > questi

Re: [PHP-DEV] CI for 5.4

On Mon, Nov 7, 2011 at 4:42 PM, Ferenc Kovacs wrote: > > > On Mon, Nov 7, 2011 at 11:14 AM, Ferenc Kovacs wrote: > >> >> >> On Thu, Nov 3, 2011 at 8:15 PM, Ferenc Kovacs wrote: >> >>> >>> >>> On Thu, Nov 3, 2011 at 7:43 PM, Stefan Marr wrote: >>> Hi Ferenc: On 03 Nov 2011, at 19

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

On 11/08/2011 01:39 AM, Florian Anderiasch wrote: > So it looks like only FPM uses it for more than the default behaviour of > "terminate", from a quick glance. Well, it is part of the new 5.4 signal handling code that defers these signals, including SIGUSR2, when inside a critical section. In ord

Re: [PHP-DEV] CI for 5.4

Quoting Ferenc Kovacs : There is only three failing tests left on the debian slaves: For 5.3 ext/phar/tests/phar_oo_005.phpt.Phar and RecursiveDirectoryIterator 0.01 20 ext/spl/tests/bug60082.phpt.Bug #60082 (100% CPU / when using references with ArrayObject(&$ref)) FWIW, the test for Bug #60

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

On 11/08/2011 11:30 AM, Rasmus Lerdorf wrote: > Not deferring SIGUSR2 just because valgrind on OSX doesn't like it isn't > really an option here. We could make debug builds on OSX not defer it, I > suppose. I didn't want to imply we should change PHP behaviour in order to be valgrindable :) https

Re: [PHP-DEV] CI for 5.4

On Tue, Nov 8, 2011 at 11:36 AM, Dirk Haun wrote: > Quoting Ferenc Kovacs : > > There is only three failing tests left on the debian slaves: >> >> For 5.3 >> ext/phar/tests/phar_oo_005.**phpt.Phar and RecursiveDirectoryIterator >> 0.01 20 >> ext/spl/tests/bug60082.phpt.**Bug #60082 (100% CPU / w

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

On Tue, Nov 8, 2011 at 7:39 PM, Florian Anderiasch wrote: > On 11/08/2011 11:30 AM, Rasmus Lerdorf wrote: >> Not deferring SIGUSR2 just because valgrind on OSX doesn't like it isn't >> really an option here. We could make debug builds on OSX not defer it, I >> suppose. > > I didn't want to imply w

Re: [PHP-DEV] unsolved issues

2011/11/7 Ferenc Kovacs : > On Mon, Nov 7, 2011 at 7:52 AM, Stas Malyshev wrote: > >> Hi! >> >> We have the following issues which I'd really like to put behind us before >> RC (please correct me if they already were resolved): >> >> 1. is_a issue - did we resolve it? If not - does anyone have a pr

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

On Tue, Nov 8, 2011 at 7:54 PM, Yasuo Ohgaki wrote: > I've been using valgrind with PHP 5.3 for sometime on my osx, and > didn't have problem. > As I just pasted the result with PHP 5.4, it seems working with my > configuration. > > My MacPorts was old enough, so I'm currently updating to latest >

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

On 11/08/2011 10:34 AM, Yasuo Ohgaki wrote: > yohgaki@esi-yasmc1$ USE_ZEND_ALLOC=0 valgrind ./sapi/cli/php -v > ==63465== Memcheck, a memory error detector > ==63465== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. > ==63465== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copy

[PHP-DEV] Accessors Parsing

Working to implement Getter/Setter Accessor syntax as per https://wiki.php.net/rfc/propertygetsetsyntax but brand new to php internals development. I was planning on having the parser define methods on the class for the getter/setter such as __getHours() and __setHours() and then have those fu

Re: [PHP-DEV] Accessors Parsing

Hi, quick note: By introducing T_GET and T_SET, you disable people the ability to name any function/method "set" or "get", which I'm sure many people used. You should rather keep to T_STRING and check it's value. Best, On Tue, Nov 8, 2011 at 15:26, Clint M Priest wrote: > Working to implement G

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Ok... I promised to complete the RFC and here I am. I wrapped the entire idea, PHP implementation of what I'm proposing all in RFC. If you're interested, feel free to review the document, highlight if I missed something and update/add your votes. http://wiki.php.net/rfc/splclassloader Answering

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On Tue, Nov 8, 2011 at 6:17 PM, guilhermebla...@gmail.com wrote: > Remove is useless. conditionally add loaders and you're done. > AddAll is ok for user land, but we focus on basic stuff, not fluffy > implementations. It can be easily done in userland. ... Just like the whole rest of the class: al

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Hi Nikita, Because there's no need to bring to C a single foreach. Also, if you re-read the RFC, you'll see that SplClassLoader is extendable for personalized developer needs, such as an addAll or an APC lookup. Cheers, On Tue, Nov 8, 2011 at 3:25 PM, Nikita Popov wrote: > On Tue, Nov 8, 2011 a

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

Hi! On 11/8/11 1:34 AM, Yasuo Ohgaki wrote: It seems copy&paste from a message don't work well. Try running some script, not -v. IIRC -v doesn't initialize request. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runt

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On Tue, Nov 8, 2011 at 6:28 PM, guilhermebla...@gmail.com wrote: > Because there's no need to bring to C a single foreach. > Also, if you re-read the RFC, you'll see that SplClassLoader is > extendable for personalized developer needs, such as an addAll or an > APC lookup. After your changes the R

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

Hi! On 11/08/2011 01:39 AM, Florian Anderiasch wrote: So it looks like only FPM uses it for more than the default behaviour of "terminate", from a quick glance. Not deferring SIGUSR2 just because valgrind on OSX doesn't like it isn't really an option here. We could make debug builds on OSX not

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

On 11/08/2011 09:42 AM, Stas Malyshev wrote: > Hi! > >> On 11/08/2011 01:39 AM, Florian Anderiasch wrote: >>> So it looks like only FPM uses it for more than the default behaviour of >>> "terminate", from a quick glance. >> Not deferring SIGUSR2 just because valgrind on OSX doesn't like it isn't >

Re: [PHP-DEV] SplClassLoader RFC Voting phase

Hi Nikita, Thanks. It's your option and I won't fight. But it seems my proposal is not yet 100%. Some things I have either identified or people have reported. 1- Remove ->register() and ->unregister(), and make the spl_autoload_register to support SplClassLoader. I'm really +0 on this one. But s

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

On 08.11.2011 18:47, Rasmus Lerdorf wrote: > Valgrind should also have a way to turn off grabbing SIGUSR2. What if > you are valgrinding something that actually needs it for something real? > Are you out of luck? According to the docs this might help: http://valgrind.org/docs/manual/manual-core.h

Re: [PHP-DEV] Accessors Parsing

2011/11/8 Clint M Priest > echo $o->Hours()."\r\n"; Why use as method call? Why not "echo $o->Hours;" ? With regards, Alexander Moskaliov ir...@irker.net

RE: [PHP-DEV] Accessors Parsing

In this particular case I was just trying to see if Hours() had properly been defined as a callable function. Eventually that function name would become __getHours(), this particular line was just a test (which is where I discovered that the $$ was no longer set to ‘Hours’ on the zend_do_abstra

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

Hi Stats, New gmail's, wordwrap and message display/sync, is killing me... Anyway, I've been using valgrind on my osx 10.6 with PHP 5.3 for a while and I don't have startup problem with PHP 5.4 like you did. It sounds like valgrind configuration is different or osx version differs. I'm using yoh

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

I think it is a new thing in Valgrind 3.7 On 11/08/2011 02:23 PM, Yasuo Ohgaki wrote: > Hi Stats, > > New gmail's, wordwrap and message display/sync, is killing me... > > Anyway, I've been using valgrind on my osx 10.6 with PHP 5.3 for a > while and I don't have startup problem with PHP 5.4 like

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

2011/11/9 Rasmus Lerdorf : > I think it is a new thing in Valgrind 3.7 When I upgraded from Leopard to Snow Leopard, I couldn't use valgrind for a while. It was some kind of startup problem. Good to know if there is problem with newer version. This is one reason that I'm holding upgrade to Lion. (

Re: [PHP-DEV] SplClassLoader RFC Voting phase

For all those interested, I implemented what I referred as item 2: After some thought it makes sense, but only if interface then defines the setMode prototype. The background for this is supported if the user decides to enhance the base class to support caching, requiring the injection of the Cac

Re: [PHP-DEV] SplClassLoader RFC Voting phase

PS: I'd love to point you all this article... this is something that motivates me to push this RFC forward. =) http://phpmaster.com/the-importance-of-standards/ Cheers, On Tue, Nov 8, 2011 at 11:23 PM, guilhermebla...@gmail.com wrote: > For all those interested, I implemented what I referred as

Re: [PHP-DEV] SplClassLoader RFC Voting phase

I don't argue with your logic and want for standards. I do question this implementation. This is will not enforce any standards whatsoever and I feel it serves the need for existing frameworks and standardizing them. I have to say, I've never heard the argument, "man, if there's one thing I'd like