Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship
Steph Fox wrote: 1) Distribution woes need to end. With the work Greg's been doing lately on PHP_Archive/Phar, that's very close to being attainable now in the physical 'getting PECL'd extensions out to people' sense, but unless people are running CLI or CGI or have access to their own php.ini they still can't do much with those extensions. So we have to seriously consider how to recommend extensions to hosts, other than by shipping them with the PHP core. Steph, Greg In interests of clarity for all, can you explain what you anticipate will change for PECL with Phar/Pyrus for Windows and non-Windows? Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2
Lester Caine wrote: Perhaps if PDO actually added some value there there would not be a problem, but we still need something sensible wrapping it to make cross database SQL work so why do I need to bother changing the internals of what I have been working with for years just to 'fix half of the problem' with a solution at is still showing a significant decrease in performance over native drivers managed transparently in ADOdb. You miss the unstated implication that PDO V2 will offer par or better performance, and potentially more functionality. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
Pierre Joye wrote: Hi Chris, On Feb 14, 2008 2:48 AM, Christopher Jones [EMAIL PROTECTED] wrote: Pierre Joye wrote: The targets were these/this companies(y) pushing CLA in php.net when it is not necessary to contribute. It has been proven already since months on a nearly daily basis. For example: http://blogs.oracle.com/opal/discuss/msgReader$268 My understanding is that because of its collaborative nature, contributing to PDO V2 has new and very different implications. You mean its collaborative and restrictive nature? No - its collaborative nature. Arguments using past contributions to show the ad-hoc development model is feasible are (unfortunately) not tenable Again, please see my other posts. Since my last post, nothing has been brought to the list to clarify the situation. Important questions like who is asking a CLA That has already been stated. This is not an us and them situation since each party has different requirements. who will contribute and what will be brought on board? That has also been stated: expertise and person-power. The fine points will depend on the community, a term that includes data access providers (I'm using that name since not all are actual vendors), and the model the community chooses to accept. Why did they not take contact with us? We did. It just took a very long time. Think of it as a normal is this idea possible chat that took place in very, very, very slow motion. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
Pierre Joye wrote: You (as group) We are individuals, all members of the mail lists. Tell us the names of these entities, companies or persons, who are going to contribute and what are actually their requirements. The general list of data access providers has been given before and isn't surprising. I can't represent anyone other than myself in these discussions. What will they bring (saying expertise is not something I can buy)? We bring development, maintenance, testing and documentation folk. We bring in-depth data access knowledge. We bring previous experience from working on standards. We bring experience from working on PHP. A side benefit is that this leads to more people familiar with PHP code and PHP processes. This grows the pool of talent with the potential to contribute to PHP in general (as my management would like me to do). The people are also able to help shape their future databases to help the PHP user, for example, Oracle's Database Resident Connection Pooling (DRCP). Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
Lukas Kahwe Smith wrote: OSS is a collaborative process that is not about some manager allocating some ressources here and there. People usually make personal commitments here and maybe this is the bigger culture clash than the CLA. Oracle contributes to a range of open source projects, big and small, mature and too new to be known. The commitments come at the personal level and from management who expect their staff to work on those projects. OSS projects accept contributions on merit, and that doesn't always mean knowing much about the background of the people contributing. What is being proposed is to turn part of PHP into something that is managed by a manager and the budget he gets allocated by a manager above him. The proposal is a broader approach to the design and implementation of a DB access layer. Instead of a piecemeal, ad hoc set of designs that ultimately reduces general productivity, I'd like to sit down and discuss what users want and create a coherent solution. People do not commit access for saying what company they work for. People get commit access once they have send enough patches that are top notch, that php.net decides they can trust them. This is the model of trust we have gone by. So if we are going to change this to start trusting a managerial process, the least we can ask is to have some interaction with the people that will most likely be involved there, even if there is a good chance that things might be shuffled around by the time we get to see code. The code and strength of contributions and maintenance is the ultimate evidence of what can be trusted. Poor quality drivers, if they are distributed via a PECL-only distribution, will acquire their own bad reputation and remain little used like other dormant PECL extensions. Or if the drivers are part of the core PHP distribution, a poor driver should get pulled if it is not of sufficient quality as determined by the PHP community. I believe that all the data access providers potentially involved have some level of skill with PHP extension writing, and they certainly have some skill in writing software. I hope that the data access providers are not the only people contributing to, or gate-checking, the drivers. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
Lukas Kahwe Smith wrote: On 14.02.2008, at 22:07, Christopher Jones wrote: Pierre Joye wrote: You (as group) We are individuals, all members of the mail lists. Ok, could the Microsoft and IBM people on this list please speak up then? Could also one of the Oracle internals guys speak up on this list? That is what Pierre was asking for. What do you want the Oracle internals guys to speak about? They may not be known to you personally, but I've acknowledged some of the coders in various bugs fixes, one of the driver architects has featured in my blog, and some of the key people (including management) have attended the Zend Conferences here in California for the last couple of years. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
Lukas Kahwe Smith wrote: However the point here is. There is a proposal on the table to change the php.net project to be able to bring in developers we do not know, for code they have not yet written, for specs they have not yet contributed. This is flipping our development process upside down while adding legal hurdles. Since the process hasn't started yet, of course some of the participants aren't known. I don't think PDO V2 is going to be any different from other PHP projects: it starts at the beginning and progress is monitored. If it's not going well, people speak up and decisions are made about how to correct it. As such the only course of action I currently is to start working. If you guys do not feel like you can work within the current legal bounds of php.net, then I suggest you start working outside of them. Once we see actual value being contributed, the willingness to compromise and change will be much higher. I want to see the effort spent will have value to the community. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Steph Fox wrote: Hi Lukas, Well maybe we should target this stuff for PHP6 for the time being. A possible PHP 5.4 would then be a collection of PHP6 todo items that we want to fast track, or are you guys already certain about PHP 5.4? I'm thinking 'get the mechanisms into place in 5.4, move stuff out of core in 6.0'. This sounds practical. No idea if that makes sense to everyone, but to move out of core or not isn't even an option without a good way to distribute PECL. I'd like to see pecl4win merged into pecl.php.net (adding to Steph's idea of releasing binaries on pecl.php.net), and the Windows binaries being built from their correct branch (whatever happened to this project - it seemed so close?) Chris PS Lukas, sorry for the three line signature. -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Hannes Magnusson wrote: On Sun, Mar 23, 2008 at 3:51 AM, Steph Fox [EMAIL PROTECTED] wrote: does anyone have any objection to the proposal at http://wiki.php.net/rfc/peclversioning? The first step in fixing the core-pecl relationship? \o/ Looks good. But what about extensions that are symlinked to core? Will they need to update their version info during core release cycles? The version number should only change if extension code has been changed. The fact there is a symlink is not really relevent. PHP will have an issue with any extension at PHP release time if the extension code is still marked -dev or -beta. Open question: do we want an extension's version to be the same in its PHP 5.3 and its PHP 6 code base? It obviously shouldn't have a -dev version when distributed with PHP.. Is it up to the RM to hunt those extensions down and make sure the version info is accurate? I'd suggest so. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad Follow me: http://friendfeed.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Supporting External Authentication in the Oracle OCI8 Extension
I've had a couple of recent requests for the OCI8 extension to support External Authentication (aka OS authentication). I also recall a discussion or two in the past, and there is at least one bug logged on it. Having external authentication would allow things like Kerberos to be used for OCI8 authentication. This need is clearly growing but I'm not in favor of having it always enabled in every web environment - I feel another php.ini parameter looming :( If anyone wants to be throw in some comments or help me re-evaluate the pros and cons, drop me a line. Some Oracle documentation discussing External Authentication is in: http://download.oracle.com/docs/cd/B28359_01/network.111/b28531/authentication.htm#CHDEGIFB Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Supporting External Authentication in the Oracle OCI8 Extension
Michael B Allen wrote: On Thu, May 8, 2008 at 2:02 PM, Christopher Jones [EMAIL PROTECTED] wrote: I've had a couple of recent requests for the OCI8 extension to support External Authentication (aka OS authentication). I also recall a discussion or two in the past, and there is at least one bug logged on it. Having external authentication would allow things like Kerberos to be used for OCI8 authentication. This need is clearly growing but I'm not in favor of having it always enabled in every web environment - I feel another php.ini parameter looming :( If anyone wants to be throw in some comments or help me re-evaluate the pros and cons, drop me a line. Some Oracle documentation discussing External Authentication is in: http://download.oracle.com/docs/cd/B28359_01/network.111/b28531/authentication.htm#CHDEGIFB Chris Hi Chris, That's interesting but the scenario that is becoming more common and is the case I'm interested in is using an existing credential to initiate authentication with Oracle. For example, using our extension a PHP script can acquire a Kerberos credential either through delegation (eg. during SPNEGO authentication), explicitly with a username and password (ie. get a TGT) or implicitly from the HTTP service account keytab file. The mod_auth_kerb module for Apache can also save the user's delegated Kerberos credential if present. Then Kerberos aware clients (e.g. pgsql_connect) look at the KRB5CCNAME environment variable and use that ccache file to acquire credentials for the desired resource. Does the PHP oci8 extension handle this scenario? Mike Without adding external authentication support, there is no support for Kerberos at all. Thanks for the use case. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Add deg2grad() and grad2deg() in PHP5.3
Even for small projects like this, we should get into the habit of creating an RFC on the Wiki. This is a way to explain the pros cons so the functionality can be evaluated. You can argue about the algorithm choice and point out weakness (overflow/underflow?). It allows us to see where the code will be added, and lets us see some usecases (that will become tests) etc. Chris Kalle Sommer Nielsen wrote: Ah Cheers I didn't think of number optimizations, but its done now Cheers Kalle - Original Message - From: Guilherme Blanco [EMAIL PROTECTED] To: Kalle Sommer Nielsen [EMAIL PROTECTED] Cc: PHP Developers Mailing List internals@lists.php.net Sent: Tuesday, May 20, 2008 8:47 PM Subject: Re: [PHP-DEV] Add deg2grad() and grad2deg() in PHP5.3 Hi... Are there any explanation why you used 360 and 400 and not optimized it? I know 1 full circle = 360 deg = 400 grads, but you can simplify it to: RETURN_DOUBLE((9 / 10) * deg); and... RETURN_DOUBLE((10 / 9) * grads); Regards, On Tue, May 20, 2008 at 3:22 PM, Kalle Sommer Nielsen [EMAIL PROTECTED] wrote: Greetings internals I've made two functions that allows convertion between degress and gradians, below is a pastebin of the functions as that would look in math.c: http://www.phpfi.com/318450 If no objections against it I will commit them in PHP_5_3 and HEAD and I will prepare some test cases for those aswell. Cheers Kalle -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 MSN: [EMAIL PROTECTED] URL: http://blog.bisna.com Rio de Janeiro - RJ/Brazil -- No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.21/1455 - Release Date: 19-05-2008 17:04 -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] pear proxy install patch
Hannes (or anyone),
Can you apply these patches for pear? I've reverted to use wget
by default. The newish fetch.php is used as a last resort.
I fixed one real message typo in fetch.php, and changed the humourous
error message prefix to something easier to grep, i.e. Error.
Chris
--
Christopher Jones, Oracle
Email: [EMAIL PROTECTED]Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad
Index: Makefile.frag
===
RCS file: /repository/php-src/pear/Attic/Makefile.frag,v
retrieving revision 1.35.6.10.2.2.2.2
diff -u -a -r1.35.6.10.2.2.2.2 Makefile.frag
--- Makefile.frag 19 May 2008 15:20:55 - 1.35.6.10.2.2.2.2
+++ Makefile.frag 30 May 2008 22:39:41 -
@@ -5,6 +5,9 @@
# Skip all php.ini files altogether
PEAR_INSTALL_FLAGS = -n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir= -derror_reporting=1803 -dmemory_limit=-1 -ddetect_unicode=0
+WGET = `which wget 2/dev/null`
+FETCH = `which fetch 2/dev/null`
+
install-pear-installer: $(SAPI_CLI_PATH)
@$(top_builddir)/sapi/cli/php $(PEAR_INSTALL_FLAGS) $(builddir)/install-pear-nozlib.phar -d $(peardir) -b $(bindir)
@@ -14,7 +17,13 @@
if test -f $(srcdir)/install-pear-nozlib.phar; then \
cp $(srcdir)/install-pear-nozlib.phar $(builddir)/install-pear-nozlib.phar; \
else \
- $(top_builddir)/sapi/cli/php -n $(srcdir)/fetch.php http://pear.php.net/install-pear-nozlib.phar $(builddir)/install-pear-nozlib.phar; \
+ if test ! -z $(WGET) test -x $(WGET); then \
+$(WGET) http://pear.php.net/install-pear-nozlib.phar -nd -P $(builddir)/; \
+ elif test ! -z $(FETCH) test -x $(FETCH); then \
+$(FETCH) -o $(builddir)/ http://pear.php.net/install-pear-nozlib.phar; \
+ else \
+$(top_builddir)/sapi/cli/php -n $(srcdir)/fetch.php http://pear.php.net/install-pear-nozlib.phar $(builddir)/install-pear-nozlib.phar; \
+ fi \
fi \
fi
@if test -f $(builddir)/install-pear-nozlib.phar $(mkinstalldirs) $(INSTALL_ROOT)$(peardir); then \
Index: fetch.php
===
RCS file: /repository/php-src/pear/Attic/fetch.php,v
retrieving revision 1.1.2.1
diff -u -a -r1.1.2.1 fetch.php
--- fetch.php 14 Apr 2008 16:56:50 - 1.1.2.1
+++ fetch.php 30 May 2008 22:39:56 -
@@ -1,4 +1,5 @@
?php
+
function usage($argv) {
echo Usage:\n;
printf(\tphp %s http://example.com/file localfile\n, $argv[0]);
@@ -22,7 +23,7 @@
break;
case STREAM_NOTIFY_CONNECT:
-echo Conntected...\n;
+echo Connected...\n;
break;
case STREAM_NOTIFY_FILE_SIZE_IS:
@@ -58,7 +59,7 @@
}
$err = error_get_last();
-echo \nErorr..\n, $err[message], \n;
+echo \nError:\n, $err[message], \n;
exit(1);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] case folding array string keys
Dave Lee wrote: Hi, I have a patch that I'm hoping might be useful to PHP developers, at least those using PostgreSQL. The patch provides case folding of string keys during hash lookups. The need for this comes from ... My question to the list is, can this functionality be added in a way that doesn't adversely effect developers who won't use it, but helps us PostgreSQL users and anyone else who might find it useful? Judging from my searches on the subject, it's not an uncommon impedance for PHP/PostgreSQL users. Oracle columns names are similarly case insensitive - unless the table was created with quoted column names. Users can see similar issues. I think a PHP solution is more likely to need to be handled the way PDO does, see PDO::CASE_. However, what about creating an RFC on the wiki to share what you have done and found. Do you have any benchmarks? Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] case folding array string keys
Dave Lee wrote: I haven't benchmarked. I haven't looked, maybe you could tell me, are there standard PHP benchmarks? If not I'll run some basic ones and post the results here. Try the basic test Zend/benchmark.php. Ideally, you'd create some specific tests that stress the changed code. I'm new to the php-dev scene, I'll take a look at the wiki and other RFCs posted. The RFC page is at http://wiki.php.net/rfc Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
Christian Seiler wrote: As a followup to the discussion in January, I'd like post a revised patch to this list that implements closures and anonymous functions in PHP. Did I miss seeing its phpt tests? A really thorough test suite might the case for inclusion in PHP 5.3. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] make it possible to skip very slow tests
Steph Fox wrote: Hi again, I'm using this locally because two of our tests take over 10 minutes each to run on my laptop, and I run the relevant bits of test suite every time I make a change. All it does is adds another option, -x, to run-tests.php. This sets an environmental variable which can then be checked for in the SKIPIF section of very slow-running tests. Any objections if I commit it in 5_3/HEAD? I'd prefer a run-tests.php option that sets the timeout limit in seconds. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] make it possible to skip very slow tests
Steph Fox wrote: So what was wrong with the simple skipif and env var approach again? The problem is it only skips the test! I'd like my slow tests to run (this generally occurs when I use a very remote DB). I end up manually increasing the timeout in stream_select() in run-tests.sh. This works for me on Linux. If we make the timeout value adjustable, you can set it to a low value so your slow tests are quickly aborted, and I can set it to a high value so my tests are run. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] make it possible to skip very slow tests
Steph Fox wrote: So 'skipif' suits my needs better, but not yours. I'll add both. Thanks Steph. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tentative 5.3 release plan
Lukas Kahwe Smith wrote: In our dreams someone would also make PDO a focus area, since the number of open bugs is getting ridiculous. This is also a call to the general community to try and help to find a PDO maintainer. In the mean time people not adapt in C might at least try and plow through the bug tickets to find duplicates and verify the open tickets, write tests etc. For PHP 5.3 on, I'd be happy to see the Windows builds of PDO_OCI only produce php_pdo_oci.dll and no longer also build php_pdo_oci8.dll. The latter uses an older set of Oracle client libraries that allows connections to Oracle 7 and 8.0 databases. The impact is that users on Windows will no longer be able to connect to the older databases unless they compile the extension themselves. The benefit is reduced user confusion and PDO maintenance. The change is to remove the pdo-oci8 section of ext/pdo_oci/config.w32 and tidy up associated Windows DLL release infrastructre. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tentative 5.3 release plan
Daniel Convissor wrote: On Tue, Jul 15, 2008 at 02:09:33PM -0700, Christopher Jones wrote: For PHP 5.3 on, I'd be happy to see the Windows builds of PDO_OCI only produce php_pdo_oci.dll and no longer also build php_pdo_oci8.dll. The latter uses an older set of Oracle client libraries that allows connections to Oracle 7 and 8.0 databases. The impact is that users on Windows will no longer be able to connect to the older databases unless they compile the extension themselves. Removing it completely or requring people to build it themselves is sub-optimal. If you really want it out of PHP, please make it a PECL package. The plan is to continue shipping php_pdo_oci.dll. This allows users to use PDO_OCI to connect to Oracle 8.1, 9.2, 10 and 11 Databases. The codebase for php_pdo_oci.dll and php_pdo_oci8.dll is the same (and only one can be enabled at a given time) Non-windows users of PDO_OCI would be not affected in anyway whatsoever. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tentative 5.3 release plan
Lukas Kahwe Smith wrote: On 15.07.2008, at 23:09, Christopher Jones wrote: Lukas Kahwe Smith wrote: In our dreams someone would also make PDO a focus area, since the number of open bugs is getting ridiculous. This is also a call to the general community to try and help to find a PDO maintainer. In the mean time people not adapt in C might at least try and plow through the bug tickets to find duplicates and verify the open tickets, write tests etc. For PHP 5.3 on, I'd be happy to see the Windows builds of PDO_OCI only produce php_pdo_oci.dll and no longer also build php_pdo_oci8.dll. The latter uses an older set of Oracle client libraries that allows connections to Oracle 7 and 8.0 databases. I guess for windows it just comes down to what we bundle. We could still support older Oracle versions with an optional download. If we want to be super fancy, we might even include a note in an error message when trying to connect to older versions that there is pdo_oci8 available as an optional download from win.php.net (or whatever our pecl4win.php.net replacement will be). I'd prefer to keep the status quo instead of making the build more complex. The idea was to simplify the distribution and move forward. The DB versions in question are Oracle 7 - released in 1993, and Oracle 8.0 - released in 1997, IIRC. These versions are even more uncommon than when PDO_OCI was created in back 2004. Users of more recent DBs (or on non-Windows platforms) won't be affected in anyway. The workaround of building your own PHP on Windows is less of a problem now there is improved Windows build infrastructure and documentation. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] tentative 5.3 release plan
Lukas Kahwe Smith wrote: On 16.07.2008, at 00:50, Christopher Jones wrote: We could still support older Oracle versions with an optional download. If we want to be super fancy, we might even include a note in an error message when trying to connect to older versions that there is pdo_oci8 available as an optional download from win.php.net (or whatever our pecl4win.php.net replacement will be). I'd prefer to keep the status quo instead of making the build more complex. The idea was to simplify the distribution and move forward. The DB versions in question are Oracle 7 - released in 1993, and Oracle 8.0 - released in 1997, IIRC. These versions are even more uncommon than when PDO_OCI was created in back 2004. Well for Oracle 7 I can definitely see it, but Oracle 8 will still be in production in plenty of places. I am fine with not supporting them out of the box, but I think we should try to offer them a download from PECL by the time 5.3.0 ships. That being said the world will not end for me if we do not provide this, especially since I assume very few people will have Oracle 8 and running a PDO based app on windows. Most people will probably be using ext/oci8 for this kind of setup. Of the Oracle 8.x releases, there will be more 8.1 in use than 8.0 and only the latter is directly affected. Php_pdo_oci.dll will connect to Oracle 8.1. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Bug Summary Report
Lukas Kahwe Smith wrote: Hello all, Just some observations. Keep in mind I am just trying to see in what area's we should try and find people to help out. So please do not interpret this email as me telling people what they should do with their time. However I am, just like Jani, a bit worried about the large number of assigned bugs. ===[OCI8 related]= 37220 Suspended LOB Type mismatch when using windows oci8.dll 40186 Assigned ORA-00932: inconsistent datatypes: expected CHAR got ARRAY 45497 Assigned memory leak in select statement for varchar2 above 2000 characters 45769 Open Segmentation fault with OCI8 46471 Open Performance problem when reading XML columns 46623 Assigned phpinfo() doesn't show compile time home with phpize install Chris, do you have those on your agenda? Yep, will be looking at them when I get back from PHP Brazil. Some I'm told don't reproduce but I want to check myself. Some are enhancements. Chris -- Email: [EMAIL PROTECTED] Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] substr passing null...
Nathanael D. Noblet wrote: Hello, I just have a question, often there are 'optional' parameters to functions, I've always thought that most of the time I could pass null to these if I wanted to leave one empty. This has as far as I can tell always worked except recently I was using substr(). If I pass null to the third param, I get nothing back. Isn't passing null the same as not passing anything? Is this a bug? Or is my logic flawed? I know Ilia recently fixed a few functions that didn't ignore null parameters, but it doesn't appear that substr() was one of them. Triple check the problem reproduces with the latest snapshot (snaps.php.net). If it's still broken then log a bug (bugs.php.net). Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/UGPOM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Invalid read at zend_objects_store_del_ref_by_handle
Olivier Bonvalet wrote: And... if I'm not able to identify which part of the script do that ? I don't know valgrind, is it possible to obtain some informations about the partion of code which produce that ? I suppose the name of the C functions should help to identify that, no ? And zend_objects_store_del_ref is about object creation or destruction ? And, it's an object created thought zim_PDOStatement_fetchObject ? The function zim_PDOStatement_fetchObject would be the implementation of PDOStatement-fetchObject, i.e. http://www.php.net/manual/en/pdostatement.fetchobject.php Look for uses of that method in your script. Good luck, Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/UGPOM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC for new INI's
Eric Stewart wrote: A new RFC for PHP's proposed INI files have been added to the wiki. Below is a direct link to the page. http://wiki.php.net/rfc/newinis Eric Lee Stewart ericleestew...@gmail.com Eric, Thanks for the work put into this. My comments follow. Chris - The section on devel prod setting differences looks nice but it does become a maintenance task. Since diffing files is easy (and relatively obvious), I'd suggest removing this section from the files. You may want to keep it in the RFC text so reviewers can get a quick idea of the intent of the differences. It's also not immediately obvious from this section whether the given values are the defaults, or what is set in each file, or set in the other file. In the section on extensions. IIRC, you can now use absolute paths. Change all http://us2.php.net/manual/en/; to http://www.php.net/manual/; (Maybe the doc team can confirm whether to keep the en) oci8.events and oci8.old_oci_close_semantics are boolean, so we can take this opportunity to change the 1 and 0 to On and Off. -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/UGPOM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ini value of On = 1 and Off = ? (Re: [PHP-DEV] RFC for new INI's)
Markus Fischer wrote: Sorry to hijack, but ... Christopher Jones wrote: oci8.events and oci8.old_oci_close_semantics are boolean, so we can take this opportunity to change the 1 and 0 to On and Off. ... I've never understood why writing On/Off is a good idea, It improves human readability of php.ini, making it clear that the parameter value range is not numeric. when it is not intuitive that the value returned from ini_get() is of a different content (not meaning, however). It could possibly be argued there is an inconsistency somewhere, but then PHP type juggling and comparison have their own charm. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/UGPOM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New INIs, Round Two.
Eric,
Should uncommented parameters that seem to have the default value be
commented out? For example asp_tags and precision. If the
parameters don't always have the same default value everywhere, should
they be documented in Quick Reference section as having a different
value to the default?
Eric Stewart wrote:
4. I mistakenly had the development and production values of
allow_call_time_pass_reference reversed. This error has been
corrected.
I really think this should be Off in both cases to discourage use.
The doc http://www.php.net/ini.core says This method is deprecated
and is likely to be unsupported in future versions of PHP/Zend.
10. The production value of error_reporting has been changed to E_ALL |
~E_DEPRECATED.
This should use '', as Dave already pointed out on the list.
12. The oci8.events and oci8.old_oci_close_semantics example values now use
the boolean constants.
Thanks.
13. Many people have asked why the links to the online documentation for
each directive are specifically to the English version.
Regardless of the language issue, can the URLs consistently use www
instead of us2? At the moment both occur.
Can the generic case in this come first:?
; 6. Windows directory (C:\windows or C:\winnt), or --with-config-file-path
; compile time option.
i.e change it to
; 6. The directory from the --with-config-file-path compile time
; option, or the Windows directory (C:\windows or C:\winnt)
The general documentation could mention the use of variables as seen
in ext/standard/tests/general_functions/parse_ini_basic.{phpt,data}:
basicval = bar
var1 = ${basicval}
The general documentation could mention that absolute paths to
extensions are (now) supported:
extension=/path/to/extension.so
This should use its not it's:
; PHP attempts to find and load this configuration from a number of locations.
; The following is a summary of it's search order:
The first it's below should be its:
; php.ini-development is very similar to it's production variant, except it's
; much more verbose when it comes to errors.
This should be its in:
; php.ini-production contains settings which hold security, performance and
; best practices at it's core.
Ditto in:
; Turning on this setting and managing it's maximum buffer size can yield some
Ditto in:
; Integer = Enables the buffer and sets it's maximum size in bytes.
Ditto in:
; this to 1 will cause PHP CGI to fix it's paths to conform to the spec. A
setting
There's an (existing) typo in this description, I guess ignore
libjpeg warnings was the intention:
; Tell the jpeg decode to libjpeg warnings and try to create
; a gd image.
Chris
--
Email: christopher.jo...@oracle.com Tel: +1 650 506 8630
Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/UGPOM
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] XOR congruentation breaks PHP
Kenan R Sulayman wrote: Hey Folks! I've been writing some code for a small project and saw PHP crashing every time. Please test the latest snapshot from http://snaps.php.net/. If the problem still exists, log a bug at http://bugs.php.net/ with version and platform details. -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/UGPOM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Changing build configuration acinclude.m4
Does anyone (where's Jani?) want to comment on updating (*) the definition of PHP_SHLIB_SUFFIX_NAMES in acinclude.m4? The PHP_SHLIB_SUFFIX_NAMES macro is very simplistic in setting the SHLIB_SUFFIX_NAME shared lib file extension. In comparison, the AC_LIBTOOL_SYS_DYNAMIC_LINKER macro in build/libtool.m4 is more finegrained, in particular in differentiating between HP-UX Itanium and HP-UX PA RISC. The base problem was reported for the OCI8 extension in http://pecl.php.net/bugs/bug.php?id=15016 An untested patch for acinclude.m4 is: --- acinclude.m4.orig 2008-12-03 13:55:53.0 -0800 +++ acinclude.m42009-03-10 13:57:10.0 -0700 @@ -1975,8 +1975,16 @@ SHLIB_DL_SUFFIX_NAME=$SHLIB_SUFFIX_NAME case $host_alias in *hpux*[)] - SHLIB_SUFFIX_NAME=sl - SHLIB_DL_SUFFIX_NAME=sl + case $host_cpu in + ia64*[)] + SHLIB_SUFFIX_NAME=so + SHLIB_DL_SUFFIX_NAME=so + ;; + *[)] + SHLIB_SUFFIX_NAME=sl + SHLIB_DL_SUFFIX_NAME=sl + ;; + esac ;; *darwin*[)] SHLIB_SUFFIX_NAME=dylib Is $host_cpu appropriately set at this point of configuration? Is there a reason why PHP_SHLIB_SUFFIX_NAMES doesn't use AC_LIBTOOL_SYS_DYNAMIC_LINKER? Unfortunately I don't have any HP-UX boxes to test on. Chris (*) No Lukas, I'm not suggesting doing before the next 5.3 Beta -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/UGPOM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Changing build configuration acinclude.m4
Jani Taskinen wrote: Christopher Jones wrote: Does anyone (where's Jani?) want to comment on updating (*) the definition of PHP_SHLIB_SUFFIX_NAMES in acinclude.m4? I don't want to comment on stuff I don't use.. :) (I don't do HP-UX) Ditto The PHP_SHLIB_SUFFIX_NAMES macro is very simplistic in setting the SHLIB_SUFFIX_NAME shared lib file extension. In comparison, the AC_LIBTOOL_SYS_DYNAMIC_LINKER macro in build/libtool.m4 is more finegrained, in particular in differentiating between HP-UX Itanium and HP-UX PA RISC. The base problem was reported for the OCI8 extension in http://pecl.php.net/bugs/bug.php?id=15016 An untested patch for acinclude.m4 is: --- acinclude.m4.orig2008-12-03 13:55:53.0 -0800 +++ acinclude.m42009-03-10 13:57:10.0 -0700 @@ -1975,8 +1975,16 @@ SHLIB_DL_SUFFIX_NAME=$SHLIB_SUFFIX_NAME case $host_alias in *hpux*[)] - SHLIB_SUFFIX_NAME=sl - SHLIB_DL_SUFFIX_NAME=sl + case $host_cpu in + ia64*[)] + SHLIB_SUFFIX_NAME=so + SHLIB_DL_SUFFIX_NAME=so + ;; + *[)] + SHLIB_SUFFIX_NAME=sl + SHLIB_DL_SUFFIX_NAME=sl + ;; + esac ;; *darwin*[)] SHLIB_SUFFIX_NAME=dylib Is $host_cpu appropriately set at this point of configuration? Try it? If it works, commit. OK! We'll see if the bug filer responds. Is there a reason why PHP_SHLIB_SUFFIX_NAMES doesn't use AC_LIBTOOL_SYS_DYNAMIC_LINKER? Because nobody knew that exists? :) :) Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/UGPOM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Production and development ini changes.
Eric Stewart wrote: I've attached patches for php.ini-production and php.ini-development. One change involves an mbstring setting correction regarding: http://marc.info/?l=php-cvsm=123596904426621w=2 http://marc.info/?l=php-cvsm=123596904426621w=2 Another change adds an additional comment including XOR in the list of usable bitwise operators. The final change includes a note regarding the merge of E_STRICT into E_ALL in PHP 6.0.0. Eric Lee Stewart ericleestew...@gmail.com mailto:ericleestew...@gmail.com Hi Eric, I wonder if my mails to you are getting through (e.g. the one mentioning mbstring.http_output_conv_mimetype? In anycase, I don't think your patch was attached. Can you save it as a .txt file and resend it? Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/UGPOM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_extensions.c zend_extensions.h
Stanislav Malyshev wrote: Hi! I'm looking forward to reading at least a mail note describing what extension maintainers can/can't do with this. Basically you can make your Zend extension load with any API number and any build ID (or let it decide with which ID to load and with which one not to). Prior to 5.3 and build IDs, you could do that for API number using api check callback, but not for other things like thread safety, etc. This is a dangerous functionality - as extension using this API should either not use most of the engine API or take care to use correct structures, etc. for every version. But for some applications it may be required. Is this Zend extensions only? Is it safe to set in extensions that should work with pre 5.3 PHP's? Did I lose track of the other API versioning change - the one that was about to change the structure size. Or is this it but just applied to Zend extensions? Chris -- Email: christopher.jo...@oracle.com Twitter: http://twitter.com/ghrd Free PHP Book: http://www.oracle.com/technology/tech/php/pdf/underground-php-oracle-manual.pdf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_extensions.c zend_extensions.h
Dmitry Stogov wrote: Is this Zend extensions only? Yes. Is it safe to set in extensions that should work with pre 5.3 PHP's? Yes, in php5.2 and below build_id just won't be checked ans this callback won't be called. Did I lose track of the other API versioning change - the one that was about to change the structure size. Or is this it but just applied to Zend extensions? It's applied only to zend_extensions and doesn't change the structure size as it has some reserved space. Thanks. Dmitry. Thanks Dmitry. Chris -- Email: christopher.jo...@oracle.com Twitter: http://twitter.com/ghrd Free PHP Book: http://www.oracle.com/technology/tech/php/pdf/underground-php-oracle-manual.pdf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP PDO comment on IRC
Matteo Beccati wrote: Here's a proposal: http://www.beccati.com/misc/php/pdo_streams_v4.diff The idea is to add a new #define PDO_DRIVER_API_CHECK which is verified at compile time by the C preprocessor. If its value doesn't match the main PDO_DRIVER_API an #error is triggered, e.g: In file included from /tmp/PDO_PGSQL-1.0.2/pdo_pgsql.c:29: /usr/local/include/php/ext/pdo/php_pdo_driver.h:50:2: error: #error PDO driver not compatible with the PDO API version in use Hi Matteo, I'll just comment on the internal API versioning part - let's get that sorted out first. To make it easier to write database specific PDO drivers that work with a range of versions of the internal PDO API, I think PDO_DRIVER_API_CHECK could be changed to be min max values that the driver supports. The check would be: #if !defined(PDO_DRIVER_API_IMPLEMENTED_MIN) || \ !defined(PDO_DRIVER_API_IMPLEMENTED_MAX) || \ !(PDO_DRIVER_API_IMPLEMENTED_MIN = PDO_DRIVER_API \ PDO_DRIVER_API = PDO_DRIVER_API_IMPLEMENTED_MAX) #error PDO driver not compatible with the PDO API version in use #endif Adding code documentation to the macros explaining what driver writers can should do would be useful (i.e. please add some). I'm not keen on the introduction of php_pdo_version.h. It seems a kludge so that PDO passes its own version check. It makes PDO itself defines the same value in two places. If you're going to bump PDO_DRIVER_API and change the API, thus making all current PDO drivers incompatible, you may as well continue making changes. Perhaps put the version check code in a new file that is only included in DB driver files, and not in PDO .c files. Chris -- Email: christopher.jo...@oracle.com Twitter: http://twitter.com/ghrd Free PHP Book: http://www.oracle.com/technology/tech/php/pdf/underground-php-oracle-manual.pdf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to contribute for PHP Internals
David Coallier wrote: 2009/5/14 Sahid Ferdjaoui sahid.ferdja...@gmail.com: Hello Internals, I want to contribute for PHP Internal, but i don't know how to do it. I am ready to give approximately 6 to 12 hours per week for PHP. i have checked a wiki, but i don't see a get involved section and i do not know how to start :) The best way to get started is to check http://php.net/anoncvs make a checkout of HEAD (php6) and then go to http://bugs.php.net start making patches and attach them to bug reports. From there you will gain developers trust (People will be tired of committing all your patches) and at some point you'll be granted with an account :) Good luck and welcome :) Yes, welcome! Perhaps you could create a get involved wiki section based on what you find out about getting involved? Chris -- Email: christopher.jo...@oracle.com Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] First test submission and comment correction
Simon Westcott wrote:
Hi,
I've just started to explore PHP's tests, reading through the docs on
qa.php.net, the wiki and a few blogs. Having gotten to a position where
I can run the tests and produce coverage reports I have my first
(simple) submission. It covers an edge case for array_multisort when an
empty array is provided.
Hi Simon,
Welcome!
I've merged these for you. I added an exit() block to the test. See
the Last bit section in http://qa.php.net/write-test.php
Let us know if you have any questions or if there's anyway we can help
you. What parts of PHP are you looking at now?
Chris
Test:
$ cat ext/standard/tests/array/array_multisort_variation11.phpt
--TEST--
Test array_multisort() function : usage variation - testing with empty
array
--FILE--
?php
/* Prototype : bool array_multisort(array ar1 [, SORT_ASC|SORT_DESC [,
SORT_REGULAR|SORT_NUMERIC|SORT_STRING]] [, array ar2 [,
SORT_ASC|SORT_DESC [, SORT_REGULAR|SORT_NUMERIC|SORT_STRING]], ...])
* Description: Sort multiple arrays at once similar to how ORDER BY
clause works in SQL
* Source code: ext/standard/array.c
* Alias to functions:
*/
echo *** Testing array_multisort() : Testing with empty array ***\n;
var_dump(array_multisort(array()));
?
===DONE===
--EXPECTF--
*** Testing array_multisort() : Testing with empty array ***
bool(true)
===DONE===
Whilst producing this simple test I spotted a mistake in a related
comment which appears to originate from bug 24897. A patch against
PHP-5.3 follows,
Index: ext/standard/array.c
===
RCS file: /repository/php-src/ext/standard/array.c,v
retrieving revision 1.308.2.21.2.37.2.53
diff -u -r1.308.2.21.2.37.2.53 array.c
--- ext/standard/array.c13 Feb 2009 22:34:15 -
1.308.2.21.2.37.2.53
+++ ext/standard/array.c5 May 2009 22:56:53 -
@@ -3789,7 +3789,7 @@
}
}
- /* If all arrays are empty or have only one entry, we don't need
to do anything. */
+ /* If all arrays are empty we don't need to do anything. */
if (array_size 1) {
for (k = 0; k MULTISORT_LAST; k++) {
efree(ARRAYG(multisort_flags)[k]);
I appreciate this a trivial stuff, but any constructive feedback is
welcome.
Regards,
Simon Westcott
--
Email: christopher.jo...@oracle.com
Twitter: http://twitter.com/ghrd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] First test submission and comment correction
Simon Westcott wrote: Thanks for accepting and the feedback. Following on from the successful NorthWestUG testfest, I'm continuing to focus on SPL and currently have 24 tests awaiting review in the testfest SVN repo (with the CREDITS section :) ). Once this repo is shutdown (in June?) I'd like to find out more about test review process with the view to applying for a CVS account. That's really excellent. Do you think you'll start to look at PHP bugs too? Chris Also, thanks to Pierre for answering some zend_parse_parameters questions the other night. -- Email: christopher.jo...@oracle.com Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phpize returns -1
Greg Beaver wrote: Hi, Could someone fix phpize to make it return 0 on success? It always returns -1 when opened via proc_open(), which is exceedingly annoying when you're trying to use it in a PHP script. Thanks, Greg The bottom of phpize does return 0 and should be reached when all works OK. I looked into a similar problem a while back. Are you seeing a signal handling issue like http://bugs.php.net/bug.php?id=8992 ? I still see pclose() return failure when I use --enable-sigchild. See http://blogs.oracle.com/opal/2009/03/php_oci8_signal_handling_and_e_1.html Chris -- Email: christopher.jo...@oracle.com Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3.0 stable release
Greg Beaver wrote: jvlad wrote: php5.3-200906221030 make produces suspecious output under FreeBSD 6/amd64: Generating phar.php Generating phar.phar pear: not found Pear package PHP_Archive or Archive.php class file not found. This is not suspicious. It is self-explanatory, not a problem, not a bug. Do not pass Go. Do not collect $200. Greg, your answer is even more suspicious. If Class file not found is neither a problem, nor a bug, what is it? Why does it appear in the output? Doesn't pear: not found mean that make tried to run pear in the $PATH and shell produced this error in the stderr? Shouldn't it run $prefix/bin/pear only? What's about PHP_Archive? Shouldn't it be there in the sources? In other words, I see two bugs there: 1. PHP depends on the system-wide installed pear and tries to run it. 2. One or many files are missed in the package producing the Archive.php class file not found error. 1. you're wrong, PHP does not depend on system-wide installed pear, it will simply use it if present 2. nothing is missing. see http://pear.php.net/PHP_Archive If installed, phar.phar will function (partially) without the phar extension being present. In other words, not a problem, not a bug. Greg, Can the messages be enhanced e.g. explaining what will happen in these cases? For example pear: not found. Using XXX instead would help users for #1. Chris -- Email: christopher.jo...@oracle.com Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: php/php-src/branches/PHP_5_3/ configure.in
I was wondering who was going to yell at me for that! Have some top posting too :) Chris David Soria Parra wrote: On 2009-07-19, Christopher Jones s...@php.net wrote: --0c1c83a6b4cbab36310748c87058a6f52e7ad90a Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit sixdSun, 19 Jul 2009 16:27:59 + URL: http://svn.php.net/viewvc?view=revisionrevision=284377 http://bugs.php.net/48722 Changed paths: U php/php-src/branches/PHP_5_3/configure.in Log: MFH: Bug #48722 (Update OCI8 --enable-sigchild warning) If possible plesae do one commit including the changes to all branches instead of MFH the changes. This will result in much cleaner repository history. -- Blog: http://blogs.oracle.com/opal Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
Lukas Kahwe Smith wrote: On 07.10.2009, at 08:09, Matteo Beccati wrote: Christopher Jones ha scritto: Could you use the new PG specific attribute to enable them but make them output/handled by the existing error/exception interface? That's what I originally thought. But there can be multiple notices triggered by a single query and they shouldn't make the query fail (i.e. throwing an exception would be awkward for a successful query). MySQL has similar notices. Like when stuff gets truncated etc. I also think that using the current error modes is probably not ideal. Or rather these arent exception worthy, and they should obviously not return false either. Is there a common interface that would suit both MySQL Postgres usage? Chris -- Blog: http://blogs.oracle.com/opal Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Use notices in PDO
Samuel ROZE wrote: Hi, I've make a patch which insert notices concepts to PDO. It create: - PDO::noticeInfo() - to be like errorInfo - PDO::ATTR_LOG_NOTICES, the name of the PDO parameter - PDO::NOTICES_FETCH - fetch notices I initially took FETCH to mean it was related to a query; this wouldn't always be the case. What about calling it NOTICES_ENABLE? Chris -- Blog: http://blogs.oracle.com/opal Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch: Use notices in PDO
Samuel ROZE wrote: It's a good idea. - PDO::NOTICES_FETCH - PDO::NOTICES_ENABLED - PDO::NOTICES_NONE - PDO::NOTICES_DISABLED That's better ? That works. I see that you are from the Oracle team. Can you explain me how oracle works to raise notices like PostgreSQL ? Or can you build a proof of concept to get notices from Oracle ? I'm equating your NOTICES to Oracle's DBMS_OUTPUT. See Getting Output with DBMS_OUTPUT on p 181 of: http://www.oracle.com/technology/tech/php/underground-php-oracle-manual.html Something similar could be coded in the PDO driver. The amount of text output could be quite large, depending on the user's coding style. Is your design extensible enough to allow for streaming/chunking if the interface needs to be enhanced? PL/SQL also has compile time warnings and errors that are handled differently, see PL/SQL Success With Information Warnings on p167. Chris Thanks. Samuel. Le jeudi 08 octobre 2009 à 15:22 -0700, Christopher Jones a écrit : Samuel ROZE wrote: Hi, I've make a patch which insert notices concepts to PDO. It create: - PDO::noticeInfo() - to be like errorInfo - PDO::ATTR_LOG_NOTICES, the name of the PDO parameter - PDO::NOTICES_FETCH - fetch notices I initially took FETCH to mean it was related to a query; this wouldn't always be the case. What about calling it NOTICES_ENABLE? Chris -- Blog: http://blogs.oracle.com/opal Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Patch: Use notices in PDO
Samuel ROZE wrote: http://wiki.php.net/rfc/pdonotices Samuel. The new interface combines system generated error messages with user generated messages. The original PostgreSQL example I saw seemed to use arbitrary text messages, similar to Oracle's DBMS_OUTPUT (page 181 of http://tinyurl.com/UGPOM). The MySQL examples in the RFC are seem to be similar to Oracle's compilation warnings (page 167 of http://tinyurl.com/UGPOM). I think two message types should be handled separately. Chris -- Blog: http://blogs.oracle.com/opal Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feedback requested on using #defines to improve the performance of the TSRMG macro
Hi Arvind, Does the GLOBALS_ID_BASE idea work? In ts_allocate_reserved_id(GLOBALS_ID_BASE+1...) each extension would anyway need to reserve an increment to avoid clashes. Also, why is GLOBALS_ID_BASE 30 when the largest reserved value is 18? Maybe I'm missing something. Would there be significant memory space or locality issues if one ID per extension in the PHP source bundle was reserved upfront, even if those extensions were never enabled? Chris Arvind Srinivasan wrote: When compiled for multi-threaded (#ifdef ZTS ) operation, the various subsystems in PHP use dynamically allocated (ts_allocate_id) identifiers to index into the thread-local storage for each subsystem. These dynamically allocated ids are used by macros such as CG, EG, PG, AG. The TSRMG macro is defined as: #define TSRMG(id, type, element) (((type) (*((void ***) tsrm_ls))[TSRM_UNSHUFFLE_RSRC_ID(id)])-element) The PG macro is defined as: # define PG(v) TSRMG(core_globals_id, php_core_globals *, v) where core_globals_id is extern PHPAPI int core_globals_id; cc -E of PG(connection_status) = PHP_CONNECTION_ABORTED; translates to: (((php_core_globals *) (*((void ***) tsrm_ls))[((core_globals_id)-1)])-connection_status) = 1; and cc -S of the same code results in: .loc 1 108 0 movl%ebx, %eax sublcore_globals_id, %eax movl(%esi), %edx sall$2, %eax negl%eax movl(%edx,%eax), %eax movw$1, 144(%eax) I used fixed IDs instead of dynamically allocated ones and noticed a decent improvement in performance (few percentage points) when running a web-based ecommerce-site workload on SPARC CMT hardware. With my changes the PG macro is defined as: # define PG(v) TSRMG(CORE_GLOBALS_ID, php_core_globals *, v) #define CORE_GLOBALS_ID10 and core_globals_id is extern PHPAPI const ts_rsrc_id core_globals_id; cc -E of the same line of code translates to: (((php_core_globals *) (*((void ***) tsrm_ls))[((10)-1)])-connection_status) = 1; cc -S (my version): .loc 1 108 0 movl(%eax), %eax movl36(%eax), %eax movw$1, 144(%eax) The patch is fairly long, so rather than attach it to this email, i'll point to it. It'd be great if someone could give me feedback on my changes - http://bitbucket.org/arvi/arviq/src/tip/arvi-16-ts_allocate_reserved_id - for using reserved/fixed IDs for accessing thread-local storage of frequently used/known/core subsystems. I think the changes only affect the #ifdef ZTS codepaths. Thanks, Arvi -- Blog: http://blogs.oracle.com/opal Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feedback requested on using #defines to improve the performance of the TSRMG macro
Arvind Srinivasan wrote:
Does the GLOBALS_ID_BASE idea work? In
ts_allocate_reserved_id(GLOBALS_ID_BASE+1...) each extension would
anyway need to reserve an increment to avoid clashes. Also, why is
I didn't really try using this. When I added it, I thought it might be
useful for modules that live outside the PHP source tree. They could
then define their constants using
#define FOO_ID (GLOBALS_ID_BASE + 3)
rather than hardcoding 33. As you point out, they would still need to
reserve an increment.
GLOBALS_ID_BASE 30 when the largest reserved value is 18? Maybe I'm
missing something.
I reserved IDs for the subsystems I thought were core. I was sure
there'd be others that I'd missed and so I left space for more.
Would there be significant memory space or locality issues if one ID
per extension in the PHP source bundle was reserved upfront, even if
those extensions were never enabled?
I'll run some tests and see what impact this has.
I'd vote that the reserved slots be assigned from day 1 for one of (i)
always-enabled core extensions or (ii) for core + common extensions or
{iii} the whole set of PHP-bundled extensions + common extensions from
PECL (i.e. APC?). The choice of (i), (ii) or (iii) would depend on
your tests.
All other extensions should use a run-time allocated non-reserved
slot. Extensions that become popular can add an xxx_GLOBALS_ID entry
to zend_globals_macros.h.
Chris
--
Blog: http://blogs.oracle.com/opal
Twitter: http://twitter.com/ghrd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] add COPY functions to pdo_pgsql
Tim Ringenbach wrote: Here's a patch to add pgsqlGetCopyData, pgsqlPutCopyData, and pgsqlEndCopyData methods. I opened bug #50092 but I don't seem able to attach the patch, so I attached it here. --Tim What do these do? I.e. where's the documentation or RFC http://wiki.php.net/rfc ? :) So the patch can be found easily, can you update the bug with a link to it? Chris -- Blog: http://blogs.oracle.com/opal Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Stuck debugging a PHP6 string--unicode--string conversion problem on Solaris (SPARC)
Arvind Srinivasan wrote: I think I've found the cause of the problem. I have created a bug and attached a patch to http://bugs.php.net/?id=50189 Arvi What about basing the #ifdef on WORDS_BIGENDIAN? This appears to be defined during PHP configuration (see alocal.m4 and acinclude.m4). Chris -- Blog: http://blogs.oracle.com/opal Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: ondercsn
nder coskun wrote: I have many projects about php ( not coding for an application or website; directly about php functions etc.) and would like to help to improve php. For example asterisk server functions. That's why i need an svn account to help developing of php This README should help get you started: http://svn.php.net/viewvc/php/php-src/trunk/README.SUBMITTING_PATCH?view=markup Chris -- Blog: http://blogs.oracle.com/opal Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
Jérôme Loyet wrote:
Yes it could be this way ... but you do repeat the pattern ('pool2')
for each entry. There is about 30 lines for each workers ... no
imagine having a multiuser environment with 30 customers ... you have
900 times a useless repeated pattern ... gnurf
If there are deficiencies in php.ini syntax, then propose an
enhancement and/or work around them in FPM. Having two syntaxes in
use will be more confusing in the long term.
Chris
--
Blog: http://blogs.oracle.com/opal
Twitter: http://twitter.com/ghrd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_a() versus instanceof
Johannes Mueller wrote:
if(is_a($foo, bar)){
..
}
// runs with an undefined constant bar notification
I think the instanceof solution can cause problems, because you can not
trigger the problem. What do you think?
I think you meant:
if(is_a($foo, bar)){
since is_a() takes a string as the second parameter.
Does this correction then reset your expectation about instanceof?
Chris
--
Blog: http://blogs.oracle.com/opal
Twitter: http://twitter.com/ghrd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.
Nathan Rixham wrote: Alexey Zakhlestin wrote: On 21.01.2010, at 18:21, Richard Lynch wrote: For BC, I suppose PHP could have *both* 'a.b' and 'a_b', or yet another php.ini flag (sorry!) to choose the behaviour. -1 from me. I don't think we need to keep backward compatibility for this. PHP-6 is a major release, after all. It would be absolutely enough to add optional var-name conversion to extract() any word from anybody on the development team to say if this removal of dot conversion (whether optional or not) can be added to some todo list or suchlike and rolled out at some point soon~ish? An (out of date) ToDo list is at http://wiki.php.net/todo/php60 Could you create an RFC at http://wiki.php.net/rfc to capture all the discussion on the topic? -- Blog: http://blogs.oracle.com/opal Twitter: http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli
steve wrote: Oh, and allow persistent connections in db apis again (like mysqli). It might happen. Wez Furlong was contemplating a persistent connection implementation for the generic PDO interface following on from the persistent connection model in the oci8 extension for Oracle. As an example, lets suppose an example with 2000 connections, using keep-alive, with 20 connections downloading static content and 50 downloading dynamic (PHP) content. In Apache 1.3, you would have to accommodate 2000 processes (either changing the hard limit, or using multiple servers). If you used persistent connections that would be 2000 (almost all idle) connections to mysql. (In the real world this is why you would either disable persistent connections or keep-alive, and most likely both.) The oci8 extension lets you timeout idle persistent connections. Unrelated to your FastCGI suggestion but FYI on database connection pooling: http://blogs.oracle.com/opal/2007/01/03. The pooling described has no dependency on how you deploy your application and works across multiple application types connecting to the DB. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
Rasmus Lerdorf wrote: I'd be more in favour of a statement that put a final death date on it which means no new releases of any sort. We could still say security-fixes only by the end of the year and then death by 08/08/08 or something like that. +1 The final PHP 4 patch date should be relative to the release date of PHP 6, e.g. 6 months after PHP 6 is released. -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
I also think we shouldn't backport features to PHP5. We should (i) keep PHP5 a stable release with a known feature set for developers to use. (ii) have a smaller code base to maintain in PHP5, reducing the overhead of merging. (iii) avoid exacerbating the future situation with uptake of PHP6 vs PHP5 that we now face with PHP5 vs PHP4. Chris Andrei Zmievski wrote: And I think that we shouldn't, since it removes a big incentive for people to move to PHP 6. Really, we need to get folks to use Unicode natively as much as possible. It is the way of the future, and not some obscure feature, as some here have suggested. This kind of attitude is precisely why we've had and continue to have such an internationalization mess when it comes to building applications. -Andrei On Jul 6, 2007, at 9:48 AM, Antony Dovgal wrote: On 06.07.2007 20:44, Stanislav Malyshev wrote: You don't by a Porsche if you need a taxi, why would you install PHP6 if you don't need Unicode? Namespaces ;) This reason is only valid if we don't backport such things from PHP6 to PHP5 (5.3, 5.5 or whatever it would be), which I think we should do. --Wbr, Antony Dovgal -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Lester Caine wrote: I keep being told that the PDO drivers can be extended to include all of the things already available in the native driver, but the second you do that they become incompatible, so in addition to the PDO driver you need to also run the native driver simply to provide the areas NOT covered by PDO. We need a generic framework that addresses the real problems not one that creates an artificial lowest common denominator strangle hold :( PDO could evolve into that, but not with it's current restrictions. Hi Lester, Can you list the current restrictions as you see them? Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Using OnUpdateUTF8String in PHP 6
With thanks to Sara we looked at OnUpdateUTF8String to access a
php.ini value in OCI8 in PHP 6.
One of our engineers sent me a proposed patch for zend_ini.c in PHP6
to allow OnUpdateUTF8String to work as he thought it should. Any
comments?
Chris
The problems I faced when unicode.semantics=On were:
1) Any OnUpdateUTF8String php.ini variable is seen as NULL in
oci_globals.
2) If the above is resolved, the memory of the variable is wiped out,
by the time we come to execution of the script, after module inits.
3) We still convert to UTF-16 when unicode.semantics=Off.
PS. Patch is attached - if it gets through.
--
Christopher Jones, Oracle
Email: [EMAIL PROTECTED]Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad
--- zend_ini.c 2007-10-02 11:07:32.0 -0700
+++ zend_ini.c.new 2007-10-16 13:20:03.0 -0700
@@ -640,7 +640,8 @@
ZEND_API ZEND_INI_MH(OnUpdateUTF8String) /* {{{ */
{
- UChar **p;
+ UChar **up;
+ char **p;
UChar *ustr = NULL;
int32_t ustr_len, capacity;
UErrorCode status = U_ZERO_ERROR;
@@ -651,30 +652,37 @@
base = (char *) ts_resource(*((int *) mh_arg2));
#endif
+ /* Convert only if unicode semantics is on. Otherwise, same as
OnUpdateString */
+ if (UG(unicode)){
+ /* estimate capacity */
+ capacity = (new_value_length 2) ? ((new_value_length 1) +
(new_value_length 3) + 2) : new_value_length;
+
+ while (1) {
+ ustr = peurealloc(ustr, capacity+1, 1);
+ u_strFromUTF8(ustr, capacity+1, ustr_len, new_value,
new_value_length, status);
+ if (status == U_BUFFER_OVERFLOW_ERROR || status ==
U_STRING_NOT_TERMINATED_WARNING) {
+ capacity = ustr_len;
+ status = U_ZERO_ERROR;
+ } else {
+ break;
+ }
+ }
- /* estimate capacity */
- capacity = (new_value_length 2) ? ((new_value_length 1) +
(new_value_length 3) + 2) : new_value_length;
-
- while (1) {
- ustr = eurealloc(ustr, capacity+1);
- u_strFromUTF8(ustr, capacity, ustr_len, new_value,
new_value_length, status);
- if (status == U_BUFFER_OVERFLOW_ERROR) {
- capacity = ustr_len;
- status = U_ZERO_ERROR;
- } else {
- break;
+ if (U_FAILURE(status)) {
+ zend_error(E_WARNING, Could not convert UTF-8 INI
value to Unicode);
+ efree(ustr);
+ return FAILURE;
}
- }
- if (U_FAILURE(status)) {
- zend_error(E_WARNING, Could not convert UTF-8 INI value to
Unicode);
- efree(ustr);
- return FAILURE;
- }
+ up = (UChar **) (base+(size_t) mh_arg1);
- p = (UChar **) (base+(size_t) mh_arg1);
+ *up = ustr;
+ }
+ else { /* Same as OnUpdateString */
+ p = (char **) (base+(size_t) mh_arg1);
- *p = ustr;
+ *p = new_value;
+ }
return SUCCESS;
}
/* }}} */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug 55544
On 07/17/2012 07:25 AM, Christian Kaps wrote: Hi, please can someone look into this issue. It seems that in version 5.4.4-1 the bug was fixed, but in newer versions this issue still exists. So please can someone merge the patch with the newer versions? https://bugs.php.net/bug.php?id=55544 Cheers, Christian Can you reproduce it using php.net's distribution of PHP and then log a new bug? Php.net doesn't do *-1 releases. On this list (and the bug system) it's better not to refer to a Linux distribution's build of PHP because that just confuses the issue. Thanks Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Any chance to fix php-trunk for windows?
On 07/17/2012 06:22 AM, Anatoliy Belsky wrote: Hi Marian, since last week current master snaps can be found here http://windows.php.net/downloads/snaps/master/ Cheers anatoliy How does that really relate to http://windows.php.net/snapshots/ ? Are you going to make the links on http://windows.php.net/snapshots/ work? Also can you update http://snaps.php.net/ to link to Windows snaps, similar to the way http://php.net/downloads.php links to windows.php.net? Thanks, Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] pdo_odbc: fix pdo_odbc_error's use of SQLGetDiagRec()
On 07/18/2012 08:48 AM, Joe Orton wrote: The state parameter passed to SQLGetDiagRec() needs to be six bytes not 5; the attached patch fixes this, from Martin Osvald. Hi Joe, Is there any chance you can log this in https://bugs.php.net/ and/or submit a pull request at https://github.com/php/php-src ? Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Release Frequency, NEWS, etc.
On 07/26/2012 08:41 AM, Johannes Schlüter wrote: I would therefore like to reduce the 5.3 pace. This is reasonable. The current idea would be to skip every second release (unless security issues demand something else) both in release date as well as version number. Skipping numbers will cause short long term confusion. The current number synchronicity between 5.3 5.4 isn't particularly obvious or useful. Doing this has an obvious issue, though: NEWS entries are currently only placed in the lowest branch. With the example from above and the current way the NEWS are handled 5.4.6 NEWS would be quite small and there would be no 5.3 NEWS to check for further things. NEWS handling is broken anyway. Now would be a good time to resolve the issues with it. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Remove calls with incompatible Context
On 07/30/2012 01:32 PM, Gustavo Lopes wrote: 3. There are other low-cost alternatives, namely the obvious one: pass the object via an extra parameter instead of operating on $this directly and unconditionally. This is really easy to do. This kind of thing should be mentioned in the RFC. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Traits behavior still up in the air in 5.4
On 07/31/2012 04:23 PM, Stan Vass wrote: I'd like to point out some puzzling behaviors in Traits as they exist in the production releases of PHP 5.4. Regardless of the outcome of the mail thread, can you review the traits tests and create new tests for any behaviour not already covered? Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] sapi/apache2*: Use ap_state_query where possible instead of old method of creating a pool userdata entry.
On 08/08/2012 10:33 AM, Cristian Rodríguez wrote: sapi/apache2filter/sapi_apache2.c | 11 +-- sapi/apache2handler/sapi_apache2.c | 12 ++-- 2 files changed, 19 insertions(+), 4 deletions(-) Patches to the mail list are very likely to get lost. It's probably better to attach them to a bug at https://bugs.php.net and/or do a pull request at https://github.com/php/php-src Since there wasn't any response to your previous patch, you will likely also need to follow up to ensure the code gets merged or rejected. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 11/12/2012 05:00 AM, Adam Harvey wrote: Hi everyone, I've written an RFC to cover deprecating ext/mysql in PHP 5.5: https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft deprecation in the documentation purely via a straw poll on Internals, I presume this will end up needing to go to a vote, hence the RFC. I won't rehash the background overly (there's some more detail in the RFC), other than to note that we've now had deprecation notices on all mysql_* functions in the manual for about six months and that the logical next step is to start generating E_DEPRECATED notices when users connect via mysql_connect(), mysql_pconnect() or the implicit ext/mysql connection routines. It's my belief that doing so will hasten the move of users to the more modern (and supported) APIs available: mysqli and PDO, and that this process will also likely encourage some users to switch to safer patterns such as prepared queries at the same time. I must apologise for the lateness of this RFC: I had hoped to do this some time before alpha 1, but travel and illness have taken their toll. Better late than never! So, please provide comments, feedback, concerns, and so on. Obviously, this isn't going to a vote for at least a couple of weeks, but earlier feedback is better. Thanks, Adam I'm +1 on using E_DEPRECATED. Anything beyond that would be -1 since it is likely to break BC (I note that the Release Process RFC doesn't defines compatibility, but I think we are have a gut feel for what it means) Adam, can you: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi 2. Mention how to turn off E_DEPRECATED warnings in the RFC? When users of 5.5 stumble on the new messages, we can then simply point them to the RFC. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 11/12/2012 07:08 PM, Adam Harvey wrote: On 13 November 2012 08:44, Christopher Jones christopher.jo...@oracle.com wrote: Adam, can you: 1. Add this link to the RFC?: https://wikis.oracle.com/display/mysql/Converting+to+MySQLi 2. Mention how to turn off E_DEPRECATED warnings in the RFC? When users of 5.5 stumble on the new messages, we can then simply point them to the RFC. Done and done. I've added a (short) workarounds section towards the bottom, which can be moved up later if the RFC is accepted. Against that, I'm not a big fan of RFCs as documentation, but that's a separate discussion. :) Content like this deserves to be in RFCs so voters can quickly judge the impact of proposed changes on end users. Thanks for adding it, Chris Adam -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 11/13/2012 01:40 AM, Lester Caine wrote: Christopher Jones wrote: When users of 5.5 stumble on the new messages, we can then simply point them to the RFC. I think this is part of the problem. The material from the RFC's should be used as a source to update the core documentation? Rather than another pile of notes. It's not a problem. We point them to the wiki so they can see the rationale behind the change. This potentially reduces user frustration. Our documentation should not have that rationale. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Poor date() performance (v 5.4.9) [PATCH]
On 12/01/2012 10:21 AM, Paul Taulborg wrote: [php_date.c patch] Thanks for the patch. To ensure it isn't lost, can you open a bug at https://bugs.php.net/ and attach it? And/or submit a pull request at https://github.com/php/php-src Regards, Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extension for str_replace / preg_replace with arrays
On 12/19/2012 03:18 PM, Larry Garfield wrote:
You could likely simplify the code even further using an infinite iterator:
http://us1.php.net/infiniteiterator
$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements_iterator) {
return $replacements-next();
},
'word word word word word'
);
--Larry Garfield
What am I missing that causes the first call to
$replacements_iterator-current() to return NULL
unless the iterator is rewound before use?
Chris
--
?php
$replacements = array(
'one', 'two', 'three'
);
$replacements_iterator = new InfiniteIterator(new ArrayIterator($replacements));
$replacements_iterator-rewind(); // why is the rewind needed?
$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements_iterator) {
$r = $replacements_iterator-current();
$replacements_iterator-next();
return $r;
},
'word word word word word'
);
var_dump($result);
// Outputs:
//string(21) one two three one two
// Without the call to $replacements_iterator-rewind(), the output is:
//string(18) two three one two
?
--
christopher.jo...@oracle.com http://twitter.com/ghrd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extension for str_replace / preg_replace with arrays
On 12/20/2012 08:31 AM, Larry Garfield wrote:
On 12/19/12 10:30 PM, Christopher Jones wrote:
On 12/19/2012 03:18 PM, Larry Garfield wrote:
You could likely simplify the code even further using an infinite
iterator:
http://us1.php.net/infiniteiterator
$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements_iterator) {
return $replacements-next();
},
'word word word word word'
);
--Larry Garfield
What am I missing that causes the first call to
$replacements_iterator-current() to return NULL
unless the iterator is rewound before use?
Eh, nothing. You're right, next() doesn't return an element, it just advances,
so you still need the current() call. Which seems kinda silly to me, but
whatev.
That is documented, so it's OK. The curiosity (bug?) is the need to call
rewind():
$replacements_iterator = new InfiniteIterator(new ArrayIterator($replacements));
$replacements_iterator-rewind(); // why is the rewind needed?
$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements_iterator) {
$r = $replacements_iterator-current();
$replacements_iterator-next();
return $r;
},
'word word word word word word word word'
);
In other (simple) scripts using InfiniteIterator the rewind wasn't needed.
--
christopher.jo...@oracle.com http://twitter.com/ghrd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extension for str_replace / preg_replace with arrays
On 12/20/2012 04:05 PM, David Muir wrote:
The curiosity (bug?) is the need to call rewind():
$replacements_iterator = new InfiniteIterator(new ArrayIterator($replacements));
$replacements_iterator-rewind(); // why is the rewind needed?
$result = preg_replace_callback(
'/word/',
function($matches) use ($replacements_iterator) {
$r = $replacements_iterator-current();
$replacements_iterator-next();
return $r;
},
'word word word word word word word word'
);
In other (simple) scripts using InfiniteIterator the rewind wasn't needed.
What happens if you do:
$replacements_iterator = new InfiniteIterator(new ArrayIterator($replacements));
var_dump($replacements_iterator-current());
If I remember correctly, when you pass a traversable into foreach, under the
hood, it basically calls:
$iterator-rewind();
while($iterator-valid()){
$value = $iterator-current();
(foreach block)
$iterator-next();
}
So that might explain why it works in (simple) scripts.
It does seem like a bug that the rewind is required though. A newly created
iterator should already be in a rewound state so the call shouldn't be needed.
Cheers,
David
I logged a bug so this can be tracked and re-discovered:
https://bugs.php.net/bug.php?id=63823
Chris
--
christopher.jo...@oracle.com http://twitter.com/ghrd
Newly updated, free PHP Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding Generator::throw()
On 12/21/2012 06:54 AM, Nikita Popov wrote: If there are no further objections I'll commit this tomorrow. Nikita This feature needs documenting in Generator RFC before it is committed. The RFC will be referenced by people new to the feature and so it should have a complete list of changes. Thanks, Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] strtr vs. str_replace runtime
On 01/09/2013 02:45 PM, Gustavo Lopes wrote: On Thu, 03 Jan 2013 11:40:31 +0100, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: The algorithm behaves very poorly in this case because at each position of the text, all the substrings starting there and with size between m and n (where m is the size of the smallest pattern and n is the largest) are checked, even if there are only two patterns with size m and n. We could fix this easily by building a set of the pattern sizes found and try only with those. The hashing of the substrings could also be improved; we don't have to recalculate everything when we advance in the text. Both optimizations (the hash rolling and limiting the substrings hashed on each iteration) worked quite well. But I got much better results with another algorithm [1], so I'm going to merge the branch with it [2] instead. I get these results with a 1.7 MB string and 13 replacement strings, the smallest with 6 characters and 30 iterations (x86-64, gcc -O3): strtr: 0.1387 str_replace: 0.4471 The algorithm doesn't perform as well when the replacement strings are small. Adding a replacement for the pattern '_' (1 character) yields: strtr: 0.6157 str_replace: 0.6230 How does this compare with your baseline results? But even in this case, it works better than my optimized version of the current algorithm. I plan on merging to 5.4 and 5.5; you may want to review it as introducing completely new code carries some risk. Depending on the improvement, it might be tempting to merge to 5.4 but I would prefer to see it in 5.5+. Let's keep 5.4 stable. Chris [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.13.2927 [2] https://github.com/cataphract/php-src/compare/strtr_wu94 -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP-5.5 unpack change broke pecl/pear
On 12/28/2012 01:08 AM, Remi Collet wrote: Le 24/12/2012 04:16, Igor Wiedler a écrit : Hi Internals, When test driving PHP-5.5 I ran into issues with a change of unpack behaviour. Archive_Tar which is used by pecl and pear (`pecl install`) uses unpack with the a format character. On 5.4 it strips trailing NUL bytes, on 5.5 it does not. There is a new Z format character that can be used to get the old behaviour. The point is, this change broke pecl, and will likely break many other things in existence. Anthony has asked me to post to internals, so that you can re-visit the issue and perhaps consider not breaking BC. If you decide that you want to keep the BC break, I will gladly submit a patch for Archive_Tar. See http://pear.php.net/bugs/bug.php?id=19746 Remi. Thanks, Igor Sherif, Are you owning this issue? I assigned bug https://bugs.php.net/bug.php?id=63073 to you in case you are. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] strtr vs. str_replace runtime
On 01/14/2013 01:55 PM, Gustavo Lopes wrote: On Wed, 09 Jan 2013 23:45:03 +0100, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Thu, 03 Jan 2013 11:40:31 +0100, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: The algorithm behaves very poorly in this case because at each position of the text, all the substrings starting there and with size between m and n (where m is the size of the smallest pattern and n is the largest) are checked, even if there are only two patterns with size m and n. We could fix this easily by building a set of the pattern sizes found and try only with those. The hashing of the substrings could also be improved; we don't have to recalculate everything when we advance in the text. Both optimizations (the hash rolling and limiting the substrings hashed on each iteration) worked quite well. But I got much better results with another algorithm [1], so I'm going to merge the branch with it [2] instead. OK, so now the plan is to merge this onto 5.4: https://github.com/cataphract/php-src/compare/php:PHP-5.4...cataphract:strtr_wu94_54 And this to 5.5: https://github.com/cataphract/php-src/compare/php:PHP-5.5...cataphract:strtr_wu94_55 The difference is that the 5.4 version does not introduce zend_qsort_r() and instead has dedicated simple heap sort. Any thoughts on this? Despite temptation, I'm still erring on the side of merging to 5.5+ only. My argument is based on the potential for regressions (behavior and performance), added code maintenance issues, merge effort etc. The ability to differentiate the benefits of PHP 5.5 over 5.4, and promote migration to 5.5 will also be improved. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.10 can not build Zend/PHP parsers with bison 2.6.5
On 01/14/2013 05:16 PM, Dennis Clarke wrote: Dear PHP/Zend folks : This is a bug I think. I recently saw that PHP had been updated to 5.4.10 and I decided to update my php bits in /usr/local. I was quite surprised to see in the configure output this warning about bison : checking for bison... bison -y checking for bison version... invalid configure: WARNING: bison versions supported for regeneration of the Zend/PHP parsers: 1.28 1.35 1.75 1.875 2.0 2.1 2.2 2.3 2.4 2.4.1 2.4.2 2.4.3 2.5 2.5.1 2.6 2.6.1 2.6.2 (found: 2.6.5). This seems odd to me as bison 2.6.5 builds and tests perfectly on my Solaris 10 server and so therefore I wonder what these PHP folks are on about? Is this a Warning or a real configure fault? If the latter then I need to backout bison in order to build PHP and then re-install a perfectly functional bison ? Dennis Clarke Unless you are hacking PHP you can ignore Bison. Check the Makefile for where it is used. The PHP distribution contains Zend/zend_language_parser.[ch] and php-5.5/Zend/zend_ini_parser.[ch] already built from their respective .y files so bison is not generally invoked when building PHP. Of course, if 2.6.5 is verified than it should be added to bison_version_list in Zend/acinclude.m4. Feel free to regenerate the parsers with it, review the test suite results, and create a github pull request. Chirs -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A problem related to php 5.4.10 and possibly others
On 01/15/2013 06:18 PM, Stas Malyshev wrote: Hi! I will try to wade through the logs tomorrow. At the moment I am doing the same process on RHEL and seeing a bucket of failures also. This URL has some potential to help, since it will show common failures other people are seeing: http://qa.php.net/reports/ RHEL shouldn't have failures in core, though some extension tests may fail (unfortunately, error messages change or library versions change can trip up some modules). Do you have test results file (it is generated at the end of make test if you ask to save test results)? Could be useful to look into it and see what exactly fails. Looking at RH's source RPM [1] for building PHP, you can see they typically update several expected PHP extension logs to make their build run 100% clean. This is just another data point about the large number of environments that PHP runs under, each of which can cause test result differences. Chris [1] You can see the equivalent at http://public-yum.oracle.com/repo/OracleLinux/OL6/latest/x86_64/ -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.10 can not build Zend/PHP parsers with bison 2.6.5
On 01/15/2013 12:09 PM, Dennis Clarke wrote: Of course, if 2.6.5 is verified than it should be added to bison_version_list in Zend/acinclude.m4. Feel free to regenerate the parsers with it, review the test suite results, and create a github pull request. Anything outside of release tarball won't be supported here. Sorry. However ... having said that, it is certainly worth the attempt. Question for you, ever seen PHP build on Solaris 10 with mysql ( in .opt/mysql as per MySQL Release Engineering packages ) and have it pass its own testsuite? I rarely build on Solaris. Other messages in this thread mention how you can assist the PHP community in resolving any issues you do see. Are you building a specific PHP version for a reason? Can you use the pre-built Solaris PHP packages in some situations (e.g. see the Solaris chapter in http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html) Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Bug #63699: performance improvements for varios ext/date functions: NEWS ext/date/php_date.c ext/date/php_date.h
[CC'ing internals.]
On 01/16/2013 03:15 PM, Paul Taulborg wrote:
On Wed, Jan 16, 2013 at 4:21 PM, Nuno Lopes nlop...@php.net wrote:
On Thu, Jan 10, 2013 at 4:59 PM, Nuno Lopes nlop...@php.net wrote:
On 01/07/2013 07:27 AM, Paul Taulborg wrote:
I would love to write this patch, I'm all in favor of simplifying
this. :) We should probably get with derick (cc'd) on this as well, to
make sure something else obvious isn't being missed.
Let me know how you want me to proceed. Thanks :)
Paul,
For small changes submit bugs (and/or github pull requests) like you
did before.
For bigger changes, start an RFC at https://wiki.php.net/rfc
This will help focus the change, and provides a source for any doc
updates.
Since it is really just you and Derick looking at this area, be
prepared
to be a leader.
Don't forget to CC internals.
Chris
PS Note that Derick tends to ignore top-posted email.
Bug/patch submitted:
https://bugs.php.net/bug.php?id=63941
Will post on internals momentarily. Turns out removing
default_timezone entirely won't work due to the callback for ini_set,
but this isn't a major problem. We could probably remove it entirely
with a future patch, but it would require some other internal variable
somewhere along the line anyway.
I have another suggestion that avoids BC break. Pseudo-code:
guess_timezone():
if (timezone) return timezone
if (default_timezone) return default_timezone
return UTC
OnUpdate ini option:
if (valid) {
free(default_timezone)
default_timezone = new
}
PHP's date_default_timezone_set():
if (valid) {
free(timezone)
timezone = new
} else {
timezone = NULL
}
I belive this causes no major BC break and enables efficient code.
Note that according to the manual, date_default_timezone_set() takes
precedence over the ini setting, and therefore we cannot set the
'timezone'
var in the ini handler (as I previously wrongly suggested).
Nuno
Nuno,
Unless I'm misunderstanding or missing something here, this is already
what I did in the patch submitted 4 days ago:
https://bugs.php.net/bug.php?id=63941
I'm still waiting for feedback and for the patch to be applied.
Thanks
Sorry for the delay, but I've been quite busy..
So, to answer your question: I don't think your patch implements the
pseudo-code I suggested above. In particular your patch change the
documented behaviour for intermixed ini_set/date_set_default_tz calls.
Nuno
I would recommend this be changed, and it would not conflict with the
documentation. First, the ini_set() does not say this will not
override date_set_default_timezone(), even though that is the
functionality. A user could easily presume (wrongly), that both do the
same thing (and they should, for consistency). I see no logical reason
to have two values in the core, that do the same thing.
For instance, I could use date_set_default_timezone() in one spot,
then later ini_set, expecting it to override, but it doesn't. This is
an extra nuance for no gain. If the argument is but I might want to
revert back to the ini value!, well, you can't currently without a
literal ini_get() and then another date_set_default_timezone() call.
This is no different than what my patch does, you would have to grab
the original value with ini_get, and then set it via EITHER method.
This simplifies the internal code handling and makes it more
consistent and makes the code a bit easier to follow with regards to
this particular subset of the date section.
If we're going to get in here and start optimizing code, we should do
so, not continue to throw band-aids on that do nothing in terms of
performance gains or code readability/manageability. That is the
reason I tackled this head-on in the way I did, because having both
values internally checked is not necessary. I cannot see any reason to
have two values internally to represent essentially the same thing. If
there is something I'm missing here regarding that, please let me
know.
Thanks
--
christopher.jo...@oracle.com http://twitter.com/ghrd
Newly updated, free PHP Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][vote] 5.3 EOL
On 01/14/2013 01:18 AM, Pierre Joye wrote: Arg, sorry :) Here you go: https://wiki.php.net/rfc/php53eol Pierre, Can you review this RFC and the votes? The wording 5.5 final release needs assessing. You probably meant first 5.5 production release. If anyone interpreted it as it is actually written i.e. terminal 5.5 release, then the vote needs to be re-run. Chris On Mon, Jan 14, 2013 at 10:11 AM, Pierre Joye pierre@gmail.com wrote: hi, I opened the voting phase for the 5.3 EOL RFC. I also changed the polls to reduce confusion between the announce and the actual EOL, to avoid equal results between many options. Thanks for your upcoming votes and let focus and 5.5+ asap :) Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Property Accessors for 5.5
On 01/22/2013 01:27 PM, Clint Priest wrote: In terms of cost of maintenance, I was under the impression that since I wrote it, I would be maintaining it which is why I applied for and you approved a VCS account for me. The concern is historical and not personal. Frequently the long-term contributors to PHP have been left to stabilize, integrate (e.g. with APC), and then maintain code that was contributed. I do note appreciate your outstanding perseverance and leadership in working through the RFC process. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][vote] 5.3 EOL
On 01/23/2013 09:37 AM, Florian Anderiasch wrote: On 01/21/2013 11:44 PM, Christopher Jones wrote: Pierre, Can you review this RFC and the votes? The wording 5.5 final release needs assessing. You probably meant first 5.5 production release. If anyone interpreted it as it is actually written i.e. terminal 5.5 release, then the vote needs to be re-run. How do you plan to find out who would've taken it that way? Ask all who voted? Probably. I suggest being practical and getting a best-effort feel for it. Lack of responses to my email is one indicator that the the community doesn't have an issue with the RFC wording. Maybe it sounds more ambiguous for a native speaker, but I actually had to reread this mail to get your point. I've never heard anyone use final as terminal, I have. There is also a subtle distinction between the use of final in final 5.5.0 and final 5.5. the final in the software development domain has always been the name for the version after the RCs, at least for me. That's the way I took it for my vote. The next day I realized that non-native English speakers might possibly have thought otherwise. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cc: acomp failed for /usr/local/build/php-5.4.11_SunOS5.10_sparcv9.001/ext/curl/interface.c
On 01/24/2013 10:47 AM, Dennis Clarke wrote: So here I am once again trying to build PHP 5.4.11 on a Solaris 10 server with the following configure options : So I think that I should be okay. Do I need to upgrade to curl 7.28.2 and then try building PHP 5.4.11 or am I sort of stuck here at 5.4.9 ? The ext/curl/interface.c diffs between 5.4.9 and 5.4.11 don't seem compiler or libcurl unfriendly. Since the compiler messages don't give a clear compile failure, I can't guess what went wrong. I compiled 5.4.11 with gcc and libcurl 7.21.2 on Solaris 11.1 without an issue. Maybe more regular Solaris users like Johannes or David (aka dsp. Ex Sun, and who wrote http://blog.experimentalworks.net/2012/05/canonical-way-to-build-php-5-4-on-solaris-11/) can guess at the issue.) If you drop the 5.4.9 ext/curl code into your 5.4.11 directory tree what happens? Are you hitting something unrelated in the build process? Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On 01/29/2013 12:30 AM, Zeev Suraski wrote: By the way, I just realized the % gain wasn't all that self-explanatory - it's vs. APC, not vs. plain PHP. I improved the doc to reflect both gains vs. plain PHP and vs. APC. Thanks for the feedback! Zeev Zeev, It would be useful to link to the current Optimizer+ doc from the RFC. I believe the link is http://static.zend.com/topics/Zend-Optimizer-User-Guide-v330-new.pdf Can you comment (in the RFC) on differences that the open source code may have from this documentation e.g. on what Zend Guard integration will be included, or what obsolete features you might clean out? I think an RFC should clearly state what the feature does and doesn't work with. I.e. for this RFC list whether CLI, FastCGI, ZTS etc work. Can you list potential platform or extension (XDebug) portability issues? The RFC still mentions Pierre helping with ZTS, which I believe is a left-over comment?? Since the releae time-frame is an issue that may affect voting, the RFC should also contain more details on what needs integrating. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On 01/29/2013 04:27 PM, Rasmus Lerdorf wrote: On 01/29/2013 04:17 PM, Christopher Jones wrote: It would be useful to link to the current Optimizer+ doc from the RFC. I believe the link is http://static.zend.com/topics/Zend-Optimizer-User-Guide-v330-new.pdf Different beast. Something like this is more apt: http://files.zend.com/help/previous-version/Zend-Server-5-Community-Edition/zendoptimizerplus.html Ah, ack. The PECL extension and/or configure directive should use a better name. This confusion reinforces my main point: the RFC needs more detail about what PHP will end up having. Can you list potential platform or extension (XDebug) portability issues? XDebug together with an opcode cache is always a shaky thing and not something we should be too concerned about. You would never want to run both in production. It would be good if they didn't clobber each other for dev environment purposes, but I am sure we can figure that out. This is the kind of info the RFC (and then user doc) should have. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On 01/30/2013 06:47 AM, Zeev Suraski wrote: This is the kind of info the RFC (and then user doc) should have. I updated the RFC with two extra sections - 'what's an opcode cache', This section extremely general and doesn't explain what the expected feature set might look like. I'm not asking for absolute certainties, just a technical description of what is and isn't the goal. Is it the complete Optimizer+, are there potential cleanups, do you see it being enabled (if not in PECL) or disabled by default, etc. Did I miss seeing the link to the current optimizer+ documentation? http://files.zend.com/help/previous-version/Zend-Server-5-Community-Edition/zendoptimizerplus.html (thanks Rasmus) Your email comment to John Carter about Zend Guard decoder is also not (yet) in the RFC. Chris and 'interaction with other plugins'. https://wiki.php.net/rfc/optimizerplus Zeev -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] clearing up who can propose RFCs
On 01/29/2013 06:10 AM, Ferenc Kovacs wrote: On Fri, Sep 14, 2012 at 12:47 PM, Pierre Joye pierre@gmail.com wrote: hi Ferenc, Can you put that in the wiki too instead? So it can be clarified there directly if necessary. Thanks, I've put it up under https://wiki.php.net/rfc/howto feel free to extend or improve the wording/formatting. I blogged about how I have seen the RFC process working in practice: https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process Flame away, Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/14/2013 08:02 AM, Nikita Popov wrote: On Thu, Feb 14, 2013 at 4:21 PM, Zeev Suraski z...@zend.com mailto:z...@zend.com wrote: - Should the name reflect the code's main purpose (op-code caching), and allowing a future use of optimizer for a more sophisticated optimizer implementation? Or do you see Optimizer+ being the framework for such optimizations? O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) If this will go into PECL first then I see no reason to change the name from Optimizer+. If this will go into PHP then it shouldn't need a name at all, should it? It could just be opcode cache (--enable-opcode-cache / --disable-opcode-cache). That seems more descriptive to me then some fancy name like Optimizer+. Regarding the optimizations it contains, imho those are a separate concern and if Optimizer+ goes into core both aspects should be cleanly separated (and you should be able to enable/disable them separately). The optimizations are not directly related to caching. Caching makes them more viable for web requests, but as someone already pointed out the optimizations are also useful on CLI, where compile times just aren't a concern anyway (but run times can be). This raises questions for Zeev to address. Btw, I was quite surprised to see the block optimizations in O+ :) Really cool! Nikita The php.ini parameters will likely need a name (or two - if the optimizer is distinct from the op-code cache) as a prefix. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/14/2013 07:21 AM, Zeev Suraski wrote: Great to see. The README covers much of the content (and in more detail) that I previously wanted to see in the RFC. Excellent! There are some things still missing from the RFC, though: - do you see Optimizer+ being enabled (if not in PECL) or disabled by default, etc. I *think* we should strive to have it enabled by default, but it should definitely be possible to turn it off too. I guess that can be another voting possibility - bundle turn on by default (vs. just bundle). To avoid too many voting choices, I think this can be decided outside the RFC process. - your email comment to John Carter about Zend Guard decoder We don't want to create any special cases in O+; We would either take care of integrating it by having slightly patching our O+ build, or we'd add generalized facilities to O+ that will allow the loader to interact with it directly (that would not be unique to the Zend loader but could be used by any extension). From my point of view, it's nice-to-have to solve it before 5.5.0, not a must-have. This should still be stated in the RFC. (The PHP community suffers from poor RFCs. Since you are a leader in the PHP community, your RFC should set a good example.) - There are still open questions in the RFC; these need to be closed before voting. I think the only open question is integration with other modules, most notably debuggers. This is something we'd like to tackle sooner rather than later, and I think it'll be easier to just go ahead and do that now that the source code is available. Any other open questions that need answering? I think this should be reworded before the vote occurs. I'm fine with leaving it under a heading for future investigation, i.e. stating it won't happen in an initial release. Comments: - The README gives recommended parameters. Taking that advice at face value, I think these should be default settings. The default settings are designed to minimize the chance that an app or a workflow - which worked fine w/o O+ - will suddenly fail after O+ is installed. The 'recommended' settings are for max-performance. You can view it like 'Safe' vs. 'Extreme' settings. Personally I think the default settings should be closer to the Safe ones... We can probably meet in the middle: leave the hard coded defaults as they currently are, and use those values in the php.ini-development examples. Php.ini-production can have the values recommended in the README. (Giving the proposed php.ini settings is another thing the RFC should have...) - Should the name reflect the code's main purpose (op-code caching), and allowing a future use of optimizer for a more sophisticated optimizer implementation? Or do you see Optimizer+ being the framework for such optimizations? O+ does perform some optimizations in addition to caching code, in a pretty sophisticated manner actually (block optimizations). Optimizations - which can be expensive to carry out - are definitely a good fit with an opcode cache, that ensures that you wouldn't have to do these optimizations more than once. I'm obviously subjective but I think the name Optimizer+ does a good job at suggesting that it's both an Optimizer but also something else. Perhaps we should call it OptiCache? :) It seems a good time to disambiguate its relationship to any current or future Zend product. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Zend Optimizer+ Source Code now available
Hi Zeev, I think people are keen to see Optimizer+ merged. Hopefully the RFC can set expectations clear on what the short-term steps will be, and what the bigger picture might look like. The middle-term tasks will then work themselves out as we get to them (in true PHP fashion) - What does Integrate Optimizer+ into PHP, but don’t delay 5.5.0 for it mean? Does it mean: * Work really had to get it into PHP 5.5.0 with no delay to 5.5? * Include it in /ext as-is, i.e. perhaps no ZTS support, or marked EXPERIMENTAL? * Include it in PHP 5.5.x where x 0, when Optimizer+ is complete? The slippage of 5.5 is an issue to some people, so clarity here would be good. I believe the wider community is expecting the op-code cache to just work, so if that's not the case, the RFC should communicate this clearly. There's also the potential to damage Zend's reputation if what is released doesn't work well. - What are your general thoughts about its integration architecture and the potential for alternative op-code caches to be used? I know code can always be changed, but what (if any) design will happen from the start to make this easy? - Regarding name choice, here are some: ZopCache, Cachze, RunCachze. Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/16/2013 01:10 PM, Rasmus Lerdorf wrote: On 02/16/2013 11:16 AM, Zeev Suraski wrote: - Regarding name choice, here are some: ZopCache, Cachze, RunCachze. Interesting names, I'm curious about pronunciation :) I (mostly) pronounce cache the non-American way as kaysh. Cachze would be like that with a bit of Z sound. I don't think I would ever get neither the spelling nor the pronunciation of Cachze right. I like the much simpler opcache name. I agree that unless we get Gopal-like inspiration (inclued, scream) for naming, opcache is best. Chris -Rasmus -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Optimizer+ Source Code now available
On 02/18/2013 10:52 AM, Christopher Jones wrote: I agree that unless we get Gopal-like inspiration (inclued, scream) for naming, opcache is best. In the so bad I can't resist sending it category is today's semi-humorous name suggestion: Cajun. It sounds roughly like the English pronunciation of caching Sadly it's not as nicely self-documenting as opcache. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Short syntax for anonymous functions
On 02/19/2013 09:45 AM, Marcello Duarte wrote: And just for you is also inaccurate. You will find that the technologies I've been referring to are becoming the tools you will use for DevOps, etc... tasks. Do you guys listen to people outside of internals? It would be good to have a feedback mechanism that actually involve PHP developers in real world projects. I take that if you are coding with other languages like C, all the time, that you may loose contact with the way things are done. I should add don't flame existing developers to https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process (Note that In summary paragraph at the end). Without getting into the merits of the syntax change, I will say that the RFC is missing a lot: who will write the patch, where are examples of syntax in other languages, where is the clear comparison with existing PHP syntax, what are the quantifiable benefits. Don't forget to update the RFC with the mail list comments, e.g. the BC issue. Even if your RFC is rejected, it will help future PHP development if the RFC contains a summary of mail list discussions. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP causing high number of NFS getattr operations?
On 02/19/2013 03:08 PM, Terry Ellison wrote: I guess that I should bite the bullet and switch to 5.5. Yes. I've been working on an evaluatorfork of APC optimized for CLI/GCI which tackles a lot of these issues head on and performs reasonable well, but I realise that this is a dead-end and will never get deployed, but I am currently considering regressing some of this technology into 5.5 and O+. Are you interested in a version of O+ which supports all SAPIs? Yes, but there are some SAPIs that are more common, so these should be prioritized if trade-offs are required. My particular desire is for embed SAPI support. We use this in our Tuxedo application server, but it is a relatively niche use case. In architectural terms I feel that having a universal cache option is important. It changes the mindset from something which is only used in niche performance use cases to a standard option. It also means that the cache can be stress tested by the entire php test suite. However, to do some of this you don't start with a patch, but with an RFC informed by evidence, and that's my real reason for doing this demonstrator. I'm looking forward to seeing your suggestions and patches. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 : a new API ?
On 02/19/2013 11:22 PM, Klaus Ufo wrote: Hi there ! We all know that the current PHP API has flaws. Maybe we could use namespaces to build a new coherent PHP API ? Like : - \arr - \num - \str and so on. Advantages : - no more global functions - separation of concerns - backward compatibility - work can be done progressively - easy to add user-defined functions (using php namespaces) - we could provide a \str\utf8 namespace This is just an idea. I don't know what is your vision for a next PHP 6. KH While it's good to see people float ideas, what is needed is real commitment to write the code to implement them. Can you comment on what participation you envisage for yourself? At the moment your email sounds like a someone should do list (see point 4 of https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process). If this isn't the case, I look forward to seeing some prototypes from you or from anyone else willing to contribute to your ideas. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP User Survey
On 02/20/2013 12:00 PM, Paul Reinheimer wrote: Hi All, My apologies for the intrusion, I'll keep this brief. In many discussions over the past few months there has been talk about what the community at large needs. Pierre said just earlier today: I would also say it us time for us to get back in sync with the communities needs. I am not talking about the last days RFCs but in general. Hi Paul, My thesis is the other way round. More people in the community need to become PHP core developers. This is historically how PHP development has occurred, since nobody has idle time to adopt projects they are not 100% behind. Increasing user involvement is easier (and more often) said than done. I'd prefer to see effort spent mentoring, rather than running surveys. I do have a lot of reservations about a survey. But if you do run one, I'm sure I'll look at the results. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP User Survey
On 02/21/2013 03:02 AM, Florian Anderiasch wrote: On 02/21/2013 08:14 AM, Pierre Joye wrote: I do not have a single doubt. Why? Surveys are one of many ways to get feedback. They have no contracting values but give us some numbers about one rfc or another. That may help us to focus on one feature instead of another if we see a large number of users looking forward to it. You'll never get perfect results, but I prefer results at all over none :) There have been a lot of those for other languages: - http://cemerick.com/2012/08/06/results-of-the-2012-state-of-clojure-survey/ - http://survey.perlfoundation.org/ - http://survey.hamptoncatlin.com/ For the mail archives, there are also these (more focused) reports: http://static.zend.com/topics/zend-developer-pulse-survey-report-Q2-2012-0612-EN.pdf http://downloads.zend.com/guides/whitepapers/State_of_PHP_in_the_Enterprise_061212.pdf Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Improved Linux process title support in the CLI SAPI
On 02/21/2013 04:42 PM, Keyur Govande wrote: Hi everyone, With the 2 weeks discussion period up, I'm moving this RFC to the Voting stage. I'd like to get this into 5.5. Most of the reaction has been positive and is archived here: http://marc.info/?t=13602158203r=1w=2 Please vote on https://wiki.php.net/rfc/cli_process_title. Voting ends on March 4, 2013. Thanks, Keyur. The patch is failing to link php in the current 5.5 snapshot, php5.5-201302221630. I did: $ cd php5.5-201302221630 $ patch --strip 1 280.patch patching file sapi/cli/config.m4 patching file sapi/cli/config.w32 patching file sapi/cli/php_cli.c patching file sapi/cli/php_cli_process_title.c patching file sapi/cli/php_cli_process_title.h patching file sapi/cli/php_cli_server.c patching file sapi/cli/php_cli_server.h patching file sapi/cli/ps_title.c patching file sapi/cli/ps_title.h patching file sapi/cli/tests/cli_process_title.phpt patching file sapi/cli/php_cli_process_title.c $ ./configure --disable-all [ . . . ] $ make [ . . . ] /bin/bash /home/cjones/Desktop/php5.5-201302221630/libtool --silent --preserve-dup-deps --mode=link cc -export-dynamic -g -O2 -fvisibility=hidden ext/date/php_date.lo ext/date/lib/astro.lo ext/date/lib/dow.lo ext/date/lib/parse_date.lo ext/date/lib/parse_tz.lo ext/date/lib/timelib.lo ext/date/lib/tm2unixtime.lo ext/date/lib/unixtime2tm.lo ext/date/lib/parse_iso_intervals.lo ext/date/lib/interval.lo ext/ereg/ereg.lo ext/ereg/regex/regcomp.lo ext/ereg/regex/regexec.lo ext/ereg/regex/regerror.lo ext/ereg/regex/regfree.lo ext/pcre/pcrelib/pcre_chartables.lo ext/pcre/pcrelib/pcre_ucd.lo ext/pcre/pcrelib/pcre_compile.lo ext/pcre/pcrelib/pcre_config.lo ext/pcre/pcrelib/pcre_exec.lo ext/pcre/pcrelib/pcre_fullinfo.lo ext/pcre/pcrelib/pcre_get.lo ext/pcre/pcrelib/pcre_globals.lo ext/pcre/pcrelib/pcre_maketables.lo ext/pcre/pcrelib/pcre_newline.lo ext/pcre/pcrelib/pcre_ord2utf8.lo ext/pcre/pcrelib/pcre_refcount.lo ext/pcre/pcrelib/pcre_study.lo ext/pcre/pcrelib/pcre_tables.lo ext/pcre/pcrelib/pcre_valid_utf8.lo ext/pcre/pcrelib/pcre_version.lo ext/pcre/pcrelib/pcre_xclass.lo ext/pcre/php_pcre.lo ext/reflection/php_reflection.lo ext/spl/php_spl.lo ext/spl/spl_functions.lo ext/spl/spl_engine.lo ext/spl/spl_iterators.lo ext/spl/spl_array.lo ext/spl/spl_directory.lo ext/spl/spl_exceptions.lo ext/spl/spl_observer.lo ext/spl/spl_dllist.lo ext/spl/spl_heap.lo ext/spl/spl_fixedarray.lo ext/standard/crypt_freesec.lo ext/standard/crypt_blowfish.lo ext/standard/crypt_sha512.lo ext/standard/crypt_sha256.lo ext/standard/php_crypt_r.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo ext/standard/url.lo ext/standard/var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard/strnatcmp.lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo ext/standard/css.lo ext/standard/var_unserializer.lo ext/standard/ftok.lo ext/standard/sha1.lo ext/standard/user_filters.lo ext/standard/uuencode.lo ext/standard/filters.lo ext/standard/proc_open.lo ext/standard/streamsfuncs.lo ext/standard/http.lo ext/standard/password.lo TSRM/TSRM.lo TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/fopen_wrappers.lo main/alloca.lo main/php_scandir.lo main/php_ini.lo main/SAPI.lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo main/strlcat.lo main/mergesort.lo main/reentrancy.lo main/php_variables.lo main/php_ticks.lo main/network.lo main/php_open_temporary_file.lo main/output.lo main/getopt.lo main/streams/streams.lo main/streams/cast.lo main/streams/memory.lo main/streams/filter.lo main/streams/plain_wrapper.lo main/streams/userspace.lo main/streams/transports.lo main/streams/xp_socket.lo main/streams/mmap.lo main/streams/glob_wrapper.lo Zend/zend_language_parser.lo Zend/zend_language_scanner.lo Zend/zend_ini_parser.lo Zend/zend_ini_scanner.lo Zend/zend_alloc.lo Zend/zend_compile.lo Zend/zend_constants.lo Zend/zend_dynamic_array.lo
