[PHP-DEV] Re: [External] : [PHP-DEV] [VOTE] [RFC] Unbundle ext/imap, ext/pspell, ext/oci8, and ext/PDO_OCI

[Christopher Jones]

On 2/11/2023 2:46 am, Derick Rethans wrote:

Hi,

I have just opened voting on the RFC to unbundle imap, pspell, and
oracle integrations.


:)

--
https://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [External] : [RFC} Unbundle ext/imap, ext/pspell, and ext/oci8

[Christopher Jones]

On 27/9/2023 11:27 pm, Derick Rethans wrote:

Hi,

after the initial introduction, here is the formal RFC to unbundle the
imap, pspell, and oci8 extensions and move them to PECL, for PHP 8.4.

https://wiki.php.net/rfc/unbundle_imap_pspell_oci8

cheers,
Derick


Hi Derick,

A small point: the bug URL for OCI8 in the RFC includes issues for 
PDO_OCI - which is not part of the RFC.


Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [External] : [PHP-DEV] Re: [VOTE] Deprecations for PHP 8.1

[Christopher Jones]

On 12/7/21 5:49 pm, Nikita Popov wrote:

On Wed, Jun 30, 2021 at 11:32 AM Nikita Popov  wrote:


Hi internals,

I have opened voting on 
https://urldefense.com/v3/__https://wiki.php.net/rfc/deprecations_php_8_1__;!!ACWV5N9M2RV99hQ!eOdPIFLsofVNrUBd4W7sbMWdcjqDAxoj6dUr1ubpwolU9F88ArjY_it8fiKBOoU67d5vLg$
 .
The vote closes on 2021-07-14.

This RFC is a collection of various deprecation suggestions from different
people. Each deprecation is voted separately, and should be considered on
its own merit.

Most deprecations should be uncontroversial, but there are some more
contentious ones as well: See 
https://urldefense.com/v3/__https://externals.io/message/113657__;!!ACWV5N9M2RV99hQ!eOdPIFLsofVNrUBd4W7sbMWdcjqDAxoj6dUr1ubpwolU9F88ArjY_it8fiKBOoXqarWpuA$
  for
additional discussion.


The oci8.old_oci_close_semantics deprecation is looking for someone to
implement it (I'm not sure who added it in the first place). I have
everything else covered, but don't have an oci8 test environment to work on
this one.

Regards,
Nikita


I will do it.

Chris

--
https://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Preparing for PHP 8.0.0 GA

[Christopher Jones]

On 20/11/20 1:50 am, Sara Golemon wrote:

I've just cut the release branch for PHP-8.0.0 final which will be released
in one week on 26 Nov.  Minor bug fixes can continue to be merged via the
PHP-8.0 branch for inclusion in 8.0.1, but 8.0.0 will be precisely what
8.0.0RC5 contained unless serious issues are encountered.


What is the status of Windows builds?

In particular who can I work with to get the build to use updated Oracle client libraries for the OCI8 extension in the PHP bundle and the upcoming 
OCI8 3.0 release on PECL?  I.e. drop building with 11g and add 19c?


Fine print: Oracle 19 is a long-term release.  Using Oracle Client 19c 
libraries lets OCI8 connect to Oracle DB 11.2 or later.

Chris

--
https://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Cleaning up unmaintained extensions

[Christopher Jones]

On 18/6/18 5:43 am, Stanislav Malyshev wrote:

Hi!

I would like to open the vote for the RFC about cleaning up the
unmaintained extensions:

https://wiki.php.net/rfc/umaintained_extensions

The vote ends 2018-06-26 23:59 PDT.

I have added some discussion about active maintainers and abandonment
procedures, this can be refined further later. I also kept the list of
the candidates as-is for now, but I will update it soon and probably
make a separate wiki page for maintaining it. Please note this list is
not part of the vote (the vote is on the process, not specific list
which will change all the time).

Thanks,

- I know we're all online all the time, but I would have gone for a 4 week 
period instead of 3.  Many countries have significant vacation periods.

- the "community maintained" option looks OK.

- Since this is a process & policy RFC that has a long lifespan as a reference, 
what about renaming it to 'PHP RFC: Process for Unmaintained Extensions'?

[Somehow https://wiki.php.net/rfc should capture these active references. 
Currently they are in the same section as things such as PHP 5.3 EOL]

Chris

--
http://twitter.com/ghrd

Re: [PHP-DEV] [RFC][VOTE] Flexible Heredoc and Nowdoc Syntaxes

[Christopher Jones]

On 2/11/17 8:58 am, Stanislav Malyshev wrote:

Hi!


Voting has now started on the flexible heredoc and nowdoc syntaxes RFC[1].


Voting will be open for 2 weeks (until November 15th).

Something I am missing here. RFC is talking about removing indents from
heredoc text, but the vote says "Allow for the closing marker to be
indented?" and does not mention that indenting closing marker also
changes how the rest of the heredoc is parsed. Is this still the case?




I'm going to have to assume so and vote No.

Chris

PS. RFC writers: please take care when writing specs.


--
http://twitter.com/ghrd


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes

[Christopher Jones]

On 24/10/17 8:27 pm, Thomas Punt wrote:


Hi Christopher,


> I like the added flexibility in placement of the end token, but I think requiring only tabs or spaces, and stripping whitespace from all 
{here|now}doc

> lines is error prone and adds unnecessary complexity.

I agree that the requirement for using either tabs or spaces is not necessary, 
but
I included it because it does help with readability when looking at the 
indentation
level of the heredoc and nowdoc (and subsequently how much whitespace will
be stripped from each line). With respect to the stripping of whitespace, 
however,
I feel that this is definitely necessary.


If developers accidentally add/subtract leading space from the closing token 
then the whole string changes;  this can lead to subtle bugs and annoyances.

Chris


If it was not stripped, then indenting the
closing token and body will cause a lot of whitespace to prepend every line in
the body of text. This is definitely not desirable, and may cause programmers to
continue to not indent the body of the heredoc/nowdoc, which leads us back to
where we currently are of having indentation of code ruined with such syntaxes.

Other languages follow these semantics of stripping whitespace from new lines

according to the indentation of the closing marker, such as Elixir (normal """ 
syntax)

and Ruby (special <<~ syntax).


Thanks,

Tom



--
http://twitter.com/ghrd

Re: [PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes

[Christopher Jones]

On 13/10/17 8:40 pm, Thomas Punt wrote:

Morning internals,


I'd like to propose an RFC to make the heredoc and nowdoc syntaxes more 
flexible[1]. Any thoughts?


Thanks,

Tom


[1]: https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes



I like the added flexibility in placement of the end token, but I think requiring only tabs or spaces, and stripping whitespace from all {here|now}doc 
lines is error prone and adds unnecessary complexity.


Chris

--
http://twitter.com/ghrd


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] com php-src: fix default args for --with-pcre-valgrind: ext/pcre/config0.m4

[Christopher Jones]

On 20/7/17 10:31 am, Anatol Belski wrote:

Hi Chris,


-Original Message-
From: Christopher Jones [mailto:christopher.jo...@oracle.com]
Sent: Thursday, July 20, 2017 2:11 AM
To: Anatol Belski <a...@php.net>; php-...@lists.php.net; Tianfang Yang
<tianfang.y...@oracle.com>
Subject: Re: [PHP-CVS] com php-src: fix default args for --with-pcre-valgrind:
ext/pcre/config0.m4

Hi Anatol,

7.2 & 7.3 builds now fails for me on macOS and Oracle Linux 7 with:

checking for Valgrind headers location... configure: error: Could not find
valgrind/memcheck.h
Configure failed

Do we really want users to have to explicitly disable PCRE valgrind when they 
are
using --enable-debug?


It wasn't by default in the first version, later it was suggested by Nikita and 
for debug mode certainly makes sense, as for me. The reason behind this option 
is the upgrade of the bundled PCRE, which shows a lot of false positives 
without the integrated Valgrind support. Also I was basing on the fact the 
debug mode is actually developers only, normal use wouldn't be affected 
therefore. Why would users do debug builds?

On a dev machine Valgrind would be anyway present. For developers it's best to 
have it by default, as PCRE usage is spread around the core here and there. Bug 
fixing also does normally involve valgrind checks. I wouldn't see the option 
itself as a big question, either way. If many people find the default 
enablement unsuitable, so the behavior can be reversed.

Regards

Anatol

I'm not totally convinced merging debug-level arguments makes sense (why not always enable --enable-phpdbg-debug too?)  But there are more important 
things to worry about, so I won't stress.


BTW, './configure --help' prints the --with-pcre-valgrind=DIR help twice.

Chris

--
http://twitter.com/ghrd


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Doxygen

[Christopher Jones]

On 26/6/17 4:43 pm, Joe Watkins wrote:

Morning,

I also voted no for similar reasons to Anatol.

This is not really a thing that needs a vote, this is a thing that requires
the handful of people who are actually able to document ZE to spend
considerable time doing so. In addition it requires a commitment from the
community of developers to continue to maintain, and introduce inline
documentation with new code.

Additionally, I'm a little concerned that an RFC that has the potential to
touch every single source file has gone to vote with a simple majority. It
would seem that we are deciding that new code must be documented in this
specific way, to say nothing of the massive task of documenting existing
code. That would seem to be a decision that could effect everybody that
works on PHP in perpetuity and a simple majority is nothing like a strong
enough consensus.

Cheers
Joe


I agree that although the intention is good, the burden on developers is likely
to cause it to be unsuccessful.  The current state of inline documentation is
partly the result of the culture of PHP, but also the general reluctance of
developers to create documentation :(

Chris



On Sat, Jun 24, 2017 at 10:59 PM, Anatol Belski  wrote:




-Original Message-
From: Fleshgrinder [mailto:p...@fleshgrinder.com]
Sent: Saturday, June 24, 2017 11:34 PM
To: php-internals ; Anatol Belski

Subject: Re: [PHP-DEV] [RFC] [Vote] Doxygen

On 6/24/2017 11:28 PM, Anatol Belski wrote:

I voted no, because it is too short term and I'd see a productivity
drop having such an obligation suddenly right in place for 7.2. To
implement the change, there's more than just to put the doc into the
source. Every piece of code needs to be revisited by someone who
understands it.

I'm not saying the current situation is better than the aim, but to be
realistic - the change needs a culture to be developed. It is clear,
that some know doxygen, but I believe maintaining the doc will be
still a huge effort for many contributors. If some patch were in place
- at least one would have a source for learning by watching, so it
would reduce the learn hurdle  Without being familiar with Doxygen
the actual productivity will for sure suffer.

Neither there's a patch covering at least the very core, nor there's a
strategy for the transition period. I can imagine, that even if the
RFC is voted positive, many contributors not familiar with doxygen
won't have time to complete the doc part. The intention good, but the
assertion might be hard. I might be wrong, but ATM I think the
intention is good, whereby the RFC implementation owes IMHO some
elaborated strategy.

Regards

Anatol


We are only voting that we want to use Doxygen for documentation as a
format, not that documentation is a must for PRs or anything. From the

RFC:

This RFC does not propose any big documentation fest where development
is halted and everybody starts writing documentation. Rather to start
documenting in the future, as well as while refactoring or rewriting
existing code.

Hence, it would be nice to write a little while one is working on

something

anyways.

There is no must to document!


Ok, that was my very concern. Documenting the existing code would also
need profound reviews.


There is a must that IF you document, that it must use Doxygen.

That's what we are voting on. Everybody has plenty of time to get

acquainted

with Doxygen and we can create follow-up RFCs with clearer rules on how

to

document (if need be).


I'd still see an issue, the formulation is a bit slack. If I don't have
to, probably I'd spare 10 minutes I'd have to spend, because a bug
investigation or implementation would take a triple time or more. Depending
on what it takes for me personally in the sum, it could be at least 1 hour
a week, most even 8 hours in a week, that's huge. I'd still say, it needs a
strategy and the community says it's a must. Otherwise, the doc might come
not from a person who implements or understands it. Or - the doc would only
reflect function signatures, which are anyway browsable with lxr, by grep
directly, or the code can be studied from the source.

Thanks

Anatol




--
http://twitter.com/ghrd


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Doxygen

[Christopher Jones]

On 22/6/17 1:43 am, Fleshgrinder wrote:

On 6/21/2017 5:38 PM, Nikita Popov wrote:

Can you please clarify where functions that are declared in a header and
defined in a source file should be documented? I believe the usual
recommendation is to document in the source file, because it's closer to
the implementation and thus more likely to be updated. On the other hand,
documentation in headers only is more useful if you're just browsing code
and not using generated output.

Nikita



The documentation should go into the header file. Source files actually
must not have documentation, because everything in there is private
anyways. Unless it is exported via a header file that is. Doxygen will
automatically inherit the documentation (no @inheritDoc necessary),
because it understands the C code in C mode.


That kind of detail belongs in the RFC.

A link to existing 'prior art' would have rounded the picture out and let
people decide between alternatives of internal vs external doc.
E.g. link to https://wiki.php.net/internals/references

Also, is this for core and for extensions?  Or for core only?  What
about PECL extensions not part of the PHP bundle?

In summary, see point 8 of 
https://blogs.oracle.com/opal/the-mysterious-php-rfc-process-and-how-you-can-change-the-web

Chris



Documentation should never document what the implementation does, only
how it can be used. This gets blurry if you implement a particular,
standardized algorithm (like the UUIDs) where the actual implementation
suddenly becomes an important part of information that should go into
the documentation.

In other words, refactoring and other changes in a functions body should
not require changes of the documentation. A usage change usually
directly translates to a breaking change. A situation in which many
places require updates (e.g. CHANGELOG, NEWS, ...) and not something a
dev should do without thinking about the implications of doing so.



--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Doxygen

[Christopher Jones]

On 17/6/17 5:53 pm, Fleshgrinder wrote:

Hi!

I started voting on the Doxygen RFC:

https://wiki.php.net/rfc/doxygen


Did I miss seeing when the vote ends?

Chris

--
http://twitter.com/ghrd


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Extensions License

[Christopher Jones]

On 15/6/17 10:34 pm, Johannes Schlüter wrote:

On Do, 2017-06-15 at 11:06 +0200, Nikita Popov wrote:

On Tue, Jun 13, 2017 at 8:23 AM, Remi Collet 
wrote:


Hi,

All extensions in php-src are PHP 3.01 Licensed
(libs may, of course, have different license)

Is there any strong rule about this ?
Or is it OK to have a BSD Licensed extension ?

Context: see sodium PR
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_php_php-2Dsrc_pull_2560=DwIDaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y=VGZgqeH18gkOkITtpv0ZRNfFvmlvCHdsjJ13Zu2yIv4=


IMHO, make sense to have only PHP Licensed ext.


I think we should allow BSD/MIT licenses, as they are compatible with
and
less restrictive than the PHP license. TBH, the PHP license seems
somewhat
dubious when applied to extensions, as most of the additional clauses
are
simply not applicable (extensions do not bundle the Zend Engine and
extensions have no control over the PHP group or the PHP name).



What about the Apache 2 license?

I'd like to be able to include the ODPI-C library code [1] in PDO_OCI and/or 
OCI8.
It is being used for Python cx_Oracle [2] and Node.js node-oracledb [3].
ODPI-C is under a dual license, one of which is Apache 2.


Mind: The PHP License[1]  doesn't talk about the Zend engine, but "PHP
Software", "PHP Software" is, since PHP License 3.01 compared to PHP
License 3.0 defined as PEAR, PECL and PHP on [2]

The "this software includes the ZendEngine" thing in the PHP
distribution's license file[3] is not part of the PHP License, but a
requirement for the PHP product, which includes the Zend Engine
product, which is licensed under the Zend Engine License[4].

According to the most legal interpretations I know (IANAL ... ask two
lawyers, get three answers ...) a BSD-licensed extension bundled in PHP
would be relicensed under PHP license "automatically" when being
distributed as part of the PHP product.


IANAL-too, and haven't talked to one about this - but will one day.


I however think it makes sense to license all bundled extensions as PHP
license with copyright PHP Group as this simplifies moving code around
(i.e. if a BSD licensed extension contains some nice macro which might
be useful to put into main/ this is simpler from a stricter legal pov
if it's the same license)


True.

Chris

[1] https://github.com/oracle/odpi
[2] https://github.com/oracle/python-cx_Oracle
[3] https://github.com/oracle/node-oracledb/tree/dev-2.0


johannes

[1] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__php.net_license_3-5F01.txt=DwIDaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y=7x6vjEasY6oe1GzH9OXDBE3pXyveWOz8ls3sXtwy1vw=
[2] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__php.net_software.php=DwIDaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y=g1dWNiQpuE2RR-lswQmJXYYD_zwkAzYd1bVVRLXOVBw=
[3] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__git.php.net_-3Fp-3Dphp-2Dsrc.git-3Ba-3Dblob-3Bf-3DLICENSE-3Bh-3D9964e0737cc9be=DwIDaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y=ZUqrUXKbNqC3ECQzQRCh6wTF8HWoWt18RInPHAMHcQM=
0521b056be697a5fbeb14d01ef;hb=refs/heads/master
[4] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__git.php.net_-3Fp-3Dphp-2Dsrc.git-3Ba-3Dblob-3Bf-3DZend_LICENSE-3Bh-3D8acb9af4f=DwIDaQ=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10=lLpUdeB4xTiOOWD6yGzxPFv2SHvPzg3yLT7kvD-ZfyU=GT6MkgICJHeF19FAbAaTtuH4St0KJibc9P1oLj7395Y=3J0pO0pb7tkfrqMlrZeaJ729znnn2I8lQqGW_lIt51I=
8a589076f305c31501565a2cfe0f6ff;hb=refs/heads/master



--
http://twitter.com/ghrd


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7.2 Release Managers

[Christopher Jones]

On 29/3/17 2:11 am, Sara Golemon wrote:


On Tue, Mar 28, 2017 at 9:56 AM, Joe Watkins  wrote:

With the first alpha of 7.2 due in early June, we think it's time to start
the process of finding and electing release managers for the next minor
release of PHP.

We are looking for two souls to take on this role. Whomsoever is elected
will be guided and helped by Davey and I, until they are comfortable, or
correcting Davey and I, whichever comes first.

Candidates should have a reasonable knowledge of internals (without
necessarily being a C guru), be confident about merging pull requests
without breaking backward compatibility, doing triage for bugs, liaising
with previous release managers, and generally getting the branch in good
shape, as these are among the activities you will be undertaking as release
manager.

Please put your name forward here if you wish to be considered a candidate.


I keep meaning to have a go at this, and with such inspiring mentors
at the ready, there's really no better time than now.

-Sara


+1

--
http://twitter.com/ghrd


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO

[Christopher Jones]

On 1/3/17 12:58 am, Adam Baratz wrote:

Merging responses here...

Are PARAM_STR_UNICODE, ATTR_UNICODE_STRINGS and PARAM_STR_ASCII the most 
appropriate names?


Good point. Maybe instead:

  * PDO::PARAM_STR_NATL
  * PDO::ATTR_NATL_STRINGS
  * PDO::PARAM_STR_CHAR

How does this interact with different character sets used for the 
connection, if at all?


I don't think that should matter. This is strictly a hint for the quote functions to put 
an "N" at the beginning of their output.

DBAL maintainer here: before we introduce even more complexity into the PDO 
stuff (which is already a maze), could a set of test cases be
written, so that stuff that is currently impossible to do without this RFC 
is clearer/demonstrated?


The other RFC I mentioned included a similar solution to this problem. The PR I 
put together for that should make this clear enough:
https://github.com/php/php-src/pull/2168 


I'm asking because we didn't get any bug reports about extended string 
types for Doctrine DBAL, and adding new types just to workaround the
limitations of the usual suspects is shotgun surgery, and just more 
complexity to handle.


I think of them more like flags, like PDO::PARAM_INPUT_OUTPUT, than standalone types. Since you apply with a bitwise-OR, the addition would be 
minimally invasive. And you wouldn't have to rewrite code if you switch drivers. The flags would simply be ignored.


(remember that PDO for SQLServer is experimental, if not totally unusable)


I'm mainly interested in pdo_dblib, which is an officially maintained extension 
(I'm the maintainer). I assume you're referring to pdo_sqlsrv?

More importantly, what about allowing arbitrary quote delimiters?


https://livesql.oracle.com/apex/livesql/file/content_CIREYU9EA54EOKQ7LAMZKRF6P.html




This functionality seems orthogonal to what I'm describing. It would be more appropriate to implement this as a driver-specific attribute for 
pdo_oci. But since that driver doesn't support emulated prepares, I'm not sure how much value it would have.


Isn't the same quoting functionality available via the quote() method?  That's 
what the PR's tests use.

I don't think it's orthogonal.  There are various ways to quote strings and a 
generic PDO solution should be flexible enough to handle all drivers.

Chris


Thanks,
Adam


--
http://twitter.com/ghrd

Re: [PHP-DEV] Re: [RFC] Extended String Types For PDO

[Christopher Jones]

On 26/2/17 9:07 am, Marco Pivetta wrote:


Hi Adam

On Fri, Feb 24, 2017 at 2:28 PM, Adam Baratz  wrote:


Based on some pain points with my team and things I've heard from others,
I created an RFC to handle "national" character sets for emulated

prepared

statements:
https://wiki.php.net/rfc/extended-string-types-for-pdo

I had previously suggested this as a driver-specific change, but believe
it's worthwhile to make it generic since it affects multiple drivers:
https://externals.io/thread/400#email-12542

Please let me know what you think.

Thanks,
Adam


Any thoughts on this one?


DBAL maintainer here: before we introduce even more complexity into the PDO
stuff (which is already a maze), could a set of test cases be written, so
that stuff that is currently impossible to do without this RFC is
clearer/demonstrated?

I'm asking because we didn't get any bug reports about extended string
types for Doctrine DBAL, and adding new types just to workaround the
limitations of the usual suspects (remember that PDO for SQLServer is
experimental, if not totally unusable) is shotgun surgery, and just more
complexity to handle.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


I agree the spec could definitely do with some samples and detail.

At a start, what about defining 'N-prefix' so the reader doesn't have to trawl 
through references?!
And clarify whether the PR is for the generic solution or the earlier problem.

More importantly, what about allowing arbitrary quote delimiters?
https://livesql.oracle.com/apex/livesql/file/content_CIREYU9EA54EOKQ7LAMZKRF6P.html

Chris

--
http://twitter.com/ghrd


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate PEAR/PECL & Replace with composer/pickle

[Christopher Jones]

On 5/09/2016 8:13 PM, Derick Rethans wrote:

On Fri, 2 Sep 2016, Davey Shafik wrote:


I'd like to introduce a new RFC to deprecate pear/pecl (in 7.2, and
remove in 8.0), as well as add composer/pickle (optional in 7.2,
default in 7.3+) in their place.

https://wiki.php.net/rfc/deprecate-pear-include-composer

I highly recommend reading the twitter poll and accompanying thread at
https://twitter.com/dshafik/status/756337267547832320


I don't think that question is phrased correctly. It is asking about
PEAR, and *not* PECL.

I don't think we should deprecate *anything*, until pickle is deemed
stable, and all issues with it are resolved (if there are any). So
instead of suggesting to deprecate something, perhaps it would be a
better idea to add pickle first - and only *then* even begin to figure
out whether it's better than "pecl" for installing PHP extensions.

"At the same time, we'd like to include composer/pickle as optional
(under build flags –with-composer and –with-pickle) for 7.2, then
enabled by default in 7.3. "

I don't think we should bundle composer, and also don't think it should
be an optional install. If it's an add-on (action required to enable
pickle), people won't do it, and nobody tests it - and continues to use
"pecl", which allthough not ideal, does do the job excellently.


I believe that pickle solves the issues with regards to pecl, and have run
the idea passed Jordi and Pierre. Both are fine with this RFC. :)


What are these issues with the "pecl" installation tool? The RFC has no
mention of this.

One of them could be that it gets very few maintenance, and it's a
little bit of a pain to update. Anything new should at least solve that.
That also means there need to be at least 3+ people that know it well
enough to be able to update, maintain and roll out releases.


I understand that adding in composer/pickle is just setting us up for
having a future "Deprecate composer/pickle & Replace with foo/bar" RFC, so
I've proposed the voting reflect that some people will just want to
deprecate/remove pear/pecl and not replace them at all.


You can't really ship PHP without a way to install extensions though!
And it should work also work out of the box, without any other tricks or
steps to make it working. That means, not having to run "composer
install" in order to get a working "pickle" tool. A phar might be an
idea.

All in all, I think it is premature to want to remove something, without
fully understanding the replacement tool. So, the first step would be to
*add* something, and not call for the removal of things.


cheers,
Derick





I'm with Derick on this.

Chris

--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] orphan extensions cleanup

[Christopher Jones]

On 15/08/2016 6:17 PM, Kalle Sommer Nielsen wrote:

Hi Stas

2016-08-15 7:53 GMT+02:00 Stanislav Malyshev :

Hi!

I'd like to propose an RFC to deal with extensions that currently have
no maintainer:

https://wiki.php.net/rfc/umaintained_extensions





pdo_oci
I have heard that maybe Oracle was going to take over this one, but it
seems fairly inactive, maybe this thread can help reach out to them.


Yep.

I've added myself to EXTENSIONS as PDO_OCI maintainer; can you take it
out of the RFC?

Thank you!

Chris

--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Throw Error in Extensions

[Christopher Jones]

On 28/06/2016 1:17 AM, Aaron Piotrowski wrote:

Hello,

Voting has opened on the RFC to change most conditions in extensions that raise 
E_ERROR or E_RECOVERABLE_ERROR to throw an instance of Error instead.

RFC: https://wiki.php.net/rfc/throw_error_in_extensions 

PR: https://github.com/php/php-src/pull/1942 


Aaron Piotrowski



Hi Aaron,

I was someone who spent time on the RFC template to try and get better
quality and to capture more information about each RFC.  I think your
RFC needs a lot more content before going to the vote.

Chris

--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RE: compiling php 5.6.# fails with sun CC 12.3 sparc sol 10, no problem 5.5 or 5.3

[Christopher Jones]

Not sure if this helps, but perhaps something like this:

# gmake Makefile fragment to clean a file of its carriage returns.
# Carriage returns drive the Studio compiler crazy.
cleancr = $(GSED) -i -e 's/\r//g' $(1) ;

Chris

On 26/01/2016 3:05 AM, Ross, Christine wrote:

Hi

Thank you for getting back to me.  I installed 5.6.17 that I downloaded from 
php.net.  I had previously tried 5.6.10 with the same results.  I'm running 
v2.5 of bison and v0.13.5 of re2c.   When I was trying to debug this I 
installed re2c but it didn't help.   I could install a later version of bison 
but PHP compiled with GCC4 without issue and I think it checks for bison on 
that compile.Everything in this web application and the database is using 
Sun CC 12.3 so I hate to change it.

I realized I didn't reply to the list so I am sending this again and adding the 
email address for the list.

Thanks for your suggestions.


-Original Message-
From: Lior Kaplan [mailto:lio...@zend.com]
Sent: Monday, January 25, 2016 5:26 AM
To: Ross, Christine; internals@lists.php.net
Cc: christine.s.r...@gmail.com
Subject: Re: compiling php 5.6.# fails with sun CC 12.3 sparc sol 10, no 
problem 5.5 or 5.3

Please try the sources available from the website (e.g. 5.6.17), these are 
already have some files pre-generated.

Regradless, which versions of re2c/bison do you have on that system?

Kaplan


From: Ross, Christine 
Sent: Saturday, January 23, 2016 11:29 PM
To: internals@lists.php.net
Cc: christine.s.r...@gmail.com
Subject: [PHP-DEV] compiling php 5.6.# fails with sun CC 12.3 sparc sol 10, no 
problem 5.5 or 5.3

Hello.

It was suggested I email this to this address.  I hope someone can help. I had 
no problems compiling php 5.3.# and 5.5.# on Sparc solaris 10 with Sun CC 12.3, 
but 5.6.# fails with the error below. GCC works but my whole application and 
environment is built with Sun CC. This is where it fails. I even tried adding 
/usr/sfw to the paths but no change.  I have received responses from others 
with the same issue.
Any help would be appreciated.



Lots of white space character errors before it fails on line 70. I saw 
something about flex and re2c so I installed re2c, and it didn't help. I tried 
without opcache, no help.

"Zend/zend_language_scanner.l", line 66: warning: invalid white space character in directive "Zend/zend_language_scanner.l", line 67: 
warning: invalid white space character in directive "Zend/zend_language_scanner.l", line 68: warning: invalid white space character in directive 
"Zend/zend_language_scanner.l", line 69: warning: invalid white space character in directive "Zend/zend_language_scanner.l", line 70: 
warning: function prototype parameters must have types "Zend/zend_language_scanner.l", line 70: warning: old-style declaration or incorrect type for: 
SCNG "Zend/zend_language_scanner.l", line 70: cannot initialize function: SCNG "Zend/zend_language_scanner.l", line 70: undefined symbol: x

#!/bin/sh
#
# Configure PHP
#
PATH=/usr/bin:/usr/local/bin:/usr/ccs/bin:/opt/SUNWspro/bin:/usr/sbin:/usr/dt/bin;
 export PATH LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/local/ssl/lib; 
export LD_LIBRARY_PATH LD_RUN_PATH=/usr/local/ssl/lib:/usr/local/lib; export 
LD_RUN_PATH # env CC=cc CXX=CC \ ../configure \ 
--with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=mysqlnd \ --with-pear \ 
--with-libxml-dir=/usr \ --with-mysqli=mysqlnd \ --with-pdo-mysql=mysqlnd \ 
--enable-mbstring \ --with-curl \ --with-gd \ --with-jpeg-dir=/usr/lib \ 
--enable-soap \ --with-openssl=/usr/local/ssl \ --enable-zip \ 
--with-iconv=/opt/local \ --enable-opcache

#!/end
#



--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 7 RTM date

[Christopher Jones]

On 9/11/2015 6:15 am, Anatol Belski wrote:

Hi,

After doing the last evaluations in the RMs circle before going for 7.0.0
RTM preparations, we came to the conclusion that the current state does not
look reasonable to be packaged as the final release.

The RCs before RC6 was looking acceptable, which gave the reason to announce
the planned RTM date on Nov 12th as final. From the todays perspective, the
most of the issues discovered and fixed since RC6 are still minor by
themselves - 7 crashes (bug #70805 rather critical), and 3 functionality
regressions. However, given the amount and the combination of them
altogether, the state is in our opinion unsuitable for starting the life
cycle of the next major.

Thus, resuming the pre-release cycle seems in our opinion the right thing to
do ATM. Hence this writing to inform the community about the intention and
to gather the opinions. PHP 7 is still going down the home stretch and is
very close to the finish, the next RC can be well the last. Though we'd
better ensuring the quality as many times as needed before, instead of
casually disservicing the consumers.

Regards

Anatol



OCI8 still has a mem leak or two that our developer is looking at, so a delay 
would
be good.

Chris

--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-WEBMASTER] PhpStorm Open Source Licenses 2015/16

[Christopher Jones]

On 9/11/2015 7:01 am, Peter Cowburn wrote:

Hi folks,

It's that time of year again. If you are using our PhpStorm license, you've
probably been prompted about it expiring in December.  JetBrains have
kindly offered their open source license to us again, and as usual all
details are on the wiki*.

https://wiki.php.net/licenses/jetbrains/phpstorm

Cheers,

Peter

* As always, please do not pass on any information that is on that wiki
page.



Even without bias, I'm a bit uncomfortable seeing this on the mail list.
But with bias: don't forget NetBeans is free: https://netbeans.org/

--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Adding phpdbg_webhelper to .gitignore

[Christopher Jones]

On 19/08/2015 9:17 pm, Bob Weinand wrote:

Am 19.08.2015 um 01:46 schrieb Christopher Jones christopher.jo...@oracle.com:
On 12/08/2015 11:31 pm, Ferenc Kovacs wrote:


On Wed, Aug 12, 2015 at 1:55 PM, Christopher Jones christopher.jo...@oracle.com 
mailto:christopher.jo...@oracle.com wrote:


Bob,

Is the ext/phpdbg_webhelper sym link really needed ?  If so, can you add it 
to .gitignore.

Thank you,

Chris

--
http://twitter.com/ghrd

Bob had a suggested change which would make the *nix build process more 
flexible and would allow us to get rid of the symlinking:
http://www.serverphorums.com/read.php?7,1061039
not sure why was this never pushed though.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu



Bob: ping.

Chris

--
http://twitter.com/ghrd


As Ferenc wrote, 
https://github.com/php/php-src/compare/master...bwoebi:soft_ext_dir patch 
should solve these issues. Seems I have forgotten it...

I'll look again at it today and then eventually finally push it.

Bob



Thank you.

I saw the patch.

Chris

--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Adding phpdbg_webhelper to .gitignore

[Christopher Jones]

On 12/08/2015 11:31 pm, Ferenc Kovacs wrote:



On Wed, Aug 12, 2015 at 1:55 PM, Christopher Jones christopher.jo...@oracle.com 
mailto:christopher.jo...@oracle.com wrote:


Bob,

Is the ext/phpdbg_webhelper sym link really needed ?  If so, can you add it 
to .gitignore.

Thank you,

Chris

--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Bob had a suggested change which would make the *nix build process more 
flexible and would allow us to get rid of the symlinking:
http://www.serverphorums.com/read.php?7,1061039
not sure why was this never pushed though.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu



Bob: ping.

Chris

--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Adding phpdbg_webhelper to .gitignore

[Christopher Jones]

Bob,

Is the ext/phpdbg_webhelper sym link really needed ?  If so, can you add it to 
.gitignore.

Thank you,

Chris

--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Benchmark Results for PHP Master 2015-07-30

[Christopher Jones]

On 30/07/2015 11:12 pm, Niklas Keller wrote:

2015-07-30 14:42 GMT+02:00 Andone, Bogdan bogdan.and...@intel.com:


-Original Message-
From: Niklas Keller [mailto:m...@kelunik.com]
Sent: Thursday, July 30, 2015 1:47 PM
To: Pierre Joye
Cc: lp_benchmark_robot; PHP internals; l...@lists.01.org
Subject: Re: [PHP-DEV] Benchmark Results for PHP Master 2015-07-30

2015-07-30 11:57 GMT+02:00 Pierre Joye pierre@gmail.com:


Hi,

Does someone has a contact there?

It would be nicer to have these results combined with what we pushed
on qa.php.net as well.

Cheers,
Pierre



Thought about that as well, results per mail aren't that useful,
especially as they're badly formatted for me in GMail (no fixed font).
A graph visualizing those numbers would be nice.

Regards, Niklas


Hi Guys,

We are glad that our small ticking spam start to be observed :) !

We would like to offer valuable information to the community related to
performance trends of the PHP project on Intel platforms based on daily
builds
and we are open for suggestions for making these results relevant.

We chose to share our numbers as plain text mails for easily seeing the
summary
snapshots on discussion lists without the need of other clicks.
Everybody agrees that plain text is ugly and, yes, you need to have fixed
font in
place for having the table formatted correctly. Let’s discuss a better way
of doing;
integration with qa.php.net is possible if we find the right interface
for sharing
data in an automated way.

Normally l...@lists.01.org should be the official entry for feedbacks and
requests but,
unfortunately, it is not yet operational, so I will be your direct contact
as I am part
of the team which deploys this project.


Kind regards,
Bogdan



Hi Bogdan,

I think absolute numbers (instead of a %-change) would be better suited for
visualizing performance over time.

Regards, Niklas



I agree on using absolute numbers.  With percentages it is not
immediately obvious whether the change was good or bad.

Including the build options would be good.

Chris

--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Reordering PDO statement dtor sequence?

[Christopher Jones]

We are looking at reordering the PDO statement-free dtors to fix a
resource leak in PDO_OCI.  Let me know if this will affect other
drivers.

Chris


*** pdo_stmt.c.orig 2015-07-15 09:56:18.986187123 -0700
--- pdo_stmt.c  2015-07-15 09:57:22.292453715 -0700
***
*** 2300,2305 
--- 2300,2309 

  PDO_API void php_pdo_free_statement(pdo_stmt_t *stmt)
  {
+
+ if (stmt-methods  stmt-methods-dtor) {
+ stmt-methods-dtor(stmt);
+ }
if (stmt-bound_params) {
zend_hash_destroy(stmt-bound_params);
FREE_HASHTABLE(stmt-bound_params);
***
*** 2316,2324 
stmt-bound_columns = NULL;
}

-   if (stmt-methods  stmt-methods-dtor) {
-   stmt-methods-dtor(stmt);
-   }
if (stmt-query_string) {
efree(stmt-query_string);
}
--- 2320,2325 

--
http://twitter.com/ghrd

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PDO Oracle driver

[christopher jones]

On 4/22/15 6:39 AM, Stelian Mocanita wrote:


The removal of pdo_oci had been suggested as part of the Removal of dead or not yet 
PHP7 ported SAPIs and extensions RFC, but there has been
feedback from Christopher Jones, that the extension will be supported by 
Oracle.[1] [1] 
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extpdo_oci_and_extoci8





Thanks for the info. Having Oracle supporting the extensions would be great, 
but I still feel like they should be re-released or something when
they are done. While the OCI8 ext works with current versions, pdo_oci has been 
experimental for a long time and never reached maturity.

Maybe Christopher Jones can jump in here and shed some light on the matter.

Regards, Stelian

On Wed, Apr 22, 2015 at 1:13 PM, Christoph Becker cmbecke...@gmx.de wrote:


Stelian Mocanita wrote:


I would like to ask what on your thoughts on removing the Oracle drive

for

PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php

)

at least since it's been experimental for a long time now, and it has

long

standing open bugs, such as:

https://bugs.php.net/bug.php?id=37706 https://bugs.php.net/bug.php?id=46728 
https://bugs.php.net/bug.php?id=60994

I know that the extension is marked as experimental already but based on the 
current status, it's not even that and a significant amount of
basic functionality is broken.


The removal of pdo_oci had been suggested as part of the Removal of dead or not yet 
PHP7 ported SAPIs and extensions RFC, but there has been
feedback from Christopher Jones, that the extension will be supported by 
Oracle.[1]

[1]  
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extpdo_oci_and_extoci8




-- Christoph M. Becker






The current state is that we will be looking at PDO_OCI and OCI8 for
PHP 7 in a short while.  Our good intentions got delayed as we have
been working on drivers for other languages
(https://github.com/oracle/node-oracledb and
https://bitbucket.org/anthony_tuininga/cx_oracle/).

I think the 'experimental' tag is unwarranted.  It has some bugs -
probably fewer than the rest of PHP, but is usable.

Yes, we do recommend using OCI8 over PDO_OCI.  This is partly due to
some inherent design and performance weaknesses of the overall PDO
architecture.

So, lets not mark PDO_OCI as dead just yet.

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: PDO Oracle driver

[christopher jones]

On 4/22/15 9:10 AM, Jonah H. Harris wrote:

On Wed, Apr 22, 2015 at 9:39 AM, Stelian Mocanita stelian.mocan...@gmail.com 
mailto:stelian.mocan...@gmail.com wrote:


 The removal of pdo_oci had been suggested as part of the Removal of
 dead or not yet PHP7 ported SAPIs and extensions RFC, but there has
 been feedback from Christopher Jones, that the extension will be
 supported by Oracle.[1]
 [1]
 

https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts#extpdo_oci_and_extoci8
 


Thanks for the info. Having Oracle supporting the extensions would be
great,
but I still feel like they should be re-released or something when they are
done.
While the OCI8 ext works with current versions, pdo_oci has been
experimental
for a long time and never reached maturity.

Maybe Christopher Jones can jump in here and shed some light on the matter.


I'd prefer to keep it in the tree. Let me talk to the people I know at Oracle 
and see. If they won't maintain it, my company will.

--
Jonah H. Harris
Blog: http://www.oracle-internals.com/


Hi Jonah,

Patches are most welcome.

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] PDO Oracle driver

[christopher jones]

On 4/22/15 2:40 AM, Stelian Mocanita wrote:

Hello internals,

I would like to ask what on your thoughts on removing the Oracle drive for
PDO from the documentation (http://us1.php.net/manual/en/ref.pdo-oci.php)
at least since it's been experimental for a long time now, and it has long
standing open bugs, such as:

https://bugs.php.net/bug.php?id=37706
https://bugs.php.net/bug.php?id=46728
https://bugs.php.net/bug.php?id=60994

I know that the extension is marked as experimental already but based on
the current status, it's not even that and a significant amount of basic
functionality is broken.

Regards,
Stelian




For the record, only one of those bugs is open.  The other may already have 
been fixed.  But I get your point.

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] Fixing bundled extension version mess

[christopher jones]

On 4/14/15 9:58 PM, Pierre Joye wrote:

On Wed, Apr 15, 2015 at 10:51 AM, christopher jones
christopher.jo...@oracle.com wrote:



On 4/14/15 7:21 PM, Pierre Joye wrote:


hi,

We tried that many times but we fail to handle the version of bundled
extensions.

Along with some installer work and other integration (projects
dependencies management, composer or other), we need to find a way to
get rid of this problem.

What do you think to simply use the PHP version number instead of some
outdated (most of the time) version for all bundled extensions?

For extensions being available both bundled or externally, the
external versions will provide a sane version number when installed
(like timezone db or other).

Doing so will make requirements management much easier by adding a
list of core extensions per PHP version.

Thoughts?

Cheers,



What do you mean external version?


Too many versions :) installed not using the core sources but
github, pecl, whatever.


I don't have a problem with extensions having different versions
depending how they are installed.


Cheers,
Pierre



What I really meant to ask was about your proposed numbering scheme
(or #ifdefs or whatever) for versioning of external packages. (I read
external version as version of the external package).  Subsequent
emails in the thread answered this.

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] Fixing bundled extension version mess

[christopher jones]

On 4/14/15 7:21 PM, Pierre Joye wrote:

hi,

We tried that many times but we fail to handle the version of bundled
extensions.

Along with some installer work and other integration (projects
dependencies management, composer or other), we need to find a way to
get rid of this problem.

What do you think to simply use the PHP version number instead of some
outdated (most of the time) version for all bundled extensions?

For extensions being available both bundled or externally, the
external versions will provide a sane version number when installed
(like timezone db or other).

Doing so will make requirements management much easier by adding a
list of core extensions per PHP version.

Thoughts?

Cheers,



What do you mean external version?

I don't have a problem with extensions having different versions
depending how they are installed.

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] Consistent function names

[christopher jones]

On 3/4/15 9:03 AM, Rowan Collins wrote:

On Wed, Mar 4, 2015 at 10:24 AM Rasmus Lerdorf ras...@lerdorf.com wrote:

Yasuo, please stop. This isn't going to happen. Changing strlen() to str_len() 
is just ridiculous. -Rasmus


Trevor Suarez wrote on 04/03/2015 15:33:

... well that's a constructive way of going about it. I don't think Yasuo
did anything harmful or rude in making his proposal. Regardless of how
realistic the idea may be, I don't think its ever appropriate or
constructive to tell someone to simply stop because something is just
ridiculous.


It's a bit of a crotchety answer, yes, but at this stage pretty much everything 
has already been said (a) in this thread, and (b) in similar threads
every few months going back as long as I've been subscribed to the list, and 
undoubtedly for a long time before that.

If Rasmus has seen this conversation several times a year for the last 20 
years, with the same conclusions every time, I don't blame him for being a
bit tired of it.

There have been some alternatives suggested - come up with a change with a 
compelling advantage rather than tweaking the names - so if you're looking
for something constructive, help move those ideas forward, rather than flogging 
the dead horse.

Regards,


See #6 at https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process

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] [BugFest] Feature request #38685: str_[i]replace(): Add support for (string needle, array replace)

[christopher jones]

On 1/10/15 9:03 AM, François Laupretre wrote:


To summarize, I started with a rather simple feature request and was
then pushed by external wishes.


See #13 at
https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process
Take advice on board but make sure your feature doesn't end up being designed by a 
committee.


--
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 - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

[christopher jones]

On 10/16/14, 8:47 AM, Rasmus Lerdorf wrote:

On 10/16/2014 04:27 AM, Ferenc Kovacs wrote:

On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara ircmax...@gmail.com
wrote:


Hello all,

I raised this topic on list over a year ago (
http://marc.info/?l=php-internalsm=130417646507744w=2 ). It was
determined that it wasn't time yet to disable prepared statement
emulation for MySQL yet. However, Rasmus did mention that it was a
possibility for 5.4 (
http://marc.info/?l=php-internalsm=130418875017027w=2 ). Since that
ship has sailed, I submitted a pull request for trunk to change the
default value of prepared statement emulation for MySQL.

https://github.com/php/php-src/pull/108

https://bugs.php.net/bug.php?id=54638

Does this need to be an RFC (should I draft one)? Or can it just be
pulled as-is?

Thanks,

Anthony

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



hi,

do we want to change the default for this in PHP7?


Honestly, I am not sure about this anymore. There is a significant
performance benefit in doing client-side prepares. Last year I attempted
to switch to server-side prepares on Etsy's production servers but it
added 30-40ms of page latency because of the extra round trips. And yes,
we were doing too many queries, but I fear if we change this default
people won't understand where this slowdown is coming from.

Of course, in some rare cases using server-side prepares might speed
things up because of prepared statement caching in the server, but I
have yet to see a case where that caching outweighs the extra tcp
roundtrip overhead.

I do agree that the default should probably be server-side since it is
the least surprising. We just need to make it very very clear in the
upgrade doc that this change will likely slow down peoples' apps and
show them how to turn client-side prepares back on.

-Rasmus



The MySQL team has been improving their server-side prepare code:
http://mysqlserverteam.com/re-factoring-some-internals-of-prepared-statements-in-5-7/

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: When, When, When???

[christopher jones]

On 9/16/14, 9:11 AM, Jorge F. Hernandez wrote:

On 9/16/2014 11:14 AM, Anatol Belski wrote:




I made a build from the current revision
http://windows.php.net/downloads/snaps/ostc/master-f469dc74/ so anyone
curious can easy snuffle :) It contains all the currently ported exts +
debug symbols, no PGO. Please catch up later with windows.php.net when the
build bot issue is fixed.

Cheers

Anatol



It loads when I change LoadModule to php5_module,


That would be because a PR to change references from php5 to php7 hasn't yet 
been completed or merged: https://github.com/php/php-src/pull/805

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
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 HEAD and gcov.php.net

[Christopher Jones]

Fine for OCI8 and PDO_OCI. I'll let you know when to re-enable.

On Aug 31, 2014 7:43 AM, Nuno Lopes nlop...@php.net wrote:

 Hi, 

 I've disabled the following extensions from the build of PHP_HEAD at the 
 gcov.php.net server: 
 - oci8 
 - pdo_oci 
 - sybase_ct 
 - litespeed SAPI 

 These extensions don't seem to have been upgraded to the new APIs. 
 Therefore I've disabled them so that we can test the other (majority) 
 extensions.  Please ping me when these extensions build and I'll reenable 
 them. 

 Nuno 

Re: [PHP-DEV] [RFC] Better type names for int64 RFC

[christopher jones]

On 8/22/14, 5:11 AM, Pierre Joye wrote:

On Fri, Aug 22, 2014 at 1:28 PM, Bob Weinand bobw...@hotmail.com wrote:


Yes, please. We're all in favor of the 64 bit implementation, but definitely 
not on
the naming. I think it was a big mistake to not separate the naming and
implementation votes initially.

I also would support a shorter RFC cycle, due to its blocking nature.
[Vote in 2-3 days, vote lasting one week as usual]


No.



Since this is obviously contentious it should follow the normal RFC cycle.

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
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] 64-bit integers and 64-bit string length patch is ready to be merged

[christopher jones]

On 8/21/14, 10:23 AM, Dmitry Stogov wrote:

Hi,

Thanks to Anatol and Pierre the 64-bit patch is ready
https://github.com/weltling/php-src

I made quick code review and don't see any technical problems now.

The performance and memory consumption difference is negligible. see
https://docs.google.com/spreadsheets/d/1PD4oiiXz6B0JbeZYnUSat5fHoq3_jAiCeI2cGHJ3UtQ/edit#gid=0

The patch breaks one test on 32-bit Linux:
ext/date/tests/bug53437_var3.phpt (seems to be a bogus test and wrong
behavior in php5.6 and below) and one test on 64-bit Linux:
ext/standard/tests/array/array_pad_variation2.phpt (has to be analyzed)

The only thing that I don't like is a massive renaming described here
https://wiki.php.net/rfc/size_t_and_int64_next#semantical_macro_renamings

IS_LONG - IS_INT
Z_LVAL - L_IVAL
etc

On one hand using INT may be more consistent, on the other hand it's going
to break habits and make addition headache for merging from php-5 (I know,
phpng already made problems)

I'm not sure how to proceed. If I'm alone, lets go ahead with new names. If
some others prefer old names we will probably need voting.

Despite of renaming, I would like to see this patch in master ASAP.

Thanks. Dmitry.



We have the code ready to go.  The change was voted OK.  I say merge it.

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
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] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)

[christopher jones]

On 8/21/14, 11:09 AM, Levi Morrison wrote:

Every time we break BC — in either of the ways Derick said — we narrow
the subset of PHP 5 and PHP 7 that's available to people writing PHP
code that has to work on both. If we narrow it too far, it'll be too
unexpressive, or too hard to use, or just plain won't do something
that they'll need, and PHP 7 will risk becoming this decade's Perl 6:
the cautionary tale for what happens when you burn all the boats.


I agree with this idea principle.

I disagree that these RFCs are breaking so much backwards
compatibility to create the next Perl 6.



Cumulatively they could easily break BC in the way Derick mentioned.
BC issues will mount up unless a higher level overview is considered
about the release.

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
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 new MIME types for the CLI web server

[Christopher Jones]

On 10/31/13 4:12 PM, Stas Malyshev wrote:

Hi!


Final comments anyone, before I commit next week?


It looks strange that we have to hardcode so many mimetypes in the code,
and doesn't sound a scalable solution. Can't we make it use data from
fileinfo or some other customizeable table so we don't have to keep all
MIME types hardcoded in the code? Maybe some ability to use Apache's
mime.types file?



It isn't scalable, but users can always use a router script to add
additional types so there isn't a real world problem in missing
uncommon extensions.

My idea was to add common extensions to the existing look-up list.  A
quick and straight-forward solution to making the CLI web-server
handle the 80-20 rule.

If someone (ajf?) wants to work on a more comprehensive solution
instead, I have no objection.

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
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] Adding new MIME types for the CLI web server

[Christopher Jones]

I'm planning on adding some MIME type to the CLI web server.

For PHP 5.5.5 CLI web server I added the .pdf MIME type.  I was using
the webserver for a conference exhibition hall demo and needed to
present a PDF.

Some other multi-media types could be useful in future situations, and
in general.  I'm thinking of adding these to PHP 5.5.6  master:

   { avi,  video/x-msvideo },
   { flv,  video/x-flv },
   { swf,  application/x-shockwave-flash },
   { qt,   video/quicktime },
   { mov,  video/quicktime },
   { mp3,  audio/mpeg },
   { mp4,  video/mpeg },
   { mpg,  video/mpeg },
   { mpeg, video/mpeg },
   { wav,  audio/wav },

Notes:

- A router can be used to add to, or override, the MIME type lookups,
  see http://php.net/manual/en/features.commandline.webserver.php

- The web server code does a linear lookup through the MIME table,
  defaulting on failure to returning application/octet-stream.

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
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: PHP 5.6 Process

[Christopher Jones]

On 10/17/2013 10:19 PM, Ferenc Kovacs wrote:

On Thu, Oct 17, 2013 at 5:29 PM, Pierre Joye pierre@gmail.com wrote:


On Thu, Oct 17, 2013 at 7:56 AM, Michael Wallner m...@php.net wrote:

On 17 October 2013 16:29, Felipe Pena felipe...@gmail.com wrote:



+1 for Ferenc Kovacs. (is it a voting thread? :D)


+1 (let's make it a good ol' one :))


+1 for both


--
Pierre

@pierrejoye |  http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Hi,

thank you guys for the support, it means a lot!



+1.

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
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] Locale-independent double-to-string cast

[Christopher Jones]

On 10/02/2013 10:26 AM, Nikita Popov wrote:

Hi internals!

I'd like to change our double-to-string casting behavior to be
locale-independent and would appreciate some opinions as to whether you
consider this feasible.



So, my suggestion is to change the (string) cast to always use . as the
decimal separator, independent of locale. The patch for this is very
simple, just need to change a few occurrences of %.*G to %.*H.


I'd like to see float/double casts recognize the locale's decimal
separator.  It's perfectly fine in Oracle DB for numbers to be
inserted/fetched with , (or any other character) as the decimal
separator:

  ?php

$c = oci_connect('hr', 'welcome', 'localhost/XE');
$s = oci_parse($c, alter session set nls_territory = germany);
oci_execute($s);
$s = oci_parse($c, select 123.567 as num from dual);
oci_execute($s);
$r = oci_fetch_array($s, OCI_ASSOC);
$n1 = $r['NUM'];   // value as fetched
var_dump($n1);
setlocale(LC_ALL, 'de_DE');  // this has no effect on casting to float
$n2 = (float)$n1;  // now cast it to a number
var_dump($n2);
  ?

The output is:

string(7) 123,567
float(123)   // Ideally this would be 123,567

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
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] Gnu/Hurd support

[Christopher Jones]

On 9/26/13 7:22 AM, Lior Kaplan wrote:

Hi,

In Debian we build PHP for GNU/Hurd system, which need some minor fixes
available here:

http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/patches/116-posixness_fix.patch

(per the guidelines here:
http://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_MAX_PATH_tt_MAXPATHL
)

There's another few bits here for the opcache extension in 5.5:
http://anonscm.debian.org/gitweb/?p=pkg-php/php.git;a=blob;f=debian/patches/Zend_OpCache_GNUHurd_fix.patch;hb=HEAD

Kaplan



Can you create a PR on github for them?

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
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: Function autoloading

[Christopher Jones]

On 9/5/13 3:32 AM, Pierre Joye wrote:

On Thu, Sep 5, 2013 at 11:34 AM, Nikita Popov nikita@gmail.com wrote:

On Thu, Sep 5, 2013 at 10:51 AM, Pierre Joye pierre@gmail.com wrote:


On Thu, Sep 5, 2013 at 10:23 AM, Sebastian Krebs krebs@gmail.com
wrote:


That being said, there is always a point in a RFC discussion where
there is nothing left to discuss or argue about, we are so far with
this one.



We've been at this point for a while; no new arguments have been raised
despite several people asking to bring it back in focus.


I totally understand your view on how such discussions go. However it
was (for what I read) about technical issues and the tones were
correct, could have been more diplomatic but that's fine imho. I am
not sure how to solve this problem as we have to discuss things deeply
and be sure that active core developers actually understand all the
impact of a given proposal will have, that's a must.



I don't think this discussion was about technical issues. Let me summarize
the main discussion points:

  * This will make function calls slower!. Many complaints about this
change hurting performance, even though it was pointed out early on (and
detailed in the RFC) that this is not true.
  * Will you put every function in it's own file?!. This has been repeated
*a lot* in this thread, even though again it has been pointed out early that
there are more reasonable autoloading schemes for functions (e.g.
namespace-to-file)
  * Just use static methods instead. I don't need to comment on the
absurdity of this statement.
  * Which function is autoloaded? Is the namespaced version or the global
fallback loaded?

Of these, only the last point has been of any benefit to this discussion.
There has also been some minor discussion regarding the API, which is also
relevant. But why does 80% of this thread deal with performance (known
incorrect assumption), unreasonable suggestions of function-to-file mappings
(even though alternatives are known) and suggestions to just not use
functions? It's really hard to fish out the 10 relevant mails in a
discussion spanning 70 in total.


Right, it goes circular way too often. I see that in many other MLs. I
however do not see it as a reason to leave, no matter how much it
happens. I also see these questions, discussions or arguing session as
technical matters, be semantic, common sense or anything else. It is
all about being sure about what php will be after a given feature is
added.


I'm pretty sure that Anthony's reaction is not directly related to this
particular thread - rather it is an accumulation of the very same kind of
discussion we have on nearly every RFC. Discussion is always very circular,
covering issues that have already been addressed (usually even written down
in the RFCs). Typically this kind of pointless discussion happens between
just three or so people and fills the largest part of the thread. Stas is
usually one of those three people, though of course I will not imply
causation from correlation.


I very much respect Stas, both for his constructive attitude and the
insane amount of work he puts in PHP and the related projects. As
anyone else, he is however a human, with needs to understand a
specific point very clearly. I do not think there any evil or
domination behavior here. About the N people trying to control
everything, that's why we have RFCs. Maybe we should scan discussions
more frequently and stop them when it goes circular, ask to update the
RFC accordingly and move forward. This is something I tried to do.
Sadly I was busy with other stuff in the last couple of months and was
not able to follow each recent RFC discussions closely.

Cheers,



I agree with Pierre on all his points in this mail.

(Note I haven't done more than skim the fuss around the post I wish I
didn't have to read so I won't comment further, nor wish my thoughts
to be extrapolated in any related direction).

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
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: PHP 5.5.2 RC1 is tagged

[Christopher Jones]

On 8/5/13 8:12 AM, Jan Ehrhardt wrote:

Julien Pauli in php.internals (Fri, 2 Aug 2013 10:05:00 +0200):

Please test the release carefully and report any bugs.


What is the best way to report things that are so small that opening an
issue would be overkill?

I have got some tiny remarks:
- Typo in NEWS: OPcahce should be OPcache
- Remove the reference to php_zip.dll in both php.ini-*'s
- Add 'case 90' in ext/gd/libgd/gd_jpeg.c to avoid unknown for jpeg
   lib 9

Compiled all 4 variants with VC11 flawlessly.

Jan



Submit pull requests with patches, then nag until someone applies them.
Then nag to get karma to make changes yourself.

The OPCache typo is already fixed, I believe.
http://git.php.net/?p=php-src.git;a=blob;f=NEWS;h=c01b43ed7bcda9d3c846df439cf32ead01c098d6;hb=refs/heads/PHP-5.5

The gd change might qualify for a bug report, so any background can be
discussed.

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
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] --enable-debug and GCC 4.8 / -Og

[Christopher Jones]

On 07/07/2013 07:55 AM, Sebastian Bergmann wrote:

On 07/07/2013 04:31 PM, Sebastian Bergmann wrote:

Currently --enable-debug sets -O0. I think it would make sense to
use -Og instead when GCC = 4.8.0 is used.


  https://gist.github.com/sebastianbergmann/5943708 is an attempt to
  implement this. Only tested this on Fedora 19.



Seems reasonable.

Your test logic needs fixing.  It should be like: if ((major  4) || (major == 4  
minor = 8))

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
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] String Size Refactor Progress

[Christopher Jones]

On 07/03/2013 07:12 AM, Anthony Ferrara wrote:


Then, I defined a series of new types:

#ifdef ZEND_USE_LEGACY_STRING_TYPES



Due to a problem with zend_parse_parameters, I added two new identifiers: S
and P. They act just like s and p, except that they return zend_str_size
instead of int.

When `--enable-zstrlen` is not enabled, I disable s and p, and changed ZPP
to rase an E_ERROR on unknown parameter types. The E_ERROR change is not
intended to go into production, but instead just makes life A LOT easier
refactoring modules one at a time.


Can you elaborate on the problem?  Ideally the return type of s  p would
be toggled by ZEND_USE_LEGACY_STRING_TYPES.

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
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] I want to work against Bug 44522 - Upload limit 2G

[Christopher Jones]

On 06/27/2013 09:33 AM, Ralf Lang wrote:


Anyway, I have built a version of the patch (using unsigned long instead
of signed long as the original did) against old php 5.3.8 and currently
a test is running with a 4.7 GiB DVD Image. If it works well, I will
submit the patch and attach it to the bug record.

Thank you for your response.



To make it more reviewable, can you base the patch on the master
branch (aka PHP 5.6)? If you're a github user, a PR would be great.

Some supporting documentation about what the patch changes, what
platforms it was tested on etc would be helpful.  I think a brief RFC
would be the best place to record the details: https://wiki.php.net/rfc/howto

Did you review all the previous mail list discussion about the patch?
IIRC there were a bunch of reasons it never got merged.

Chris

--
christopher.jo...@oracle.com  http://twitter.com/ghrd
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 and APC user cache upgrade path

[Christopher Jones]

On 05/09/2013 05:02 AM, Pierre Schmitz wrote:

Hi,

I am testing PHP 5.5 atm and how we can package it for Arch Linux and
provide an upgrade path for users. The RC1 looks pretty solid so far.

As the new opcache does not provide a user cache to store custom
variables, I would be glad if you could clarify what the best migration
from 5.4 would be.
* Is APC basically dead and wont support PHP 5.5?


From the lack of APC activity and from comments Rasmus has made in the
bugs (e.g. [1]) this is a safe assumption.


* Should APC users switch to opcache and APCu? (with APCu replacing the
APC package)


OPcache is definitely the opcode cache solution for PHP 5.5

For user data caches, there are a number of alternatives, as you
noted.  During this initial transition phase it isn't clear what the
directions of each solution will be.  It isn't clear that there will
be one dominant solution.  I'll leave it to Laruence and Joe to
state their cases for world domination of YAC and APCu, respectively.

Chris

[1] https://bugs.php.net/bug.php?id=64625



For PHP application developers:
* Regarding APCu: it provides the old PHP interface function as well as
their own apcu_* functions. They are aliases right now. Should
application developers think about switching to the apcu_-API as new
features will be available only here?

Bonus question:
* Right now very similar functionality is provided by APCu, XCache,
WinCache, YAC etc.. Are there plans to include such functionality inside
PHP in future to make application developers life a little easier? At
least a common API would be great. There were several bugs in
applications as these modules behave a little different regarding return
values etc..

Greetings,

Pierre



--
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.0beta1 ZTS broken build

[Christopher Jones]

On 03/25/2013 08:41 AM, Remi Collet wrote:

Le 25/03/2013 06:47, Laruence a écrit :

attached here:
https://bugs.php.net/patch-display.php?bug_id=64503patch=bison_build_2.patchrevision=latest


Tested under RHEL 6.4 (bison 2.4.1), Fedora 17 (bison 2.5) and Fedora 18
(bison 2.6.1). NTS and ZTS build OK.

Thanks,
Remi.





Bison 2.3 with Oracle Linux 5.9 (and therefore with RHEL 5.9) gives this error:
/home/cjones/php-5.5/Zend/zend_language_parser.y:50.1-5: invalid directive: 
`%code'
/home/cjones/php-5.5/Zend/zend_language_parser.y:50.7-14: syntax error, 
unexpected identifier

[You can get Oracle Linux (and keep up to date with patches and
security errata) from http://public-yum.oracle.com/]

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.5.0beta1 ZTS broken build

[Christopher Jones]

On 03/25/2013 01:59 PM, Rasmus Lerdorf wrote:

On 03/25/2013 01:43 PM, Christopher Jones wrote:


Bison 2.3 with Oracle Linux 5.9 (and therefore with RHEL 5.9) gives this
error:
/home/cjones/php-5.5/Zend/zend_language_parser.y:50.1-5: invalid
directive: `%code'
/home/cjones/php-5.5/Zend/zend_language_parser.y:50.7-14: syntax error,
unexpected identifier

[You can get Oracle Linux (and keep up to date with patches and
security errata) from http://public-yum.oracle.com/]


I'm ok dropping bison-2.3 support from 5.5. We ship a generated parser,
so this only affects people who need to re-generate the parser for some
reason and the people who need to do that are more than capable of
installing a more modern Bison.

-Rasmus



OK.

I also tested bison 2.7.  After locally patching Zend/acinclude.m4 to
allow 2.7, then the PHP 5.5 testsuite has only five fails, all in gd.

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] Optimizer+ bugreps

[Christopher Jones]

On 03/02/2013 09:42 AM, Christopher Jones wrote:



On 3/2/13 3:19 AM, Terry Ellison wrote:

On 02/03/13 09:34, Pierre Joye wrote:


Having it in peck right now allows that. But as of now it is not a PHP.net 
project so it makes little sense to have it listed there.

On Mar 2, 2013 10:33 AM, Terry Ellison te...@ellisons.org.uk 
mailto:te...@ellisons.org.uk wrote:

At what point is O+ reporting going to be possible through
https://bugs.php.net/ ?

I realize that this is a bit of a catch-22, but surely it would be
better to allow properly tracked open bug reporting sooner rather
later?



Thanks Pierre, I understand and that's why I mentioned catch-22. AFAIK, there's 
no open bug and issue reporting available prior to its formal
adoption, event though we all realize that it's going to be pretty much 
inevitable -- for compelling reasons -- and by the time it is adopted the
first release will be a fait accompli.



Bugs can (and have been) reported via 
https://github.com/zend-dev/ZendOptimizerPlus/issues
I'm sure email reports will also do fine in the interim.

Chris



Felipe added ZO+ to the bugs.php.net Package affected drop-down today.

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] Optimizer+ bugreps

[Christopher Jones]

On 3/2/13 3:19 AM, Terry Ellison wrote:

On 02/03/13 09:34, Pierre Joye wrote:


Having it in peck right now allows that. But as of now it is not a PHP.net 
project so it makes little sense to have it listed there.

On Mar 2, 2013 10:33 AM, Terry Ellison te...@ellisons.org.uk 
mailto:te...@ellisons.org.uk wrote:

At what point is O+ reporting going to be possible through
https://bugs.php.net/ ?

I realize that this is a bit of a catch-22, but surely it would be
better to allow properly tracked open bug reporting sooner rather
later?



Thanks Pierre, I understand and that's why I mentioned catch-22. AFAIK, there's 
no open bug and issue reporting available prior to its formal
adoption, event though we all realize that it's going to be pretty much 
inevitable -- for compelling reasons -- and by the time it is adopted the
first release will be a fait accompli.



Bugs can (and have been) reported via 
https://github.com/zend-dev/ZendOptimizerPlus/issues
I'm sure email reports will also do fine in the interim.

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] Current Status of O+ on Windows

[Christopher Jones]

On 03/01/2013 04:15 PM, Matt Ficken wrote:


I am testing O+ on Windows with php 5.3, 5.4, and 5.5.

I have uploaded my O+ test results here: 
http://windows.php.net/downloads/snaps/ostc/pftt/


Can you put your O+ php.ini settings up there as well?
Did you experiment with any options?
Putting the date of your O+ snapshot would also be handy.

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] new LDAP function: ldap_modify_batch

[Christopher Jones]

On 02/28/2013 05:54 AM, Ondřej Hošek wrote:

Hi,

yesterday, I submitted a patch to add a batch modification function to the
LDAP extension:

https://bugs.php.net/bug.php?id=64317

IMNSHO, this would be a very useful addition to PHP’s LDAP API (and I think
the submitter of bug 31209, among others, would agree with me), so I’d like
to ignite a discussion about it, collect feedback, and have it added to PHP
as soon as possible. ;-)


This should have an RFC sooner rather than later.  See https://wiki.php.net/rfc

Can you liaise with Etienne (CC'd)?  He is planning/hoping to merge some LDAP
changes too.

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] O+ - are we ready to go ahead and vote?

[Christopher Jones]

On 02/27/2013 03:06 AM, Zeev Suraski wrote:

Are there any additional clarifications and/or unanswered questions people
are still waiting for, or can we move ahead to vote on the O+ inclusion RFC?



Zeev



Are there any updated guesstimates at how long integration into PHP 5.5 will 
take?

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] O+ - are we ready to go ahead and vote?

[Christopher Jones]

On 02/27/2013 11:26 AM, Pierre Joye wrote:

On Wed, Feb 27, 2013 at 8:05 PM, Christopher Jones
christopher.jo...@oracle.com wrote:


Are there any updated guesstimates at how long integration into PHP 5.5 will
take?


There will be no integration, but the idea is to bundle it, as it is.
The actual integration is a large task and should/will target 5.6 and
later.

Or do you mean the testsfixes sessions to get it work out of the box?

Cheers,



The three voting options all use the word integrate. In a previous
email, Zeev clarified what it means: By integration I refer to
including something that is production quality, potentially
enabled-by-default (TBD), that everyone should feel comfortable
using.

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] Allow (...)-foo() expressions not only for `new`

[Christopher Jones]

On 02/25/2013 08:14 AM, Nikita Popov wrote:

Hi internals!

PHP 5.4 added support for expressions of the kind (new Foo)-bar(), (new
Foo)-bar and (new Foo)['bar'].

I'd like to extend this support to any expression instead of just new.

Why should be do this? Because it's just an arbitrary restriction. Removing
it would for example allow clone calls in the parens, so you could do
something like (clone $date)-modify('...'). Which - you may have already
noticed this - is more or less a replacement for the DateTimeImmutable
class that was added for 5.5 (with the nice benefit of being fully
compatible and not being an object oriented abomination :) That's just one
example, but I think there are a lot more (especially if you also consider
that it allows array dereferencing too). One further use that is of
interest to me personally is for https://github.com/nikic/scalar_objects,
so I can do calls like (foo)-bar().

A nice side benefit from this is that it removes a shift/reduce conflict
from the parser.

The patch for the change can be found here:
https://github.com/php/php-src/pull/291/files. It's a very simple patch, it
basically just changes one parser rule and adjusts the allowed opp types
for some opcodes. The rest is just the vm regeneration for the new op types.

I hope that this change is trivial enough to not require dragging it
through the whole RFC process. If there are no objections I'd commit it
sometime soon.


I think a brief RFC would be good to clarify and give some more examples of
what any expression is.  Seeing more examples would help people
evaluate the impact and see the use cases. It would also help the doc process.

(For me, it's changes like Sara's trailing comma proposal that are too
small to have needed an RFC)

Chris



Thoughts?
Nikita



--
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] Allow (...)-foo() expressions not only for `new`

[Christopher Jones]

On 02/25/2013 04:33 PM, Sara Golemon wrote:

When it comes to changing syntax, there is no such thing as too small
of an RFC IMO.  Runtime changes can occasionally be hand-waved, but
syntax changes are serious business.



Seeing this quoted makes me realize I expressed myself poorly.  What I
meant to convey was:

When it comes to syntax changes, there's no such thing as too small of
a change to need an RFC.

Which I think most parsed out correctly, but I want to be clear on
that position.  Bugfix or not, a parser change is a parser change.



It is actually great to see support for the RFC process.

Any new RFC page created in the wiki will get a bigger template than
previously provided. It looks like: https://wiki.php.net/rfc/template.
(Also see https://bugs.php.net/bug.php?id=64256 about updating the
template).  Whether it actually helps improve the quality of RFCs
remains to be seen.

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

[Christopher Jones]

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 

Re: [PHP-DEV] [VOTE] Improved Linux process title support in the CLI SAPI

[Christopher Jones]

On 02/22/2013 10:22 AM, Christopher Jones wrote:



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.


Doh!  buildconf is my friend.  Thanks Johannes.

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

[Christopher Jones]

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] PHP User Survey

[Christopher Jones]

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] [RFC] Short syntax for anonymous functions

[Christopher Jones]

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?

[Christopher Jones]

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 ?

[Christopher Jones]

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] Zend Optimizer+ Source Code now available

[Christopher Jones]

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

[Christopher Jones]

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] Zend Optimizer+ Source Code now available

[Christopher Jones]

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

[Christopher Jones]

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

[Christopher Jones]

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] clearing up who can propose RFCs

[Christopher Jones]

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] [RFC] Integrating Zend Optimizer+ into the PHP distribution

[Christopher Jones]

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] [RFC] Integrating Zend Optimizer+ into the PHP distribution

[Christopher Jones]

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

[Christopher Jones]

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] cc: acomp failed for /usr/local/build/php-5.4.11_SunOS5.10_sparcv9.001/ext/curl/interface.c

[Christopher Jones]

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] Re: [RFC][vote] 5.3 EOL

[Christopher Jones]

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] [VOTE] Property Accessors for 5.5

[Christopher Jones]

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

[Christopher Jones]

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

[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

[Christopher Jones]

[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: A problem related to php 5.4.10 and possibly others

[Christopher Jones]

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

[Christopher Jones]

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

Re: [PHP-DEV] strtr vs. str_replace runtime

[Christopher Jones]

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

[Christopher Jones]

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] PHP-5.5 unpack change broke pecl/pear

[Christopher Jones]

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

[Christopher Jones]

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] Adding Generator::throw()

[Christopher Jones]

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] Extension for str_replace / preg_replace with arrays

[Christopher Jones]

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

[Christopher Jones]

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] Extension for str_replace / preg_replace with arrays

[Christopher Jones]

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] Re: Poor date() performance (v 5.4.9) [PATCH]

[Christopher Jones]

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] RFC: ext/mysql deprecation

[Christopher Jones]

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] RFC: ext/mysql deprecation

[Christopher Jones]

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

[Christopher Jones]

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] [PATCH] sapi/apache2*: Use ap_state_query where possible instead of old method of creating a pool userdata entry.

[Christopher Jones]

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] Traits behavior still up in the air in 5.4

[Christopher Jones]

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] [RFC] Remove calls with incompatible Context

[Christopher Jones]

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] Release Frequency, NEWS, etc.

[Christopher Jones]

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