Re: [PHP-DEV] P++: FAQ

[Andi Gutmans]

I must admit that the first time I read Zeev’s email I got anxious... but it is 
frustrating that PHP has a WAY better runtime than Python and most other 
dynamic languages yet is falling out of fashion. It’s strange given how much 
better it actually runs (really being unbiased here). One reason is security 
perception (which is BS but perception matters) and the second is arguably some 
of the historic baggage which makes some folks feel PHP is hard to master 
without a manual (we have the best manual).

So many times I have thought “is it time to just take an axe and simplify it 
and do a cleanup?”. I actually don’t think we lack many features but rather 
lots of stuff I would dump like references, array(), global namespace for 
functions(?), type juggling in areas where we should be stricter, etc... I 
actually think that having a p++ is risky but it is an opportunity. I think 
it’s mostly be an opportunity if we’d be careful about feature bloat and try 
and be really aggressive about removing things and cleaning up. We potentially 
would get the significant benefits of our runtime but with a cleaner language. 
Will non-PHP appreciate it? maybe, maybe not... I actually do think there’s 
value of a different brand just because of the BS perception issues...

Andi

Get Outlook for iOS


From: Zeev Suraski 
Sent: Friday, August 9, 2019 12:54 PM
To: Internals
Subject: [PHP-DEV] P++: FAQ

During the discussion of the P++ proposal (
https://externals.io/message/106453), it became painfully clear that this
idea did little, so far, to bring peace to the galaxy.

However, based on a lot of the feedback, both on internals@ and elsewhere -
it seems that a lot of people simply didn't really understand what this
idea was actually proposing to do. I'll take the blame for that - by not
making the idea sufficiently clear.

I went on and create an FAQ, that attempts to address many of the questions
and common misconceptions that repeatedly came up.

It's available here: https://wiki.php.net/pplusplus/faq

Before you read it, I want to stress that this is an attempt to
provide *everyone
with a good deal, and nobody with a raw deal. *It doesn't mean it's
successful at that (although I think it is) - but the motivation is clean
and positive. If & when you read this FAQ, please try to read it without
any preconceived notions.

If there are additional questions that you think are missing, please let me
know - or better yet, if you're up for constructively adding them - go
ahead and do that.

Thanks,

Zeev

Re: [PHP-DEV] [RFC] JIT

[Andi Gutmans]

I think I heard some stat that over 50% of Azure now runs Linux (and I am sure 
PHP is primarily running on Linux). So given JIT probably helps 95% of 
production PHP installations I wouldn’t hold this back. If Windows ends up 
being important to folks some (and possibly msft) will contribute that.

I think we should explore the feasibility of moving some internal PHP functions 
to userland if performance is reasonable. Will help security.


Get Outlook for iOS


From: Andrey Hristov 
Sent: Friday, February 1, 2019 3:49 AM
To: Pierre Joye
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] JIT

Pierre,
On 1.02.19 г. 13:12 ч., Pierre Joye wrote:
> On Thu, Jan 31, 2019, 11:39 PM Dmitry Stogov 
>>
>>
>> I don't see any problems with including JIT without Windows support.
>> Windows runs PHP much slower any way.
>>
>
> How so? I tend to disagree here. Except if recent changes affect Windows
> indirectly (as in optimization done on linux only).
>
> Also while I use php on windows less, I still see a large amount of
> companies using php on windows, in similar ways than on Linux.
>
> Nikita concerns are valid, PHP is and should remain a cross platform
> language. And some top OSes besides linux should remain a target. Easier
> said than done and willing to help at least for windows. I am sure msft
> teams will step in as well.

considering how open is Microsoft to open source nowadays it is probably
a no brainer to have them help. They might only need some hinting :)

>>
>

Cheers,
Andrey


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

Re: [PHP-DEV] [VOTE] UUID

[Andi Gutmans]

If we say it is a ubiquitous need and Spl stands for "Standard PHP Library" and 
namespace is already taken then why not? Better than breaking BC on a global 
UUID...

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Marco Pivetta <ocram...@gmail.com>
Sent: Sunday, September 3, 2017 10:30:53 AM
To: Andi Gutmans
Cc: PHP Internals List; Zeev Suraski
Subject: Re: [PHP-DEV] [VOTE] UUID

Why would it go under Spl? Spl is already bloated with loads of unrelated 
classes with no real logical grouping.

On 3 Sep 2017 19:03, "Andi Gutmans" 
<andigutm...@gmail.com<mailto:andigutm...@gmail.com>> wrote:
Why would we not just add this under Spl? Feels like an appropriate place to 
put standard methods.
I would definitely not make functionality like this a top level class/namespace 
both for BC reasons and it is a minor capability that fits in well into a 
standard library context.

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Fleshgrinder <p...@fleshgrinder.com<mailto:p...@fleshgrinder.com>>
Sent: Saturday, September 2, 2017 3:43:09 AM
To: Zeev Suraski; internals@lists.php.net<mailto:internals@lists.php.net>
Subject: Re: [PHP-DEV] [VOTE] UUID

Hey Zeev :)

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> I just voted 'no', and I'd like to quickly explain why:
>
> 0. I agree with the premise of the RFC, that we should have something better 
> than uniqid() built into the language.
> 1. I think a renewed discussion, beyond the two days of discussion 3+ months 
> ago would be useful, as beyond that basic (yet important) point - I have 
> thoughts about a bunch of things in the RFC, and honestly didn't even notice 
> the brief discussion months ago (if there was another one then my apologies, 
> I couldn't find it).

The discussion was really ongoing for a long time, and actually very
heated as well. It was on GitHub with lots of comments, Internals,
Reddit, Twitter, ... everywhere.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 2. I think that a function that returns a string (a-la uuid_v4_create() 
> Nikita proposed) would make perfect sense.  Forcing the use of 
> classes/objects in such a case - where there's little to no added value, is 
> wrong and uncommon (possibly unprecedented) in PHP.

DateTime? SPL? Intl?

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 3. The section dealing with backwards incompatible changes, states:
> "Both UUID and UUIDParseException are now globally defined classes, which 
> might collide with user defined classes of the same name in the global 
> namespace. However, the risk of the introduction of them is considered to be 
> very low, since the global namespace should not be used by PHP users."
> ... erroneously assumes that all code in PHP utilizes namespaces.  IMHO this 
> is a projection of a particular coding style onto the entire PHP userbase.  
> We haven't deprecated at any point the ability to place user classes in the 
> global namespace, we haven't even as much as said at any point we might be 
> considering it - and I don't think we should, either.   My gut feel, backed 
> by a quick Google search refutes the assumption that the risk of introducing 
> - at least the UUID class - is very low.  Not that I have a better suggestion 
> (other than not introducing a class at all) - but I think the text there 
> should be changed as it does not reflect reality.

The very same would be true for any function that is being introduced in
the global namespace. I had an RFC for namespaces prepared and ready for
vote; incl. a namespaced UUID implementation. However, the feedback on
it was so extremely negative and hostile that I decided to withdraw it.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 4.  If I voted yes, it would also mean I agree with a statement such as "One 
> could argue that it is faster (C implementation), which it probably is, but 
> this is a weak argument".  I disagree it's a weak argument - and I do think 
> that for basic building blocks of the language, performance absolutely 
> matters.  If we manage to get JIT out the door and the performance 
> differences become negligible - then I see a lot of value in moving some of 
> our core value to PHP - but not before then.

I would agree, but most people think differently. The wording is a
result of the discussions.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 5.  Given we seem to agree this is a basic building block of the language (as 
> it is in other languages), I do think it should be a 2/3 majority vote and 
> not a 50%+1 one.  Taking the "is this something we can easily change w/o 
> affecting BC" test, this clearly gets a 'no'.

Actually we can. Both classes are final and users cannot extend them.
The only thing we cannot do is rename the stuf

Re: [PHP-DEV] [VOTE] UUID

[Andi Gutmans]

Why would we not just add this under Spl? Feels like an appropriate place to 
put standard methods.
I would definitely not make functionality like this a top level class/namespace 
both for BC reasons and it is a minor capability that fits in well into a 
standard library context.

Get Outlook for iOS

From: Fleshgrinder 
Sent: Saturday, September 2, 2017 3:43:09 AM
To: Zeev Suraski; internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] UUID

Hey Zeev :)

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> I just voted 'no', and I'd like to quickly explain why:
>
> 0. I agree with the premise of the RFC, that we should have something better 
> than uniqid() built into the language.
> 1. I think a renewed discussion, beyond the two days of discussion 3+ months 
> ago would be useful, as beyond that basic (yet important) point - I have 
> thoughts about a bunch of things in the RFC, and honestly didn't even notice 
> the brief discussion months ago (if there was another one then my apologies, 
> I couldn't find it).

The discussion was really ongoing for a long time, and actually very
heated as well. It was on GitHub with lots of comments, Internals,
Reddit, Twitter, ... everywhere.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 2. I think that a function that returns a string (a-la uuid_v4_create() 
> Nikita proposed) would make perfect sense.  Forcing the use of 
> classes/objects in such a case - where there's little to no added value, is 
> wrong and uncommon (possibly unprecedented) in PHP.

DateTime? SPL? Intl?

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 3. The section dealing with backwards incompatible changes, states:
> "Both UUID and UUIDParseException are now globally defined classes, which 
> might collide with user defined classes of the same name in the global 
> namespace. However, the risk of the introduction of them is considered to be 
> very low, since the global namespace should not be used by PHP users."
> ... erroneously assumes that all code in PHP utilizes namespaces.  IMHO this 
> is a projection of a particular coding style onto the entire PHP userbase.  
> We haven't deprecated at any point the ability to place user classes in the 
> global namespace, we haven't even as much as said at any point we might be 
> considering it - and I don't think we should, either.   My gut feel, backed 
> by a quick Google search refutes the assumption that the risk of introducing 
> - at least the UUID class - is very low.  Not that I have a better suggestion 
> (other than not introducing a class at all) - but I think the text there 
> should be changed as it does not reflect reality.

The very same would be true for any function that is being introduced in
the global namespace. I had an RFC for namespaces prepared and ready for
vote; incl. a namespaced UUID implementation. However, the feedback on
it was so extremely negative and hostile that I decided to withdraw it.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 4.  If I voted yes, it would also mean I agree with a statement such as "One 
> could argue that it is faster (C implementation), which it probably is, but 
> this is a weak argument".  I disagree it's a weak argument - and I do think 
> that for basic building blocks of the language, performance absolutely 
> matters.  If we manage to get JIT out the door and the performance 
> differences become negligible - then I see a lot of value in moving some of 
> our core value to PHP - but not before then.

I would agree, but most people think differently. The wording is a
result of the discussions.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> 5.  Given we seem to agree this is a basic building block of the language (as 
> it is in other languages), I do think it should be a 2/3 majority vote and 
> not a 50%+1 one.  Taking the "is this something we can easily change w/o 
> affecting BC" test, this clearly gets a 'no'.

Actually we can. Both classes are final and users cannot extend them.
The only thing we cannot do is rename the stuff that's already in them.
This is one of the reasons why I kept the provided functionality to a
bare minimum.

On 9/2/2017 12:14 PM, Zeev Suraski wrote:
> To summarize - I'm strongly in favor of fixing this issue in PHP, but at the 
> same time against the proposed solution.  I'd vote in favor of something 
> along the lines of uuid_v4_create() in a heartbeat.
>

$bin = \UUID::v4()->toBinary();
$hex = \UUID::v4()->toHex();
$str = \UUID::v4()->toString();

You can already use it like you want, with greater possibilities and
freedom. Incl. auto-completion with your favorite editor to explore your
possibilities, and type-safety everywhere as an opt-in.

--
Richard "Fleshgrinder" Fussenegger

Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines -- "let's proceed to ideas"

[Andi Gutmans]

On 1/14/16, 7:47 AM, "stig.bak...@gmail.com on behalf of Stig Bakken" 
 wrote:



>I agree whole-heartedly with Zeev here!
>
>Anyone who has a clue about organizational psychology will tell you to
>focus on what you want more of, not on what you want to eliminate.  Heck,
>anyone who is a parent today should understand this intuitively.
>
>The main focus of a CoC should be positive, describing or even giving
>examples of respectful behavior, that way people are guided towards
>"wanted" behavior, instead of having to figure it out by process of
>elimination from a list of what NOT to do.  Granted, there is such a thing
>as common sense, but it's not always that common, so providing positive
>guidance is effective.
>
>Several people have suggested splitting the RFC into two: one for the CoC
>itself (which should be easier to rally around), and another for how
>to deal with problems.  I think this is a very rational approach, it allows
>us to learn from experience with the CoC as formulated before setting up
>any kind of tribunal or banning system which could backfire badly in
>various ways.
>

I agree with Stig and it mirrors what’s happening in psychology - less carrot 
and stick and more focused on positive reinforcement and expectations.
I also question whether the RFC process is supposed to even address such issues.
The RFC process exists to vote on product related issues (features, EOL, BC 
breakage, …). It feels weird to me to use it for such an initiative.

But going with Stig’s suggestion, I think it’d be nice to work on a 
consensus-based (not RFC-based) guideline of the kind of positive behaviors we 
expect from people on internals@.

Andi

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

[Andi Gutmans]

Is there an update on the OpenSSL front...?
Is this release of OpenSSL going to be binary compatible or just source
compatible?

[PHP-DEV] Re: PHP 7 ?! :)

[Andi Gutmans]

Never mind. It returned. Congratulations everyone!

Amazing accomplishment. The Web is going to speed up 2x!
Everyone here has made a huge impact.

Thanks to the RMs.
Thanks to Dmitry for leading such an amazing effort on the performance
front.

Andi

On Thu, Dec 3, 2015 at 12:28 PM, Andi Gutmans <a...@zend.com> wrote:

> What just happened? It was on php.net and now it's gone?
>

[PHP-DEV] PHP 7 ?! :)

[Andi Gutmans]

What just happened? It was on php.net and now it's gone?

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

[Andi Gutmans]

How’s it going? Are we golden?
When do you plan on posting tomorrow?

> On Dec 2, 2015, at 12:42 AM, Anatol Belski  wrote:
> 
> 
> 
>> -Original Message-
>> From: Sebastian Bergmann [mailto:sebast...@php.net]
>> Sent: Wednesday, December 2, 2015 9:01 AM
>> To: internals@lists.php.net
>> Subject: Re: [PHP-DEV] PHP 7.0.0 final RTM delay
>> 
>> Am 02.12.2015 um 08:34 schrieb Anatol Belski:
>>> A short note to this is that due to the OpenSSL release on December
>>> 3rd that makes full sense to be included with the Windows builds, the
>>> PHP 7.0.0 announcement will most likely appear later afternoon.
>> 
>> Do the Windows builds have to be available immediately when the  sources
> of
>> PHP 7.0.0 are released?
> Yes.
> 
> Regards
> 
> Anatol
> 
> 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


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

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

[Andi Gutmans]

> On Dec 2, 2015, at 9:51 PM, Sebastian Bergmann  wrote:
> 
> Please do not get me wrong: I appreciate what Microsoft in general
> and you, Anatol, as well as Pierre in particular have done for PHP.
> But no vendor -- neither Microsoft nor Red Hat nor whoever else
> rolls binary distributions of PHP -- should have the power to delay
> a release in my opinion.

Ditto. Never remember any such thing in PHP history. Binary builds should not 
be a blocker to releases. Not Windows/MSFT, Zend, Red Hat or anyone...

Andi

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

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

Re: [PHP-DEV] PHP 7 RTM date

[Andi Gutmans]

> On Nov 10, 2015, at 8:53 AM, David Zuelke  wrote:
> 
> Sure: http://phpversions.info/paas-hosting/
> 
> The default PHP version in the absence of any explicit declaration on Heroku 
> will remain 5.6.latest for a while, but if you have a composer.json with a 
> bunch of requirements for package "php" like ">=5.3.3", and not a single one 
> with an upper bound, then on the day we make PHP 7.0.0 available, your next 
> deploy will get PHP 7, because your composer.json says that's fine (unless 
> you also require extensions that are not PHP 7 ready; it all gets resolved 
> correctly).
> 
> Of course, I'll roll out a warning soon to remind users of this, but many 
> will miss it because they tend to never read what's on their screens, so the 
> more stable 7.0.0 is, the better!
> 
> You'd be surprised how many of our users have composer.json templates from 
> weirdo frameworks with "minimum-stability": "dev", and they don't even notice 
> that they're getting PHP 7 RCs because of that.

Of course I don’t have any influence in what Heroku does but I would recommend 
not to deploy 7.0.0 on release day.

Actually part of the value we provide our customers with Zend Server is to 
deliver hardened, tested versions which is why we tend to wait a bit before we 
deliver the latest and greatest versions. Our customers depend on us delivering 
a version they can absolutely count on.
We’ve had PHP releases in the past which have been lemons and thanks to our 
waiting policy we saved our customers major outages. I agree with Rasmus that a 
.0.0 release will have a higher risk of having issues once the masses test 
their applications with it. The reality is that many people don’t bother 
testing their apps with RCs and wait for a GA version is out.

So while I understand Heroku likes to be ahead of the curve my friendly 
recommendation would be not to make it available too quickly. Give it at least 
a couple of weeks to ensure nothing major blows up… 

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

Re: [PHP-DEV] PHP 7 RTM date

[Andi Gutmans]

> On Nov 8, 2015, at 5:35 PM, Rasmus Lerdorf  wrote:
> 
> On 11/08/2015 05:16 PM, Anatol Belski wrote:
>> Exactly, the relevant patches are going into RC7 which is then out on 12th
>> instead of GA. The next closest release slot were then Nov 26th, either for
>> GA or for RC8 (but better not try to predict). If it stands good, we might
>> have no reason to wait until the Mrs. Lovelace birthday party :)
> 
> We should try really hard to get it out on the 26th. Once we get into
> December people start to disappear. Nov.26 is American Thanksgiving
> though, but I don't think that should interfere.

I think thanksgiving is not a great time to releasing something so significant. 
Most folks in the US are on time off and you won’t get as much interest.

If we do need to postpone I’d aim for Nov 30th or Dec 1st then. My experience 
is that as long as you’re in the first two weeks of December you still get 
people. After the 14th you slow down….

I know we are open-source and release when it’s ready but I think for such a 
huge deal it is worth waiting three more working days. 

Btw, do we want to do something special on php.net ? Front 
page?  Not the sexiest site as-is so maybe gives us an excuse to spice up the 
front page?

Just my 2 cents.
Andi

Re: [PHP-DEV] Undefined variables undefined order

[Andi Gutmans]

 On May 11, 2015, at 9:05 PM, Sara Golemon poll...@php.net wrote:
 
 On Mon, May 11, 2015 at 5:12 PM, Matt Wilmas php_li...@realplain.com wrote:
 - Original Message -
 From: Stanislav Malyshev smalys...@gmail.com
 Sent: Monday, May 11, 2015
 
 argument. I'd like to propose making the order of evaluation defined
 by splitting this into separate statements:
 
 What is the purpose of this? I.e. why is it important that these notices
 would be produced in certain order?
 
 Logic, consistency, polish, etc. :-)
 Exactly this. :)
 
 It's just my CDO kicking in.  It's not necessary for the language to
 function. Heck, HHVM already matches PHP 5.1-7.0's out-of-order
 behavior, so fixing PHP only creates double work for me.  I just look
 at these error messages and twitch uncomfortably.

I don't think it is worth the change. I actually prefer to leave code path 
optimization up to gcc here vs. trying to tell it what to do. 

Andi

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

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

Re: [PHP-DEV] PDO Oracle driver

[Andi Gutmans]

 On Apr 22, 2015, at 10:50 PM, christopher jones 
 christopher.jo...@oracle.com wrote:
 
 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.

This is good news. And I agree we shouldn’t give up on PDO_OCI just yet 
especially if Oracle is willing to take a look at it.
I actually just met with a very large global brand a couple of weeks ago which 
was successfully using PDO_OCI.

Andi


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

Re: [PHP-DEV] Concern around growing complexity in engine - hash table specifically

[Andi Gutmans]

On Fri, Apr 3, 2015 at 11:57 AM, Anthony Ferrara ircmax...@gmail.com
wrote:

 All,

 I spent a little bit of time today trying to debug an issue with 7
 that Drupal 8 was facing, specifically regarding an array index not
 behaving correctly ($array[key] returned null, even though the key
 existed in the hash table).

 I noticed that the hash table implementation has gotten orders of
 magnitude more complex in recent times (since phpng was merged).

 Specifically, that ardata and arhash are now the same block of memory,
 and that we're now doing negative indexing into arData to get the hash
 map list. From Dmitry's commit message, it was done to keep the data
 that's accessed most often in the same CPU cache line. While I am sure
 that there are definitive performance gains to doing this, I do worry
 about the development and debugging costs of this added complexity.

 As well as the way it increases the busfactor of the project.

 There is definitely a tradeoff there, as the change is pretty well
 encapsulated behind macros. But that introduces a new level of
 abstraction. But deeper than that it really makes debugging with gdb a
 pain in the neck.

 Without hard data on this particular patch, I'm not suggesting we roll
 back the change or anything. I more just want to express concern with
 the trend lately to increase complexity significantly on developers
 for the sake of performance.

 While I'm definitely not saying performance doesn't matter, I also
 think performance at all costs is dangerous. And I wonder if some of
 the more fundamental (even if isolated) changes such as this should be
 way more documented and include the performance justification for
 them. I'm definitely not suggesting an RFC, but perhaps some level of
 discussion should be required for these sorts of changes...

 Thoughts?


I think it is generally true that increased performance often requires more
sophisticated approaches.
Generally speaking I've observed that the faster, more modern runtime
engines all need to deal with that additional sophistication.
JIT runtime engines typically are the worst because they deal with hundreds
of micro-optimizations around code generation (register allocation, cache
line optimization, etc...).
So what you have in PHP 7 today is actually not that bad compared to some
of the other runtimes (IMO).
I think it can be partially addressed in a combination of documenting key
datastructures (some of which was already written) and maybe some
additional comments in areas of code where the complexity level goes up for
some very specific tricks.

You can see by the level of interest in performance (whether ones opinion
is that this is fully warranted or not) around PHP 7, HHVM and other
languages, that this is an area we need to invest in on an ongoing basis.
And sophistication will likely go up.

Andi

Re: [PHP-DEV] 7.0 Release Management

[Andi Gutmans]

On Sun, Apr 5, 2015 at 12:05 AM, Ferenc Kovacs tyr...@php.net wrote:

 Hi,

 bumping the thread as we should start the release steps (branching out 7.0,
 tagging the first alpha or more likely beta) if we wanna keep up with
 https://wiki.php.net/rfc/php7timeline


I definitely think we should roll a package and get it posted to encourage
early testing and feedback.
I think we are also more likely to get folks to benchmark against their
apps and give us feedback on performance gains and migration challenges
which can help us with migration guidelines and tools.

In the past we've posted alpha versions at much earlier phases of
development.
Given that what we currently have in hand is quite good and somewhere in
between an alpha (very raw, incomplete) and a beta (mostly feature
complete, yet not sufficiently tested) I would opt for either calling it a
preview or a potentially even a beta which will get more eyeballs on it.
But I don't have a strong opinion besides getting the ball rolling and
helping folks get their hands on it.

We are posting nightly builds for Debian and Red Hat on php7.zend.com just
to make it easier for folks who don't want to self-compile to give it a go
but I think even better if we get some downloadable .tar.gz of the sources
on php.net and we can always also have some non-nightly builds of the
preview/betas we provide for folks who are interested.

Thx!
Andi

Re: [PHP-DEV] Proposal to delay 7.0 timeline

[Andi Gutmans]

 On Mar 21, 2015, at 9:05 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 
 On 03/21/2015 08:52 AM, François Laupretre wrote:
 Now, after more calls from many of you to delay it, and as Zeev himself
 seemed to consider it as more acceptable, I am proposing again to delay 7.0
 feature freeze to May, 15 (2 month delay, date where vote is starting). I
 won’t repeat all the arguments of my previous posts but, to summarize, it
 would allow to include important features, making it a ‘real’ major version.
 Releasing a major version is not just a question of BC break, we also need
 to think about what we put forward. So, we need features. We already have
 STH, but we can do more (I personally have at least 4 RFCs I didn’t have
 time for, including scalar pseudo-methods, which can be an important
 feature).
 
 No, please, let's get what we have stabilized and out the door. There
 are always more things to do and we can delay things indefinitely. And I
 completely disagree that this isn't a 'real' major version.
 
 -Rasmus
 

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

Re: [PHP-DEV] [RFC] Basic Scalar Types

[Andi Gutmans]

 On Mar 11, 2015, at 2:28 PM, Bob Weinand bobw...@hotmail.com wrote:
 
 Hi all,
 
 after all, some people are not happy with the current proposals about scalar 
 types. So, they both still possibly may fail.
 
 Thus, I'd like to come up with a fallback proposal in case both proposals 
 fail:
 
 https://wiki.php.net/rfc/basic_scalar_types
 
 It shouldn't prevent any future improvements and still give use all the 
 advantages of scalar types.

Agree and I would vote +1 on this even if I'd prefer coercive. 
It is a very valid option for a 7.0 and it is future proof. 

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

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

Re: [PHP-DEV] Re: Zend JIT Open Sourced

[Andi Gutmans]

 On Feb 27, 2015, at 7:12 AM, Anthony Ferrara ircmax...@gmail.com wrote:
 
 Dmitry and Zend,
 
 Thank you for sharing your code. I look forward to playing with it.
 
 Perhaps after 7 stabilizes (and ships) you could write up your
 thoughts around it? Why decisions were made and the findings that you
 have?

Yes I think we can definitely do that. It is an interesting experiment and 
clarified also that JIT was less interesting in the short term as we can all 
observe by the fabulous results of the current PHP 7 runtime. But absolutely 
worth discussing post 7 as there surely are interesting opportunities. 

Andi

 Thanks again
 
 Anthony
 
 On Fri, Feb 27, 2015 at 7:10 AM, Dmitry Stogov dmi...@zend.com wrote:
 Hi,
 
 With the recent discussions of JIT/AOT and the good progress we made on
 PHP-7, we decided to open up the JIT experiment we've been working on.
 
 https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit
 
 You may just clone or pull zend-jit branch and compile/configure according
 to instruction. Don't merge it with master. It may work today but will stop
 working tomrrow.
 
 Disclaimers:
 
 - It's an experiment, and is not in any way ready for anything.
 In the future we may try to implement JIT quite different from this PoC.
 
 - I'm not planning to invest into it in the near future. (PHP-7 takes all my
 time)
 Consider it available for academic purposes only at this point.
 
 Enjoy!
 
 Thanks. Dmitry.
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 

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

Re: [PHP-DEV] Zend JIT Open Sourced

[Andi Gutmans]

 On Feb 27, 2015, at 11:36 AM, Anthony Ferrara ircmax...@gmail.com wrote:
 
 Dmitry,
 
 That's not to say there's anything wrong with this approach, nor that
 there isn't a ton we can learn from it. I think it's a fantastic
 research effort and plan on digging through it myself. Thank you for
 open sourcing it.
 
 
 Thanks for good words :)
 
 This work may be adopted for some specific cases.
 25-30 times speedup on Mandelbrot allows usage for numeric calculation
 instead of C.
 
 https://gist.github.com/dstogov/12323ad13d3240aee8f1
 
 anyone may repeat the language battle :)
 
 These tests seem really odd. A 15% speed advantage over GCC -O2? Sure,
 it's possible. But I don't think it's likely. It really smells to me
 like bias in the testing methodology. (and the lack of an -O3 result
 is suspicious as well).
 
 And looking at the code, I can see why. The PHP version is writing to
 an internal buffer, while every other version has to write to STDOUT
 on every single iteration.
 
 So you are intentionally not benchmarking the output in the PHP
 version (you even explicitly call ob_start()) but are benchmarking it
 in every other version. So in fact, the PHP code does something
 different than the rest of the code.

We actually discussed this at the time of the results.
IIRC it really has nothing to do with the output mechanism, etc.. The benchmark 
does enough iterations and very little output that the impact there is 
negligible (you can test this yourself to see if I am right but I am pretty 
sure I am).
It is due to the fact that at runtime LLVM can optimize better to the 
architecture than a static standard gcc build. Constraining gcc with the right 
architecture dependent switches upfront will also improve the gcc results. 
Anyway, still pretty cool to see this although it has very little impact (if 
any) on real world apps ala Magent, WordPress, Drupal, ...

I think the important learning is that faster synthetic benchmarks have very 
little impact on overall application performance. Sure it can have an impact on 
specific algorithmic pieces of code but that’s the exception not the norm. No 
doubt there are other ways to write JIT including tracing JITs etc. but I do 
think we found that we are more bound by I/O and memory/caches than the quality 
of the machine code as the engine is already quite tight. And with apps 
consuming more and more Cloud services the I/O bottleneck issue looks grimmer 
than ever! :) That also comes across consistently in benchmarks of PHP 7 vs. 
hhvm on real-world apps - you see a JIT and non-JIT platform pretty much head 
to head on performance and actually on the complex stuff PHP 7 is often faster.

Anyway, definitely makes sense to continue to look at these kind of 
opportunities down the road but PHP 7 is such a huge step-up on real world 
application performance I think getting that out the door is the biggest 
possible short-term win when it comes to performance. Looking forward to seeing 
folks dig into the code and have ideas down the road!!

Andi


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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Andi Gutmans]

 On Feb 7, 2015, at 7:52 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 
 On 02/07/2015 09:51 PM, Andrea Faulds wrote:
 tan(1);
 echo strstr(test, est, 1);
 
 Banning int-float and float-int is both a pain point and sometimes a 
 life-saver. It’s annoying that tan(1) doesn’t work. On the other hand, you 
 discover if your ints floats would be silently truncated (as I did with 
 PictoSwap).
 
 I wouldn’t say that int-string not working is a problem, though. Seeing 
 something like strstr(“test”, “est”, 1); is rather confusing. Looking at it, 
 I’d think the third parameter is some sort of number for you to want to pass 
 an integer to it. If I want a string, I’ll use one.
 
 This isn't int-string. This is int-boolean. The 3rd arg to strstr() is
 a boolean and passing 1 instead of true makes it blow up. It is very
 very common for people to pass 0 or 1 in place of true/false to all
 sorts of things in PHP.


Thanks for those relevant examples.
I think it’s also worth emphasizing that in C people frequently work around 
this by forcing casts. The value of strict typing diminishes quickly and the 
code ends up being less readable.

I think in PHP this is going to be even more so due to the reasons Rasmus 
states. We have *a lot* of places like this which will lead to unnatural acts 
and code which is no more strict than it was before (just not as pretty).

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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Andi Gutmans]

 On Feb 6, 2015, at 12:42 PM, Stelian Mocanita steli...@php.net wrote:
 
 Sending people who want to have more structure in the language to Java
 is downright bad, not to mention that it psounds completely dictatorial. I 
 would just put that in the next Zend newsletter to make it clear for your 
 customers that there is a saner option.
 

Oh come on. I was kidding. I will remember for next time this list has no sense 
of humor. 

And just for the record this is not a zend thing. Four zenders voted based on 
their own beliefs - three votes were no and one was yes. So diversity here too 
plus a small minority of total voters who can't really move the needle much. 

Let's keep the conversation pragmatic. I will try and refrain from any humor. 

Andi

 Stelian
 
 On Fri, Feb 6, 2015 at 12:57 AM, Andi Gutmans a...@zend.com wrote:
 The folks who really want all this great strict typing should head over to
 Oracle.com and download free open-source Java? I hear it's got a lot of
 strict typing features in it. Only downside is that it'll take them 10x
 longer to complete their projects. OK sorry. Had to say that :) I realize
 it's not the same...
 
 Andrea, while I don't agree with what you say I accept it. *But* exactly
 for the reasons you state (the big divide) we should also have a weak type
 hinting option to vote for in parallel. If you feel morally unable to do
 that then I can copy your work and just have another RFC running in
 parallel but I think that would do a disservice to the good work you've
 done.
 
 Andi
 
 
 On Thu, Feb 5, 2015 at 3:47 PM, Andrea Faulds a...@ajf.me wrote:
 
  Hi Andi,
 
   On 5 Feb 2015, at 23:22, Andi Gutmans a...@zend.com wrote:
  
   I have to say I’m pretty disappointed at the opening of the vote.
   We had a pretty good RFC (thank you) for weak type hinting which was
  aligned with the spirit of PHP and everyone was able to rally around it.
 
  This is far from true. Some people on internals were happy, but only some,
  and everywhere outside internals I looked, the reception was far more
  negative.
 
   This has now been morphed into something very hard to swallow and IMO
  having such a declare(…) syntax will be ridiculed by the broader app dev
  community until the end of time…
 
  Nobody mocks Perl or JS for use strict.
 
   But even that syntax aside (it’s only syntax after all), I think we lost
  the ability to reach consensus on something so important to everyone which
  we haven’t been able to come to agreement on for over 10 years. Finally it
  was there, in reach and you made a 180 degree turn.
 
  “Consensus” is exaggerated. There was no consensus and to claim there was
  is to ignore the reality that the PHP community is divided over this issue.
  I’d love to say that everyone loves weak type hints and if that version had
  passed we’d all be dancing around happy holding hands, but the reception
  was not uniformly positive, not even close, and that’s just on internals.
 
   I think it’d be so much easier for us to implement weak type hinting.
  Have everyone rally around it. Be happy and then learn and see whether an
  additional mechanism is really necessary.
 
  Who’d be happy? I realise you and Zeev are big fans of weak types, as are
  many others, but there are also a lot of PHP developers who vehemently
  disagree with you.
 
   We could even add an E_STRICT_TYPES error_reporting flag to help folks
  “debug” their code if they so wish to see if there are any hotspots in
  their code they may want to take a look at - again not necessarily an error
  but maybe a debugging tool.
 
  Global error handlers affect all code the interpreter runs, which is why
  we’ve looked down on them in recent times.
 
   But net, net - why not just implement the thing everyone can agree on.
 
  Everyone doesn’t agree on it.
 
  If everyone did agree on it, v0.1 of the RFC would have been the one that
  went to vote.
 
   Have something really good in the spirit of the PHP Language for PHP 7
  and learn how people leverage that… The reality is that for the majority of
  the Web community “1” coming in from HTTP should be accepted as a 1. 
  Period.
 
  It’s very well and good you claiming that the “majority” agree, but this
  does not match my experiences. The PHP community is not a single,
  homogenous entity. It is very difficult to judge.
 
   I voted “no” but I will vote “yes” for the competing RFC which is 80% of
  your RFC. Why are we not given that option??
 
  Because I cannot in good conscience push through something in the name of
  “consensus” which does not even approach it.
 
  --
  Andrea Faulds
  http://ajf.me/
 
 
 
 
 
 

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Andi Gutmans]

+1

 On Feb 5, 2015, at 5:23 PM, Adam Harvey ahar...@php.net wrote:
 
 On 6 February 2015 at 04:14, Andrea Faulds a...@ajf.me wrote:
 At long last, I’m going to put the RFC to a vote. It’s been long enough - I 
 don’t think there needs to be, or will be, much further discussion.
 
 True, and I probably won't respond to any replies to this because we
 don't need more noise, but I do want to explain my -1 vote. This is
 long and rambling. I apologise. I've posted a formatted version of
 this at https://gist.github.com/LawnGnome/354ca07f1799ff88fc35 in case
 it's easier to read.
 
 In no particular order, my issues with this RFC:
 
 ## The declare switch
 
 Adding the cognitive overhead for each file for developers to have to
 remember whether they have to cast a value before passing it to a
 function or if PHP will automagically do that for them is a bad thing.
 Of course, in a small, well compartmentalised file, or a single
 developer code base, it wouldn't be a problem. Unfortunately, a lot of
 PHP projects aren't that tidy. (Probably most of them, in fact.)
 
 I also disagree with the comparisons that have been drawn on Internals
 between `declare(strict_types=1)`, `use strict`, and `from __future__
 import foo` statements. They're not the same thing at all:
 
 * `use strict` is ultimately about code quality — am I doing something dumb?
 * `from __future__ import foo` is ultimately about features — yes, I
 want to opt-in for the new shiny.
 * `declare(strict_types=1)` isn't either of those, although it might
 superficially appear so — what it's really about is I reject your
 philosophy and substitute my own in terms of typing.
 
 There are structural decisions we can and should let our users make. I
 believe this isn't one of them: allowing users to fundamentally change
 the typing semantics of a language on a module-by-module level is, in
 my opinion, insanity. Languages have to be opinionated about this sort
 of issue: if they weren't, there'd only be one programming language
 and it would have 800 switches to configure before you could write a
 line of code. This sort of decision is the whole point of designing a
 language: abdicating it by providing a switch is effectively us
 shrugging and saying sure, whatever, we don't care, so now we'll make
 you care.
 
 ## Strong typing
 
 This ties into the previous point: for scalars, PHP has never been a
 strongly typed language. I was once on the train of strict typing
 being universally better — if you know that you always have an
 integer, you never have to worry about a bad conversion, right? And,
 if I was designing a language from scratch, I'd probably still feel
 that way.
 
 That language wouldn't be PHP, though. PHP is unapologetically weakly
 typed from top to bottom. Designing a feature to break that would be
 bad enough. Designing a feature to optionally break that is insidious.
 If you care about whether the zval IS_STRING, you can check that
 today. Encouraging our users to care goes against the entire
 philosophy of the language.
 
 To be clear: yes, we have problems in our type conversion matrix. The
 fact that `21 Jump Street == 21` is an issue (particularly because
 it's silent), and we should be talking about that. But strong typing
 is not the solution.
 
 ## Caller versus callee
 
 Making the caller responsible for choosing the type behaviour is a
 clever hack. (No pun intended, Facebookers.) I find the idea
 intriguing from an academic perspective. Unfortunately, as with the
 above point, this isn't consistent with PHP as a language that's
 existed for 20 years and had type hinting in its current form for over
 10 years. If we accept this, then we only widen the gap between scalar
 values and array/object ones: for one set of type declarations, the
 behaviour is determined entirely by the callee, and for another, it's
 determined by both the callee (via the type hint) and the caller
 (whether it will be converted or not).
 
 ## So what do we do for 7.0?
 
 From where I sit, we had a good solution: it was the 0.1 version of
 this RFC. It behaved like PHP should behave, respected PHP's long
 standing scalar type handling and conversion rules, but most
 importantly, it solved the **actual** problem scalar type hints are
 supposed to solve in the simplest possible way:
 
Can I guarantee that my function that expects an integer will
 really get an integer?
 
 I don't think that adding complexity on top of that helps anyone in
 the long run. Yes, we get to tick some extra boxes — we support
 strong typing, we support weak typing, we put the user in control
 — but at the cost of having a language that not only supports, but
 advertises multiple, inconsistent behaviours, requires users to be
 aware of conversion minutiae that they shouldn't have to be mindful
 of, and doesn't do anything to solve the actual problem above.
 
 Adam
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Andi Gutmans]

I have to say I’m pretty disappointed at the opening of the vote. 
We had a pretty good RFC (thank you) for weak type hinting which was aligned 
with the spirit of PHP and everyone was able to rally around it.
This has now been morphed into something very hard to swallow and IMO having 
such a declare(…) syntax will be ridiculed by the broader app dev community 
until the end of time… But even that syntax aside (it’s only syntax after all), 
I think we lost the ability to reach consensus on something so important to 
everyone which we haven’t been able to come to agreement on for over 10 years. 
Finally it was there, in reach and you made a 180 degree turn.

I think it’d be so much easier for us to implement weak type hinting. Have 
everyone rally around it. Be happy and then learn and see whether an additional 
mechanism is really necessary. We could even add an E_STRICT_TYPES 
error_reporting flag to help folks “debug” their code if they so wish to see if 
there are any hotspots in their code they may want to take a look at - again 
not necessarily an error but maybe a debugging tool.

But net, net - why not just implement the thing everyone can agree on. Have 
something really good in the spirit of the PHP Language for PHP 7 and learn how 
people leverage that… The reality is that for the majority of the Web community 
“1” coming in from HTTP should be accepted as a 1. Period.

I voted “no” but I will vote “yes” for the competing RFC which is 80% of your 
RFC. Why are we not given that option??

Andi


 On Feb 5, 2015, at 12:14 PM, Andrea Faulds a...@ajf.me wrote:
 
 Good evening,
 
 At long last, I’m going to put the RFC to a vote. It’s been long enough - I 
 don’t think there needs to be, or will be, much further discussion.
 
 I’d like to make sure that everyone voting understands the RFC fully. Please 
 read the RFC in full: the details are important. And if  anyone has any 
 questions or uncertainties, please ask them before voting. I am very happy to 
 answer them.
 
 I would urge everyone who wants type hints to vote for this RFC. It is not a 
 perfect solution, but there can be no perfect solution to this issue. 
 However, I think it is better than most of the alternatives suggested thus 
 far - see the rationale section, and previous discussions. Crucially, this 
 RFC would keep PHP a weakly-typed language, and not force either strict 
 typing, nor weak typing, on anyone who does not want it. It would allow the 
 addition of type hints to existing codebases. It would not create a situation 
 where userland functions are strict yet internal functions are not, because 
 the strict mode affects both. I’ve tested the implementation myself on my own 
 code, and it worked well, providing benefits other proposals would not have 
 given (see my previous post about my experiences).
 
 Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In 
 addition to the vote on the main RFC, there is also a vote on the type 
 aliases issue, and a vote to reserve the type names for future RFCs’ sake if 
 this RFC fails.
 
 The RFC can be found here, and it contains a voting widget: 
 https://wiki.php.net/rfc/scalar_type_hints
 
 Thank you for your time.
 
 --
 Andrea Faulds
 http://ajf.me/
 
 
 
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Andi Gutmans]

I am not sure.

I think we need to explicitly vote on a weak type hinting option.
Andrea, I think this should be an option in any vote. Right now it feels
like the only option to people is the very challenging, non-consensus
driving RFC or nothing.
I think we have plenty of key folks who would support weak type hinting and
frankly, I think that would be a huge win for everyone!

If I need to put forward a separate weak type hinting RFC which would
heavily plagiarize Andrea's good work then please let me know.

Andi


On Thu, Feb 5, 2015 at 3:44 PM, Thomas Bley ma...@thomasbley.de wrote:

 I think the consensus is not so far away.
 As far as I understand the rules, it is possible to vote yes and put up a
 new RFC to remove strict-declare after the voting ends?

 Regards
 Thomas

 Andi Gutmans wrote on 06.02.2015 00:22:

  I have to say I’m pretty disappointed at the opening of the vote.
  We had a pretty good RFC (thank you) for weak type hinting which was
 aligned
  with the spirit of PHP and everyone was able to rally around it.
  This has now been morphed into something very hard to swallow and IMO
 having
  such a declare(…) syntax will be ridiculed by the broader app dev
 community
  until the end of time… But even that syntax aside (it’s only syntax after
  all), I think we lost the ability to reach consensus on something so
 important
  to everyone which we haven’t been able to come to agreement on for over
 10
  years. Finally it was there, in reach and you made a 180 degree turn.
 
  I think it’d be so much easier for us to implement weak type hinting.
 Have
  everyone rally around it. Be happy and then learn and see whether an
 additional
  mechanism is really necessary. We could even add an E_STRICT_TYPES
  error_reporting flag to help folks “debug” their code if they so wish to
  see if there are any hotspots in their code they may want to take a look
 at -
  again not necessarily an error but maybe a debugging tool.
 
  But net, net - why not just implement the thing everyone can agree on.
 Have
  something really good in the spirit of the PHP Language for PHP 7 and
 learn how
  people leverage that… The reality is that for the majority of the Web
  community “1” coming in from HTTP should be accepted as a 1. Period.
 
  I voted “no” but I will vote “yes” for the competing RFC which is 80%
  of your RFC. Why are we not given that option??
 
  Andi
 
 
  On Feb 5, 2015, at 12:14 PM, Andrea Faulds a...@ajf.me wrote:
 
  Good evening,
 
  At long last, I’m going to put the RFC to a vote. It’s been long enough
 -
  I don’t think there needs to be, or will be, much further discussion.
 
  I’d like to make sure that everyone voting understands the RFC fully.
 Please
  read the RFC in full: the details are important. And if  anyone has any
  questions or uncertainties, please ask them before voting. I am very
 happy to
  answer them.
 
  I would urge everyone who wants type hints to vote for this RFC. It is
 not a
  perfect solution, but there can be no perfect solution to this issue.
 However,
  I think it is better than most of the alternatives suggested thus far -
 see
  the rationale section, and previous discussions. Crucially, this RFC
 would
  keep PHP a weakly-typed language, and not force either strict typing,
 nor weak
  typing, on anyone who does not want it. It would allow the addition of
 type
  hints to existing codebases. It would not create a situation where
 userland
  functions are strict yet internal functions are not, because the strict
 mode
  affects both. I’ve tested the implementation myself on my own code, and
 it
  worked well, providing benefits other proposals would not have given
 (see my
  previous post about my experiences).
 
  Voting starts today (2015-02-05) and ends in two weeks’ time
 (2015-02-19).
  In addition to the vote on the main RFC, there is also a vote on the
 type
  aliases issue, and a vote to reserve the type names for future RFCs’
 sake if
  this RFC fails.
 
  The RFC can be found here, and it contains a voting widget:
  https://wiki.php.net/rfc/scalar_type_hints
 
  Thank you for your time.
 
  --
  Andrea Faulds
  http://ajf.me/
 
 
 
 
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Andi Gutmans]

OK. But maybe that's why PHP is better than those languages :)

On Thu, Feb 5, 2015 at 3:49 PM, Rowan Collins rowan.coll...@gmail.com
wrote:

 On 5 February 2015 23:22:26 GMT, Andi Gutmans a...@zend.com wrote:

 having such a declare(…) syntax will be ridiculed by the broader app
 dev community until the end of time…

 I think that's laying it on a bit thick. It's no worse than Python's from
 __future__ import, or JS's 'use strict;' (quotes included).

 I wish unknown declare directives were ignored, though, because it would
 make for a great forward-compatibility mechanism. Still, that, like the
 syntax format, is a decision made many years ago.


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

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Andi Gutmans]

On Thu, Feb 5, 2015 at 3:53 PM, Andrea Faulds a...@ajf.me wrote:

 Hi Andi,

  On 5 Feb 2015, at 23:50, Andi Gutmans a...@zend.com wrote:
 
  I am not sure.
 
  I think we need to explicitly vote on a weak type hinting option.
  Andrea, I think this should be an option in any vote. Right now it feels
 like the only option to people is the very challenging, non-consensus
 driving RFC or nothing.
  I think we have plenty of key folks who would support weak type hinting
 and frankly, I think that would be a huge win for everyone!

 Yes, *you* think it’s a huge win for everyone. There are plenty who’d
 disagree.

 This RFC is a different attempt at consensus. Rather than asserting the
 dominance of one idea over the other and completely ignoring the segment of
 the community that believes in a particular approach, it allows using both
 approaches. It allows choice. It’s radical, sure, but I think trying to
 accommodate everyone’s use cases (or at least most people’s) is better than
 covering only one of two.


Just to be clear, I think it's a thoughtful RFC. I don't think it's dumb. I
can even see where you're coming from on trying to balance the approaches.
I do think we should also represent the weak type hinting only folks in a
ballot too.

Andi

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Andi Gutmans]

The folks who really want all this great strict typing should head over to
Oracle.com and download free open-source Java? I hear it's got a lot of
strict typing features in it. Only downside is that it'll take them 10x
longer to complete their projects. OK sorry. Had to say that :) I realize
it's not the same...

Andrea, while I don't agree with what you say I accept it. *But* exactly
for the reasons you state (the big divide) we should also have a weak type
hinting option to vote for in parallel. If you feel morally unable to do
that then I can copy your work and just have another RFC running in
parallel but I think that would do a disservice to the good work you've
done.

Andi


On Thu, Feb 5, 2015 at 3:47 PM, Andrea Faulds a...@ajf.me wrote:

 Hi Andi,

  On 5 Feb 2015, at 23:22, Andi Gutmans a...@zend.com wrote:
 
  I have to say I’m pretty disappointed at the opening of the vote.
  We had a pretty good RFC (thank you) for weak type hinting which was
 aligned with the spirit of PHP and everyone was able to rally around it.

 This is far from true. Some people on internals were happy, but only some,
 and everywhere outside internals I looked, the reception was far more
 negative.

  This has now been morphed into something very hard to swallow and IMO
 having such a declare(…) syntax will be ridiculed by the broader app dev
 community until the end of time…

 Nobody mocks Perl or JS for use strict.

  But even that syntax aside (it’s only syntax after all), I think we lost
 the ability to reach consensus on something so important to everyone which
 we haven’t been able to come to agreement on for over 10 years. Finally it
 was there, in reach and you made a 180 degree turn.

 “Consensus” is exaggerated. There was no consensus and to claim there was
 is to ignore the reality that the PHP community is divided over this issue.
 I’d love to say that everyone loves weak type hints and if that version had
 passed we’d all be dancing around happy holding hands, but the reception
 was not uniformly positive, not even close, and that’s just on internals.

  I think it’d be so much easier for us to implement weak type hinting.
 Have everyone rally around it. Be happy and then learn and see whether an
 additional mechanism is really necessary.

 Who’d be happy? I realise you and Zeev are big fans of weak types, as are
 many others, but there are also a lot of PHP developers who vehemently
 disagree with you.

  We could even add an E_STRICT_TYPES error_reporting flag to help folks
 “debug” their code if they so wish to see if there are any hotspots in
 their code they may want to take a look at - again not necessarily an error
 but maybe a debugging tool.

 Global error handlers affect all code the interpreter runs, which is why
 we’ve looked down on them in recent times.

  But net, net - why not just implement the thing everyone can agree on.

 Everyone doesn’t agree on it.

 If everyone did agree on it, v0.1 of the RFC would have been the one that
 went to vote.

  Have something really good in the spirit of the PHP Language for PHP 7
 and learn how people leverage that… The reality is that for the majority of
 the Web community “1” coming in from HTTP should be accepted as a 1. Period.

 It’s very well and good you claiming that the “majority” agree, but this
 does not match my experiences. The PHP community is not a single,
 homogenous entity. It is very difficult to judge.

  I voted “no” but I will vote “yes” for the competing RFC which is 80% of
 your RFC. Why are we not given that option??

 Because I cannot in good conscience push through something in the name of
 “consensus” which does not even approach it.

 --
 Andrea Faulds
 http://ajf.me/

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Andi Gutmans]

On Thu, Feb 5, 2015 at 4:05 PM, Andrea Faulds a...@ajf.me wrote:

 Hi Andi,

  On 5 Feb 2015, at 23:57, Andi Gutmans a...@zend.com wrote:
 
  The folks who really want all this great strict typing should head over
 to Oracle.com and download free open-source Java? I hear it's got a lot of
 strict typing features in it. Only downside is that it'll take them 10x
 longer to complete their projects. OK sorry. Had to say that :) I realize
 it's not the same…

 I don’t think it’s terribly funny to tell a large portion of the PHP
 community to go away.


Oh come on... You're taking me a bit too literally. Your proposal isn't
Java-like strict typing... I even said that.


  Andrea, while I don't agree with what you say I accept it. *But* exactly
 for the reasons you state (the big divide) we should also have a weak type
 hinting option to vote for in parallel. If you feel morally unable to do
 that then I can copy your work and just have another RFC running in
 parallel but I think that would do a disservice to the good work you've
 done.

 No, I don’t think that’s fair. I’d be against holding a vote on strict
 types only for the same reason: the community is divided. Letting one side
 “win is simply unfair on everyone else.


I don't understand that statement. You mean it's not OK for any side to win
unless you win? Or are you saying that you tried to strike a balance
between the two parties which you hoped everyone could rally around? What
if they can't? It's all or nothing? Btw, not trying to be facetious but
really trying to understand where you're coming from.


 To quote myself in the Scalar Type Hints thread, here’s a rough tally of
 who was in favour of what in the v0.1 thread (I think “yourself” was Zeev
 in that context):


Zeev and I aren't twins (thank god for him) and aren't always in agreement
on such topics. Looks like I am not on that list. Don't see him either
btw...

Anyway, I think I need to sleep on it... I understand what you're trying to
do. It's definitely not a crazy strict type hinting approach (which would
be very bad)... But I find elements of it challenging...

Andi


  On 15 Jan 2015, at 14:51, Andrea Faulds a...@ajf.me wrote:
 
  Let’s have a look. From a quick skim over the thread for v0.1:
 
  * In favour of weak types (or the RFC anyway): Adam, Stas, yourself,
 Jordi, Pierre,
  * Against, in favour of strict types: Maxime, Nikita, Markus, Marco,
 Leigh, Levi, Sven(?)
  * In favour of strict types, not against weak types as compromise:
 Matthew
  * Somewhat in favour: Sebastian
  * In favour of allowing both approaches: Marcio, Thomas, Marco
 
  I apologise if I am misrepresenting anyone’s position.
 
  This is unlikely to be super-representative of the PHP community.
 However, I’m not sure I’d say “overwhelmingly positive”. It can be easy to
 get confirmation bias when reading RFC threads.
 
  It is very clear to me that a lot of people would like strict types, and
 some people would like weak types. As to their relative numbers, I cannot
 say.
 
  I don’t think it’s really fair to cover only the use case of one half of
 the PHP community. The other half counts too. This is a rather divisive
 issue.

 As is rather clear, there was no such consensus on internals. Confirmation
 bias can be a powerful thing, and it’s easy to forget that the number of
 messages doesn’t reflect the number of participants.

 The views on other places were, from my experience, even more against weak
 types than internals. Internals seems to be the most pro-weak types PHP
 community I’m a part of.

 Because of this schism, I really think it would be completely unfair to
 force through weak types. I know internals might like it (or some of
 internals, anyway), and I know you and Zeev certainly do, but it’s not as
 clear-cut in the wider community.

 This isn’t some minor issue, either: it’s a very frequently resurfacing
 topic, and one which is particularly divisive. It’s not some minor syntax
 issue that merely holding a vote will solve.

 --
 Andrea Faulds
 http://ajf.me/

Re: [PHP-DEV] Warnings in zend_alloc.h

[Andi Gutmans]

Can you provide more info re: operating system and version? Compiler version?
Thanks. 

Sent from my iPhone

 On Jan 24, 2015, at 11:57 PM, Sebastian Bergmann sebast...@php.net wrote:
 
 Nut sure whether this is an issue or not but I see it a lot while
 compiling master:
 
   Zend/zend_alloc.h:57:236: warning: unknown attribute 'alloc_size'
   ignored [-Wunknown-attributes]
   __attribute__ ((visibility(default))) void* _emalloc(size_t size,
   const char *__zend_filename, const uint __zend_lineno,
   const char *__zend_orig_filename, const uint __zend_orig_lineno)
   __attribute__ ((__malloc__)) __attribute__ ((alloc_size(1)));
 
   Zend/zend_alloc.h:61:250: warning: unknown attribute 'alloc_size'
   ignored [-Wunknown-attributes]
   __attribute__ ((visibility(default))) void* _ecalloc(size_t nmemb,
   size_t size , const char *__zend_filename, const uint __zend_lineno,
   const char *__zend_orig_filename, const uint __zend_orig_lineno)
   __attribute__ ((__malloc__)) __attribute__ ((alloc_size(1,2)));
 
   Zend/zend_alloc.h:62:238: warning: unknown attribute 'alloc_size'
   ignored [-Wunknown-attributes]
   __attribute__ ((visibility(default))) void* _erealloc(void *ptr,
   size_t size, int allow_failure , const char *__zend_filename,
   const uint __zend_lineno , const char *__zend_orig_filename,
   const uint __zend_orig_lineno) __attribute__ ((alloc_size(2)));
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 

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

Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2

[Andi Gutmans]

 On Jan 15, 2015, at 6:51 AM, Andrea Faulds a...@ajf.me wrote:
 
 
 I’m not really sure this is true. I agree that strict types aren’t entirely 
 in keeping with the “PHP way”. However, there are plenty of people who are 
 against them not for that reason, but simply because they don’t work well for 
 them. Plus, I’m not sure strict typing causes as much of a problem if it is 
 off by default. Nobody is forced to use it, the language would stay 
 beginner-friendly and weakly-typed. Indeed, strict type hints don’t stop PHP 
 being weakly-typed. They just check types at function call boundaries. Think 
 of it as a sanity check.
 
 
 Let’s have a look. From a quick skim over the thread for v0.1:
 
 * In favour of weak types (or the RFC anyway): Adam, Stas, yourself, Jordi, 
 Pierre,
 * Against, in favour of strict types: Maxime, Nikita, Markus, Marco, Leigh, 
 Levi, Sven(?)
 * In favour of strict types, not against weak types as compromise: Matthew
 * Somewhat in favour: Sebastian
 * In favour of allowing both approaches: Marcio, Thomas, Marco
 
 I apologise if I am misrepresenting anyone’s position.
 
 This is unlikely to be super-representative of the PHP community. However, 
 I’m not sure I’d say “overwhelmingly positive”. It can be easy to get 
 confirmation bias when reading RFC threads.
 
 It is very clear to me that a lot of people would like strict types, and some 
 people would like weak types. As to their relative numbers, I cannot say.
 
 I don’t think it’s really fair to cover only the use case of one half of the 
 PHP community. The other half counts too. This is a rather divisive issue.

Man, oh man. I thought we finally had a proposal with 0.1 that everyone could 
give a thumbs up to and move forward. One that enables stronger type stability 
(for those who want it) and even can allow for under-the-hood optimizations.

I really think we took a step back with 0.2. I think a super strict approach is 
really against what PHP is about.
And a configuration option that significantly impacts how the language behaves 
is probably the worst thing we could do. I remember I bumped into something 
like that with Visual Basic and expression short circuiting (yes the first 
version didn’t have that and it became a configuration option). Completely 
horrible and unmaintainable.

We cannot have a configuration option that changes the core language behavior. 
That is a no-no and there’s a good reason why languages stay away from that.

And definitely disappointed that we took a step back after it seemed we could 
finally come to an agreement on this agonizing topic.

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

Re: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)

[Andi Gutmans]

 On Jan 9, 2015, at 5:10 PM, Sara Golemon poll...@php.net wrote:
 
 On Thu, Jan 8, 2015 at 5:44 PM, Pierre Joye pierre@gmail.com wrote:
 The fact that hhvm implements a significant part of the extensions (or
 other areas) using PHP+additional syntax as well as adding cleaner
 APIs or mechanisms for the C parts only confirms me one thing: the
 very 1st problem we have to solve is to ease the extension creation,
 by drastically changing the internals APIs  tools. Bundling script
 does not help here, we are using a scotch tape to repair something
 that should have been replaced or redesigned since long already. I am
 not blaming anyone, the engine design, historically, does not make
 such changes easy.
 Funny to see you mention this.  I literally just pulled together a
 meeting today to discuss HHVM's admittedly unstable extension API.
 One idea to emerge from this was to design a new extension API
 agnostic of underlying implementation.  An API which, if done right,
 could be adapted equally to both PHP7 and HHVM *and* provide the
 opportunity to introduce PHP5 shims so that a single extension could
 be written to function identically under any PHP runtime, and any
 version. If done right, could make extensions not just source
 compatible, but *binary* compatible as well.  The engine details can
 change, but the public-facing extension API could offer a consistent
 way of doing the one and only thing that extensions should have to do:
 Glue PHP into external libraries.
 
 That's a bit pie in the sky, I'll admit, but wouldn't that be cool?
 Fact is, JNI does this for Java already, so there's precedence to
 learn from.  Heck, we're actually halfway there with HHVM's
 ext_zend_compat layer, which makes PHP extensions (mostly) source
 compatible with HHVM.
 

I was a *very* heavy user of JNI. Sucked big time. You pay a high price for 
trying to keep a consistent API and marshaling. While this is slightly 
different I don't see how you avoid some of the additional overhead plus it 
will be very challenging to really cover everything that's needed. 
Just my 2 cents. Had to respond because of how crappy JNI was/is :)
Andi



 While I could work on this in the dark, manipulating HHVM's APIs with
 one hand and adding proxy interfaces to PHP (as an extension) with the
 other, I'd much rather have involvement from others.
 
 What do you think?
 
 -Sara
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 

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

Re: [PHP-DEV] [VOTE][RFC] PHP 5.7

[Andi Gutmans]

 On Dec 30, 2014, at 12:26 AM, Stanislav Malyshev smalys...@gmail.com wrote:
 
 Hi!
 
 I’m going to put the PHP 5.7 RFC to a vote, since it’d been 2 weeks.
 I’m not entirely certain myself whether it’s a good idea, but I’d
 like it for us to vote on it so we can settle the matter. If people
 vote against 5.7, a new RFC proposing an alternative could always be
 made by someone.
 
 I still haven't achieved a proper understanding of what 5.7 would
 actually include (so far the only real BC thing mentioned that it can
 warn about is the switch thing, and IMHO making the new minor just
 because of that makes little sense, of course I'm not counting
 non-accepted RFCs since otherwise there's like 40 of them), so I intend
 to vote no, but if somebody really sees something substantial that I
 missed, please point me out, as I am not opposed to the idea of 5.7 just
 don't see any practical content for it for now.

My take is that anything that takes away efforts from getting PHP 7 to market 
faster is a distraction.
PHP.net needs to continue to show leadership in evolving the runtime. We have a 
pretty great jewel in our hands. Some very good RFCs that are going to make it 
in. Postponing PHP 7 (which this would as we have a finite amount of resources 
on this list) would not be good for our users.

Andi

P.S. - Not interested in debating it. Definitely accept folks can have other 
views. Just wanted to state my opinion clearly :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Abstract Syntax Tree

[Andi Gutmans]

got it. thanks!

On Aug 18, 2014, at 11:36 PM, Dmitry Stogov dmi...@zend.com wrote:

 Hi Andi,
 
 We already discussed most of semantic changes introduced in AST patch.
 Most of them came from another approved RFC 
 https://wiki.php.net/rfc/uniform_variable_syntax
 
 Thanks. Dmitry.
 
 
 On Tue, Aug 19, 2014 at 6:32 AM, Andi Gutmans a...@zend.com wrote:
 Hi Nikita,
 
 I reviewed the AST RFC on my way to vote but there was something that wasn’t 
 clear to me.
 This patch introduces some semantic/behavioral changes in addition to the AST.
 Are these as a side-effect of how AST was implemented? Or are they unrelated 
 to the AST patch?
 I think some of them make sense but I’m having a bit of a hard time 
 separating out the benefits of the AST (which I really like) and making other 
 changes to semantics w/o really understanding if they are side-effects and we 
 have no choice vs. we’re trying to solve for two separate items in one RFC.
 Any BC breaks here we think could bite us?
 
 Any insight would be much appreciated.
 Thanks!
 Andi
 
 On Aug 18, 2014, at 9:41 AM, Nikita Popov nikita@gmail.com wrote:
 
  Hi internals!
 
  I've opened the vote on the Abstract Syntax Tree RFC:
 
 https://wiki.php.net/rfc/abstract_syntax_tree#vote
 
  Thanks,
  Nikita
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 

Re: [PHP-DEV] [VOTE] Abstract Syntax Tree

[Andi Gutmans]

Hi Nikita,

I reviewed the AST RFC on my way to vote but there was something that wasn’t 
clear to me.
This patch introduces some semantic/behavioral changes in addition to the AST.
Are these as a side-effect of how AST was implemented? Or are they unrelated to 
the AST patch?
I think some of them make sense but I’m having a bit of a hard time separating 
out the benefits of the AST (which I really like) and making other changes to 
semantics w/o really understanding if they are side-effects and we have no 
choice vs. we’re trying to solve for two separate items in one RFC.
Any BC breaks here we think could bite us?

Any insight would be much appreciated.
Thanks!
Andi

On Aug 18, 2014, at 9:41 AM, Nikita Popov nikita@gmail.com wrote:

 Hi internals!
 
 I've opened the vote on the Abstract Syntax Tree RFC:
 
https://wiki.php.net/rfc/abstract_syntax_tree#vote
 
 Thanks,
 Nikita


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

Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP (again)

[Andi Gutmans]

 On Jul 23, 2014, at 11:23 AM, Kris Craig kris.cr...@gmail.com wrote:
 
 On Wed, Jul 23, 2014 at 7:39 AM, Ferenc Kovacs tyr...@gmail.com wrote:
 
 On Wed, Jul 23, 2014 at 4:32 PM, Andrea Faulds a...@ajf.me wrote:
 
 
 On 23 Jul 2014, at 15:21, Ferenc Kovacs tyr...@gmail.com wrote:
 
 I also think that it would be reasonable to have two weeks for the
 votes
 to
 come in, as https://wiki.php.net/rfc/voting states that There'd be a
 minimum of 2 weeks between when an RFC that touches the language is
 brought
 up on this list and when it's voted on is required. and while the code
 impact for this rfc is really small (modifying the version numbers),
 but
 it
 is an important decision for the project and for the language.
 sorry if it feels being too bureaucratic
 
 That refers to the minimum time for discussion, I don’t think we need 2
 weeks for a vote. In a week’s time when the vote would end, if it looks
 like not enough people have voted, I suppose it could be extended.
 
 
 argh, you I right, the relevant part is The voting has minimal period of 1
 week, which can be extended when circumstances warrant it., so one week is
 fine by the rules.
 
 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu
 
 Wow, looks like the PHP 7 votes are dominating so far.  If you want to
 avoid the confusion and ridicule that will result from skipping a version
 increment, I suggest you remember to cast your vote.


Let's keep this clean and not start a 100 email thread restating what both view 
points have already said many times or do an artificial rally. 

 
 Editorial aside, I'm glad that the two sides were able to come together and
 get this to a vote finally.



 
 --Kris

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

Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP

[Andi Gutmans]

On Jul 20, 2014, at 8:39 AM, Peter Cowburn petercowb...@gmail.com wrote:

 
 As for the PHP 7 section, this is by far the dominant part of the RFC. Both
 in terms of physical presence, but also points and counter-points.
 
 It also contains, IMO unnecessarily, light-hearted and jokey comments not
 befitting an RFC  — unless you see the RFC as a joke too ;) — about 6 being
 a failed version in other software, and 7 a lucky number. Seriously?..
 
 The RFC as a whole is very light on trying to summarise, or at least
 provide reference to, the history of PHP 6” and discussions around it.
 This is disappointing, if the aim was to see a balanced summary of previous
 discussions.  However, this particular gripe is a common issue with our
 RFCs as a whole.
 
 Personally, regardless of the content of the RFC, I feel that the choice is
 obvious. I’m just a little concerned about the lack of quality from both
 “sides” in presenting their argument(s), or not.

I actually think that both perception and facts need to be take into account on 
naming/version number decisions.
I must say I do share the perception that many version 6’s in open-source have 
been failures and I’ve heard many people ridiculing the PHP 6 is like Perl 6. 
So I don’t think it’s irrelevant. - This is perception but it matters.

Fact - There is SO much PHP 6 content out there and many folks think they know 
what PHP 6 is that I think the confusion we’d be creating in calling this PHP 6 
would be huge and unnecessary. To the point I am even surprised we have folks 
here who are resisting not calling it PHP 6. It feels pretty obvious to me that 
we are doing people a disservice calling it PHP 6.

But anyway, didn’t want to restart the discussion but just wanted to point out 
that RFC should address both perception and fact because both matter. It’s not 
just a technical discussion.

Andi



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

RE: [PHP-DEV] Disabling the GC during shutdown

[Andi Gutmans]

-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Thursday, June 20, 2013 8:20 PM
To: Anthony Ferrara
Cc: Laruence; internals@lists.php.net
Subject: Re: [PHP-DEV] Disabling the GC during shutdown

 However, that's not really fixing the situation either, as the zval is
 still getting nuked (but only partially).

If there's a memory overwrite or use-after-free is going on, this patch
is not a
complete solution - it relies on the fact that bad data will be always
out of
range of good data. I see no way to ensure that - so if there's an
overwrite
that writes garbage inside the object there will be situations where the
garbage looks exactly like a valid object ID and it will still crash, but
it would
be significantly harder to reproduce.
So I think before patching it we need to get to the root cause and figure
out
why it happens and what causes it, instead of partially fixing the
symptom

I agree with that. I think it'd be a mistake to submit any patch without
us understanding root cause.
We may cover up a bug which will resurface elsewhere...
Hopefully you can find a way to pin it down.

Thanks for putting this much effort into it!
Andi

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

[PHP-DEV] PHP 5.5 Upgrade Notes Question

[Andi Gutmans]

Hi,



Just reading the excellent PHP 5.5 Upgrades Notes -
https://raw.github.com/php/php-src/php-5.5.0beta1/UPGRADING



Some questions:

-  Dropped support for Windows XP  2003:

o   Was this an RFC? At what point was it decided? (I may have missed it in
that case I’d just appreciate a pointer to where it was decided). I am
asking because XP still seems to be quite prevalent and while Microsoft
wants to incentivize people to upgrade by being aggressive around end of
life, not sure that’s the most convenient for our users.

-  In “Backwards Incompatible Changes” there’s a big list of BC
changes that are internals and don’t impact user land. So could come across
a lot more intimidating than it is. I think we should move towards the end
of the upgrade notes in a section of its own that’s “PHP Internals Changes
– does not impact user space” (or something of that sort). I’m happy to
make that change but wanted to bring it up before tackling it.

-  On similar note as previous item, should we put New Features
before BC changes? No big deal but it’s always nice to have the more
positive piece first :)




Andi

RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution

[Andi Gutmans]

-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Thursday, March 07, 2013 1:58 PM
To: Philip Olson
Cc: David Soria Parra; internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP
distribution

Philip,

Shouldn't we be focusing on how this makes PHP better? And not nitpick
 about a percentage point or two?


Well, this passed with 62.8%. Property accessors failed with 60.7%. The
target
for acceptance is 66.6%. So 3.8% is enough to throw away, but 5.9% isn't?

I think the point of this discussion is that rules are rules for a
reason.
You can't be high and holy and deny one RFC judiciously, and then hand-
wave and say the next RFC doesn't matter because the intention is there
(or
whatever rationale is).

I have to say I wasn't sure whether to laugh or cry at some of the
ludicrous statements that have been made here.

The 2/3 vote rule was meant to protect the language from not becoming
bloated, i.e. language syntax feature creep. This has been a serious
concern for many of us over the past years with just an ever increasing
flood of new language syntax suggestions coming in. I think very few of us
looked at that as a catch-all for any infrastructure change in PHP incl.
evolving PHP extensions, core runtime changes, etc..

The 62.8% comparison to 60.7% is the most out of touch thing I've read on
this mailing list in a long time. If you're talking about pure feature
yay/nay then 94% have given a yay to this feature. The split is the
timing.

And as far as timing is concerned I do not see how this whole thing falls
into the 2/3 vote for new language syntax/prevent feature creep rule.
Many times in the past have we aligned new PHP versions with runtime
improvements esp. as they are often exciting and beneficial to most of our
audience. I don't see why we wouldn't do that given that the cost is
pretty minimal and the benefit to our audience is high.

Andi

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

RE: [PHP-DEV] 6.0 And Moving Forward

[Andi Gutmans]

It is absolutely related to how the PHP project approaches things.
As a project we have always valued backwards compatibility and migration path. 
That focus and approach is one of the reasons why PHP is so pervasive. It is 
sometimes more fun to break (fix) everything but the reality is that while it 
may feel better it ultimately can have a significantly negative impact on PHP 
pervasiveness and success.

Generally speaking we've done a good job in balancing the two and phasing out 
functionality over time in a responsible way. Like any project, we've also had 
our missteps on that front which has made migration a bit more painful than it 
needed to be.

Andi

-Original Message-
From: Andrew Faulds [mailto:ajf...@googlemail.com]
Sent: Friday, July 20, 2012 5:20 AM
To: Lester Caine
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] 6.0 And Moving Forward

Whilst I feel some sympathy for you, I must ask if it is really the PHP project
to blame if your hosts use old PHP versions?
On Jul 20, 2012 12:50 PM, Lester Caine les...@lsces.co.uk wrote:

 Daniel Macedo wrote:

 One little change in PHP5.3.10 or so wiped out a whole block of
 mine, and
 the fix involved a re-writing all the ?= code across many pages.
 Simply because the ISP would not switch back on short tag.

 Did you really go through all code manually to change the short tags?
 You should be smarter than that:
 https://github.com/danorton/**php_replace_short_tags/https://github.
 com/danorton/php_replace_short_tags/


 If I had easy access to every FTP server and local copies of the code
 bases in each, but we still have not rationalised what we inherited
 structure wise, and the update to PHP5.3 had not even been advised for
 those hosting packages! I think it was a mistake and unfortunate that
 the version they picked had the short_tag regression.

 But I want to get these sites BACK to '?=' format as well since
 '?php echo' is simply wrong for the style of site and framework that they
use.
 I'd been tidying them up to be consistent before they blew up.

  One of the reasons major versions are introduced is BC breaks, those
 don't come around frequently nor are introduced lightly, and you
 still go through the E_DEPRECATED  .ini setting  disabled 
 optional extension, for a safe cycle.

 I like to think we, as smart developers, would like to see complexity
 reduced, even if we need to input a few man-hours into adapting the
 old surviving masterpieces.


 I've spent many DAYS on the 'strict' updates to other peoples
 masterpieces So that argument is my main objection to many of these
 'complexity reductions' as the changes I am making add nothing to the
 functionality of these sites.

 The MAIN problem here is that ISP's do not update supplied versions of
 PHP even with security fixes, simply because that cause them more
problems.
 Many of the hosted sites I still need to move over are still on PHP5.2.?
 and dropping them onto a PHP5.4 machine even with all the ini settings
 correct simply does not work because they need bringing up to date to
 PHP5.3 first. I'm dragging my feet moving some 100 sites off 5.2
 simply because I don't know what problems it's going to cause :(

 The stepping stone approach being pushed for these sorts of changes
 only works if everybody is following on the same stone. I bet 75% of
 sites are still on 5.2 and that moving them up to 5.4 simply would not work
cleanly?
 At least every one needs testing before moving them ... and that takes
 time ...

 --
 Lester Caine - G8HFL
 -
 Contact -
 http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=
 contact L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/ Model Engineers Digital
 Workshop - http://medw.co.uk Rainbow Digital Media -
 http://rainbowdigitalmedia.co.**ukhttp://rainbowdigitalmedia.co.uk



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

[PHP-DEV] PHP 5.4 Benchmarks

[Andi Gutmans]

Hi,

As many of you know we made huge improvements in PHP 5.4 memory usage (enabling 
higher concurrency) and runtime performance.
We've done our own benchmarks but it'd be great to hear from others re: what 
you're seeing with your real-world apps.

If you have any experiences to share please do. Benchmarking is not easy and 
can be misleading (config not being the same, compiler options, different 
version of byte code caches, etc..) so the more data points we get the better 
the info re: performance gains.

Thanks,
Andi

RE: [PHP-DEV] PHP 5.4 Benchmarks

[Andi Gutmans]

Cache results are of course important. Memory usage would be great too.

Thanks!!
Andi

-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Wednesday, February 01, 2012 10:19 AM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 5.4 Benchmarks

hi Andi,

We do automatic perf tests as part of the CI. Some of the results can be seen
here for example here:

http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20120119-
5.3.9-5.4.0RC6.html

for a 5.3.9 vs 5.4.0RC6 comparison. There are other in the same location.

We are going to do add some more perf related tests later.

Cheers,

On Wed, Feb 1, 2012 at 7:08 PM, Andi Gutmans a...@zend.com wrote:
 Hi,

 As many of you know we made huge improvements in PHP 5.4 memory
usage (enabling higher concurrency) and runtime performance.
 We've done our own benchmarks but it'd be great to hear from others re:
what you're seeing with your real-world apps.

 If you have any experiences to share please do. Benchmarking is not easy
and can be misleading (config not being the same, compiler options,
different version of byte code caches, etc..) so the more data points we get
the better the info re: performance gains.

 Thanks,
 Andi



--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

RE: [PHP-DEV] PHP 5.4 Benchmarks

[Andi Gutmans]

Optimizer+ is free and packaged in Zend Server Community Edition. Happy to get 
you and anyone else who wants to run benchmarks a copy out of cycle. We haven't 
put a preview up yet but have it working.

Re: memory usage, I've seen some great results so definitely will be nice to 
see what others are seeing.

Thanks,
Andi

-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Wednesday, February 01, 2012 10:37 AM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 5.4 Benchmarks

hi!

I could add zend optimizer to the stack but we do not have a license (or is it
free for the optimizer only?).

APC should join the party soon, not sure yet if it is ready yet. We will run
compat tests first.

About the memory usage, yes, this is on my todos. I have a tool for that (on
win) which has less than 1% impact on perf so we can compare all in one run.
But that will have to wait post final.

Cheers,

On Wed, Feb 1, 2012 at 7:24 PM, Andi Gutmans a...@zend.com wrote:
 Cache results are of course important. Memory usage would be great too.

 Thanks!!
 Andi

-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Wednesday, February 01, 2012 10:19 AM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 5.4 Benchmarks

hi Andi,

We do automatic perf tests as part of the CI. Some of the results can
be seen here for example here:

http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-
20120119
-
5.3.9-5.4.0RC6.html

for a 5.3.9 vs 5.4.0RC6 comparison. There are other in the same location.

We are going to do add some more perf related tests later.

Cheers,

On Wed, Feb 1, 2012 at 7:08 PM, Andi Gutmans a...@zend.com wrote:
 Hi,

 As many of you know we made huge improvements in PHP 5.4 memory
usage (enabling higher concurrency) and runtime performance.
 We've done our own benchmarks but it'd be great to hear from others re:
what you're seeing with your real-world apps.

 If you have any experiences to share please do. Benchmarking is not
 easy
and can be misleading (config not being the same, compiler options,
different version of byte code caches, etc..) so the more data points
we get the better the info re: performance gains.

 Thanks,
 Andi



--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org



--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

RE: [PHP-DEV] PHP 5.4 Benchmarks

[Andi Gutmans]

Absolutely. Will gather those and send them over...

Andi

-Original Message-
From: Johannes Schlüter [mailto:johan...@schlueters.de]
Sent: Wednesday, February 01, 2012 10:49 AM
To: Andi Gutmans
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 5.4 Benchmarks

On Wed, 2012-02-01 at 18:08 +, Andi Gutmans wrote:
 We've done our own benchmarks but it'd be great to hear from others

Can we also hear from you? :-)

johannes
   who doesn't have proper benchmarks himself, but is interested in
   seeing them ;-)

RE: [PHP-DEV] E_STRICT in production

[Andi Gutmans]

-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Saturday, July 23, 2011 3:22 PM
To: Stas Malyshev
Cc: PHP Internals
Subject: Re: [PHP-DEV] E_STRICT in production

hi Stas,

The idea of E_STRICT when we introduced it was to help developers. So I
tend to think that we should not enable it in php.ini-production.

Agree.

Andi
 


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

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

[Andi Gutmans]

-Original Message-
From: Pascal COURTOIS [mailto:pascal.court...@nouvo.com]
Sent: Thursday, June 16, 2011 12:28 AM
To: Lester Caine
Cc: PHP internals
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)

Le 16/06/2011 09:19, Lester Caine a écrit :

when you have a bug in PHP it should not ever ever crash PHP and
 unfortunately I encountered that case dozens of times.
 At least on Linux is just recovers and carries on

 If PHP crashes, yes, it recovers but it's VERY resource and time consumming.
If PHP corrupts some memory, it does not crash fastcgi processes but the
next
request(s) behave erratically.

I have some news for you. Ruby has crashes, Python has crashes, even Java has 
security issues and crashes (check out the Java bug database. It's bigger than 
ours).
Of course our goal is to reduce this as much as possible for PHP and as was 
stated here, short concise reproducible scripts do get attention. 

Re: memory models, PHP actually has a memory model that is very robust and 
prevents leaks from happening. Every memory model has its pros and cons but 
leak-free Java is a great example of where the memory model more often than not 
bites you in your tush more than you'd think (and I can say that after having 
done quite a bit of Websphere development - yuck).
 
So just help us with identifying root cause and you will see the internals@ 
group very much jumping on the issues and try to resolve them.
Andi

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

[Andi Gutmans]

-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Wednesday, June 15, 2011 2:33 AM
To: Andi Gutmans
Cc: Derick Rethans; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)

On Wed, Jun 15, 2011 at 7:02 AM, Andi Gutmans a...@zend.com wrote:

 Hence my suggestion to bundle MongoDB extension and possibly work on
additional extensions. Some of my suggestions probably rightfully didn't get
much interest such as Thrift.

See my comment in your other thread and below.

 Maybe we should consider making a list of extensions we think could be
beneficial and the new mentorship program can actually help deliver some of
them?

I do not thnk it is a good thing to begin a discussion about this exact topic 
and
then totally ignore it.


I think it got lost in the very long and varying discussions. Will dig up and 
take a look. I had a couple of hectic weeks.

I also think that it is somehow wrong to post something asking to do not 
propose
new things when we finally have more people involved in proposals and
discussions. Maybe that's just me me but I do think that the main problem we
have (besides the ones we identified and try to fix right now) is the complete
lack of open discussions about possible new features, in this list with new or
existing contributors.

I did not say we should not propose or have discussions (I am in favor of 
adding [] for arrays for example). But I am saying the bias should be not to 
include new language functionality unless it has very broad appeal  serious 
upside impact. The bias should be against feature creep.

Andi


--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

[Andi Gutmans]

What I am saying is if we accepted even 50% of what people felt very passionate 
about because their favorite language of the day has it then PHP would become 
overly complex, bloated and very challenging for users to pick up. C++ for 
example was a good language but is a good example of trying to do too much and 
getting overly complex over time (at least in my opinion).

I do think we should have new feature discussions and need to ensure PHP 
evolves with the market and its users but have to ensure that we still keep it 
simple, easy to adopt and maintainable. Also, I think we do not need 100 ways 
of doing the same thing. Choice is good but too much choice is not. 

As I said in my previous email, while I think there are areas we can and should 
innovate in and evolve the core language I believe a lot of the innovation also 
has to happen at the framework and extension-level. I do not think there's a 
resource issue at the language level. When a new feature does get slated to be 
included we always have plenty of resources deployed on it to harden it and 
make sure it gets into the core vm in the right way (it is almost never the 
same as the original patch).

I do think having more people work on extensions for some of the up and coming 
technologies would be super valuable. Seems like everyone wants to try and get 
their favorite language feature in but less are stepping up to work on 
extensions. What can you contribute?

Andi

From: dukeofgaming [mailto:dukeofgam...@gmail.com] 
Sent: Wednesday, June 15, 2011 7:36 PM
To: Andi Gutmans
Cc: Pierre Joye; Derick Rethans; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)

Hi,

I think that -in any context- the if it aint broke don't fix it is a very 
depressing attitude to have, and a very wrong one in any open source community.

If the signal to noise ratio is the problem, I think its better to focus on 
that problem, not shutting down the signal. If PHP is a resource crunched 
project, I think its better to focus on that problem, not rejecting feature 
requests.

(I might appear as impertinent with what I'm going to say, but bear with me, 
I'm being well-intentioned and mean no offense; just want to be honest).

Regarding the signal to noise ratio, I have one question: how did traits get 
accepted?, having seen the kind of conversations in the lists it makes almost 
no sense to me how something so radical and complex could make its way to PHP 
so quickly and a simple and convenient thing like a short array syntax cannot, 
and something so basic as annotations raises so much pointless (just not to say 
ignorant) debate. Was it the to-the-point RFC and solid patch?, was it that the 
conversations were just on another level so not anyone could just say -or 
troll- traits are no solution! *spit*, lets do aspects instead!. I know it 
took some time, but while lurking the lists IIRC I never saw any opposition to 
traits... could anyone tell me what was the magic behind this?, could it be 
repeated?.

Regarding resources, I think this is one of the main things rendering the 
community unhealthy (at least it feels like that to me) and I even feel 
bitterness in the air. I think that the definite solution to this is a DVCS 
like git and hosting the code at github, or like mercurial and hosting the code 
at bitbucket, please don't be angered at this suggestion (as I know the switch 
to SVN is a fairly recent one), you can ask around SVN geeks that went the 
distributed way and they will tell you things, wonderful things of how they 
don't know how could they could endure that much with that in their project, 
and if its an open source one, how much the switch has done in favor of 
contributions.

Regardless of everything, I like that the PHP community has so much passion and 
energy, sometimes in a not constructive way, but that is a good problem to have 
in my opinion, really, don't take it for granted, it just needs a little 
direction.
Best regards,

David Vega

On Wed, Jun 15, 2011 at 8:46 PM, Andi Gutmans a...@zend.com wrote:
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Wednesday, June 15, 2011 2:33 AM
To: Andi Gutmans
Cc: Derick Rethans; PHP Developers Mailing List
Subject: Re: [PHP-DEV] Give the Language a Rest motion (fwd)

On Wed, Jun 15, 2011 at 7:02 AM, Andi Gutmans a...@zend.com wrote:

 Hence my suggestion to bundle MongoDB extension and possibly work on
additional extensions. Some of my suggestions probably rightfully didn't get
much interest such as Thrift.

See my comment in your other thread and below.

 Maybe we should consider making a list of extensions we think could be
beneficial and the new mentorship program can actually help deliver some of
them?

I do not thnk it is a good thing to begin a discussion about this exact topic 
and
then totally ignore it.

I think it got lost in the very long and varying discussions. Will dig up and 
take a look. I had a couple

RE: [PHP-DEV] Give the Language a Rest motion (fwd)

[Andi Gutmans]

Hi Derick and all,

I think we have had some reasonable additions to the language in PHP 5.3 + will 
have a couple of good ones in PHP 5.4. That said, I do agree we should have a 
strong bias against language feature creep unless there is a really strong 
compelling reason.
I do think that an increase of focus on enriching the eco-system around the 
core language esp. PHP extensions will be a lot more valuable. This is 
especially so if we can target many of the up and coming technologies and get 
such extensions production ready to bundle in Core PHP (hence my previous email 
re: adding some modern extensions).

We've benefited in the past from a lot of enhancements and innovation around 
extensions incl. SimpleXML, variety of database, json, datetime, etc... Having 
another wave of really strong core extensions would be very beneficial and 
consistent with our past bias to deliver everything Web developers need 
out-of-the-box.

Hence my suggestion to bundle MongoDB extension and possibly work on additional 
extensions. Some of my suggestions probably rightfully didn't get much interest 
such as Thrift.

Maybe we should consider making a list of extensions we think could be 
beneficial and the new mentorship program can actually help deliver some of 
them?

Stas, on a different note, weren't we going to roll a 5.4 alpha?
Andi

-Original Message-
From: Derick Rethans [mailto:der...@php.net]
Sent: Tuesday, June 07, 2011 4:05 AM
To: PHP Developers Mailing List
Subject: [PHP-DEV] Give the Language a Rest motion (fwd)

Hi,

Short-array syntax, Native JSON, Currying. I can almost only say one thing:
WHY?!

And because of that, I'd like to forward a mail by Zeev from a few years ago. I
think it applies now even more than then:

-- Forwarded message --
Date: Thu, 09 Mar 2006 12:57:32 +0200
From: Zeev Suraski z...@zend.com
To: internals@lists.php.net
Subject: [PHP-DEV] Give the Language a Rest motion

I'd like to raise a motion to 'Give the Language a Rest'.

Almost a decade since we started with the 2nd iteration on the syntax (PHP 3),
and 2 more major versions since then, and we're still heatedly debating on
adding new syntactical, core level features.

Is it really necessary?  I'd say in almost all cases the answer's no, and a 
bunch of
cases where a new feature could be useful does not constitute a good enough
reason to add a syntax level feature.  We might have to account for new
technologies, or maybe new ways of thinking that might arise, but needless to
say, most of the stuff we've been dealing with in recent times doesn't exactly
fall in the category of cutting edge technology.

My motion is to make it much, much more difficult to add new syntax-level
features into PHP.  Consider only features which have significant traction to a
large chunk of our userbase, and not something that could be useful in some
extremely specialized edge cases, usually of PHP being used for non web stuff.

How do we do it?  Unfortunately, I can't come up with a real mechanism to
'enforce' a due process and reasoning for new features.

Instead, please take at least an hour to bounce this idea in the back of your
mind, preferably more.  Make sure you think about the full context, the huge
audience out there, the consequences of  making the learning curve steeper with
every new feature, and the scope of the goodness that those new features bring.
Consider how far we all come and how successful the PHP language is today, in
implementing all sorts of applications most of us would have never even thought
of when we created the language.

Once you're done thinking, decide for yourself.  Does it make sense to be
discussing new language level features every other week?  Or should we,
perhaps, invest more in other fronts, which would be beneficial for a far 
bigger
audience.  The levels above - extensions to keep with the latest technologies,
foundation classes, etc.  Pretty much, the same direction other mature
languages went to.

To be clear, and to give this motion higher chances of success, I'm not talking
about jump.  PHP can live with jump, almost as well as it could live without it
:)  I'm talking about the general sentiment.

Zeev

--
http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation:
http://xdebug.org/donate.php
twitter: @derickr and @xdebug

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


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

RE: [PHP-DEV] Re: [RFC] Improved parser error message

[Andi Gutmans]

Hi Felipe,

Read the archives. We discussed T_PAAMAYIM_NEKUDOTAYIM extensively and agreed 
to keep it as a historical landmark. Let's not have the discussion yet again 
within the same year. Google it just to see the # of mentions. 

What we could do as a compromise between history and improving many of the 
parse error messages is:
Parse error: syntax error, unexpected :: (T_PAAMAYIM_NEKUDOTAYIM) in Command 
line code on line 1

Generally speaking I'm OK with the other changes but I don't know if any 
extensions or scripts depend on them (probably not).
I suggest to give it another couple of days to see if anyone has any valid 
concerns on breakage this could cause.

Andi

-Original Message-
From: Felipe Pena [mailto:felipe...@gmail.com]
Sent: Tuesday, May 17, 2011 7:18 AM
To: internals
Subject: [PHP-DEV] Re: [RFC] Improved parser error message

2011/5/16 Felipe Pena felipe...@gmail.com

 Hi all,
 As I have proposed previously in an old thread... What about we name
 all the tokens to have an improved parser error message? (i.e. anymore
 T_PAAMAYIM_NEKUDOTAYIM, T_DOLLAR_OPEN_CURLY_BRACES in the
messages
 etc)


 [...]



Other examples and patch at:
 https://wiki.php.net/rfc/improved-parser-error-message

 Any thoughts?

 Thanks.


So... In case of no objections, I'll commit it in trunk and 5_4 branch, Is it 
okay? :)

--
Regards,
Felipe Pena

RE: [PHP-DEV] 5.4 again

[Andi Gutmans]

-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Sunday, May 08, 2011 4:41 PM
To: PHP Internals
Subject: [PHP-DEV] 5.4 again

Hi!

I would like to propose the following process (of course, dates can be moved
around, etc. - I consider phase lengths be more important that actual dates, 
but
any of them can be shifted if reason arises) for 5.4:

- starting now - nominate features for 5.4 (see 
https://wiki.php.net/todo/php54),
discussion on them
- May 18 - start voting and debating on features that have no clear consensus
support immediately. On the end of May is also phptek, so we could have some
discussion there about it if needed.
- June 15 (a bit more than a month) - alpha, branching of 5_4, open only for
bugfixes and features in TODO list that are approved and can be done by beta
time.
- July 20 - beta, bugfixes only (if we add a lot of features, we may want to 
insert
another 1-month alpha period, so far it doesn't look like it but may change)
- Aug 24 - RC1, then an RC every 2 weeks until stable
- Release - somewhere in October or November, depending on the RCs.

I think we need to start moving. Not much is happening in 5.4 now as far as I 
can
see, and we have a good feature set that is long due to be released.

Stas, in the past we had alphas. Is there any reason why we wouldn't roll one 
out asap? (revert the typehints stuff and go).

I think we (almost) all agree that we need to start pushing PHP 5.4 with all 
the goodness that has been developed to-date. Additional features can wait 
for the next version.
Any exceptions that are low risk can be evaluated (an additional minor API, 
some additional enhancements) but let's get the good work that has been done 
to-date out there vs. allowing feature creep and pushing the timeline for 
another 1-2 years. I think we should start pushing out alpha in parallel to 
these discussions. Most of them sound like major features which would not make 
PHP 5.4 as any major feature requires plenty of time to mature (and needless to 
say some of them won't even be accepted).

There is plenty to get excited about in PHP 5.4!

Andi (sending in plaintext. Hope this gets rid of the funky newlines from prior 
emails)

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

RE: [PHP-DEV] 5.4 again

[Andi Gutmans]

 -Original Message-

 From: Stas Malyshev [mailto:smalys...@sugarcrm.com]

 Sent: Sunday, May 08, 2011 4:41 PM

 To: PHP Internals

 Subject: [PHP-DEV] 5.4 again



 Hi!



 I has been almost a month since we did our routine talk about 5.4, so here it

 goes again. The patch for the scalar hints seems to be pretty simple (see

 http://random-bits-of.info/no_scalar_hints.diff - no generated files included,

 that will be done on actual commit), so it should not hold us too much.

 I propose putting current code in a branch and continue without scalar typing

 for 5.4 - any objections to that?



-snip-

 I think we need to start moving. Not much is happening in 5.4 now as far as I

 can see, and we have a good feature set that is long due to be released.

 For proposing stuff for 5.4, please do it here:

 https://wiki.php.net/todo/php54 and also on the list if it wasn't discussed 
 and

 you think it requires discussion.



As I've already pointed out, I am all in favor of starting to run the release 
process.

I do think we should focus on getting out there what we have now (with some 
tweaks) and not trying to do major new features or we will by definition not be 
entering a release process. The richer our language (and the more mature and 
broad our base) the more we have to be concerned with feature creep.



- On performance  memory consumption - as already mentioned, huge 
improvements! We may be able to do more but will stay within the release 
timeline if we make any further improvements.

- On square bracket shortcut I was always in favor of (b) in 
http://marc.info/?l=php-internalsm=11385524494w=2. If this is what we're 
talking about I personally feel it's an easy one.

- Agree type hints goes out.



Go!!

Andi

RE: [PHP-DEV] annotations again

[Andi Gutmans]

 -Original Message-
 From: Marcelo Gornstein [mailto:marce...@gmail.com]
 Sent: Monday, May 09, 2011 10:20 AM
 To: Stas Malyshev
 Cc: guilhermebla...@gmail.com; PHP Internals
 Subject: Re: [PHP-DEV] annotations again
 
 mm i don't remember saying anything like that :) i dont want to start an
 argument here, but maybe you'd like to take things less personal and re-read
 my post.
 
 anyway, i think it's time to stop just saying no, and really collaborate 
 with
 what the community is suggesting (and already
 propsed) in order to bring this into php (5.4 or whatever).

I absolutely agree we should be getting input from the various communities 
whether that's ZF, Symphony, Drupal, etc.. I do feel we get quite a bit of if 
it's not enough it should keep coming with very clear proposals. It'd also help 
if the frameworks would collaborate on such proposals. I know our ZF team has 
collaborated with other framework teams on a variety of fronts.
I do think this group does take clear proposals seriously but it's also 
important to remember that there has to be a strong bias to avoid feature creep 
and really focus on what's critical and not nice-to-have.
There are proposals that come up time and time again like operator overloading 
which just makes me cringe...

Andi

RE: [PHP-DEV] 5.4 again

[Andi Gutmans]

 -Original Message-

 From: Christopher Jones [mailto:christopher.jo...@oracle.com]

 Sent: Monday, May 09, 2011 10:28 AM

 To: internals@lists.php.net; Guilherme Blanco

 Subject: Re: [PHP-DEV] 5.4 again







 On 05/09/2011 07:44 AM, 
 guilhermebla...@gmail.commailto:guilhermebla...@gmail.com wrote:



  It seems to me that you are not interested on user's request and

  rather accept/implement only what the features that interest you. It's

  very bad for the language and very bad for all of users.



 Rasmus  Stas have already pointed out this is not valid and lots of user

 requests are implemented.



 I'd add that PHP has never had a lot of spare developer capacity.

 Programmers are not idly sitting around, waiting for random ideas to code

 up.  If you feel strongly about a feature you have to convince the core

 contributors of its merits and (i) pique the interest of someone capable of

 implementing it and then help with testing and documentation, or (ii)

 implement it all yourself.



 It's easier than ever to get an SVN account, so contributing would be a good

 way to get karma.



I agree but also want to emphasize that just because there’s a patch it doesn’t 
mean it’s a good idea and should be accepted.

Of course like Chris points out it’ll significantly increase the chances of 
people taking it seriously and playing around with the idea.



I also think Matthew makes a good point – annotations can be viewed in 
different ways and arguably there are already quite a lot of possibilities with 
what exists today.



Andi

RE: [PHP-DEV] 5.4 again

[Andi Gutmans]

-Original Message-

From: guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com]

Sent: Monday, May 09, 2011 10:51 AM

To: Andi Gutmans

Cc: Christopher Jones; internals@lists.php.net

Subject: Re: [PHP-DEV] 5.4 again



Hi Andi,



That's all I want.

Someone to at least look at the patch and give me feedback.

None here did that, all you're doing is telling no, we don't accept it.



Why don't you give me some valuable feedback so I can work on the patch to

turn it relevant to you?



I think more important than the patch is the actual functionality. Patch can 
always be fixed.

I assume the latest RFC is https://wiki.php.net/rfc/annotations?



I will take a bit of a longer look at it in the coming days but from looking at 
it quickly I can see why some people may not be very excited about it. I 
personally have never been a huge fan of meta-data whether in the code or 
outside the code. The biggest scars I carry are from J2EE. I feel annotations 
are sometimes just a nicer way of creating similar problems (hard to understand 
flow, hard to debug, etc…). I do realize there are also some benefits but as 
Matthew pointed out the question is are those benefits enough to warrant a 
whole new grammar in the language or do we keep it lighter weight and let 
people build on that (which with the right caching should not be too hard).

Anyway, I will take a longer look.



Andi (hoping I don’t get extra newlines this time around. My apologies but for 
some reason my mail client doesn’t like internals@ in the past two weeks).

RE: [PHP-DEV] Releases, trunk, policy and the wardrobe (Was: Re: [PHP-DEV] RFC: built-in web server in CLI.)

[Andi Gutmans]

 -Original Message-

 From: a...@adamharvey.name [mailto:a...@adamharvey.name] On Behalf

 Of Adam Harvey

 Sent: Monday, April 18, 2011 8:26 AM

 To: internals Mailing List



 Is there any thought that we might stop throwing things into trunk soon and

 start thinking about some sort of release?



 5.3.0 came out in June 2009. Even if we start the alpha process now, there's 
 no

 chance trunk is going to hit stable until the last few months of the year, so

 we're looking at over two years between minor releases, which is about as long

 as I'd be comfortable leaving it — not just for any PR reason, but because

 there's some genuinely good stuff in trunk that I think deserves to see the 
 light

 of day.



I completely agree.



The current PHP 5.4 source tree (a.k.a. trunk) already has *major* 
enhancements. Just look at the NEWS file.

I think it's a mistake we don't start a release cycle. If we try and get too 
much into this release it just won't happen.



The typehint stuff which has no consensus should be reverted and we should 
start pushing forward with a release. Things which people wanted to get done 
and didn’t (e.g. Pierre asked for another 3-4 weeks to do some more Windows 
work (about 4-5 months ago which I don’t know if ever happened) should not slow 
down a release and be marked as nice-to-have – if it doesn’t make the train it 
can wait for the next version; if they do, great.



Btw, just performance and memory use itself is a good enough reason to push a 
minor release and every day that goes by where we prevent people from getting 
their hands on it is a day we're warming up the planet faster. This is between 
16-20% faster and on average 30% lower memory usage (the latter is the more 
exciting change thanks to a lot of memory optimization we did; with a release 
cycle started and people testing/comparing we may be able to squeeze even more 
out of it). I’d also like to see some of the work around making mbstring a 
configurable option out sooner rather than later…



My 2 cents. We can work closely with an RM to move things forward and ensure we 
push out a lot of the really good stuff that was done.



Andi

RE: [PHP-DEV] RFC: built-in web server in CLI.

[Andi Gutmans]

I really like the idea.

Just to be clear though I'd change:
Server is listening on localhost:8000... Press CTRL-C to quit.
To something like:
PHP Development Server is listening on localhost:8000... Press CTRL-C to quit.

I think that makes it very clear this is for development and enhancements will 
be focused on ensuring the dev environment works and not trying to make this 
into a mini Apache.

Andi

 -Original Message-
 From: Richard Quadling [mailto:rquadl...@gmail.com]
 Sent: Sunday, April 17, 2011 1:29 PM
 To: Mikael Fernandus S
 Cc: Philip Olson; Moriyoshi Koizumi; Christopher Jones; internals Mailing List
 Subject: Re: [PHP-DEV] RFC: built-in web server in CLI.
 
 On 17 April 2011 15:51, Mikael Fernandus S mika...@gmail.com wrote:
  As a non core dev, I would like to say that the patches are so handy
  and this feature will be so helpful in portable php development
  scenarios.
  +1 on this and hoping it will make into the main branch pretty soon.
 
  Similar with others, my suggestion is to put the docroot and router
  script as parts of the options. An option to specify max number of
  connections would be nice but perhaps it can be in a future wishlist.
 
  Regards,
  Mike
 
  On Sun, Apr 17, 2011 at 8:17 AM, Philip Olson phi...@roshambo.org wrote:
  Greetings Moriyoshi and all,
 
  Are people still thinking about this? And how about applying the
 current/revised patch to trunk thus making it easier to play with and break, 
 but
 not freeze its features/API yet.
 
  Also the wiki is up again so:
 
   - RFC: https://wiki.php.net/rfc/builtinwebserver
   - Patch is here: http://gist.github.com/835698
 
  Regards,
  Philip
 
 
 What would happen if you could combine these patches with the Win32Service
 pecl extension ... could you not have a real PHP orientated web server running
 which was capable of starting up and shutting down with the OS.
 
 Hey! Who would need IIS or Apache then! (OK. Just kidding).
 
 --
 Richard Quadling
 Twitter : EE : Zend
 @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
 
 --
 PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
 http://www.php.net/unsub.php

RE: [PHP-DEV] PHP for embedded device: reduce size

[Andi Gutmans]

HI Martin,

Is it only file size you worry about or also memory footprint? I assume it'd 
also be the latter.
If so, we can share a patch we've worked on which could allow you to reduce the 
memory footprint at compile time somewhat more (on the expense of performance, 
...).
We were going to send it out for review anyway so this could be it :)

Andi

-Original Message-
From: martin.herr...@gmail.com [mailto:martin.herr...@gmail.com] On Behalf Of 
Martin Herrman
Sent: Saturday, February 19, 2011 10:25 AM
To: internals@lists.php.net
Subject: [PHP-DEV] PHP for embedded device: reduce size

All,

I have cross-compiled php-cgi for a MIPS device (mediaplayer), but the binary 
is quite large, more than 3MB. I'm using:

./configure --prefix=../result/php-5.3.5 --host=i686-pc-linux-gnu 
--target=mipsel-linux-gnu --build=mipsel-linux-gnu --enable-cgi --disable-all 
--without-pear --with-config-file-path=/etc/

Which options do I have to reduce size of the binary? E.g. can I remove the 
zend engine?

Thanks in advance,

Martin

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


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

RE: [PHP-DEV] RFC - MACRO

[Andi Gutmans]

 -Original Message-
 From: Mathias Grimm [mailto:mathiasgr...@gmail.com]
 Sent: Wednesday, December 22, 2010 9:12 AM
 To: internals@lists.php.net
 Subject: [PHP-DEV] RFC - MACRO
 
 I want to request a C/C++ feature that i think is good.
 
 MACRO
 
 ?php
 MACRO('PF','private function _');
 MACRO('SCOPE_CLASS','class MyProject_');
 
 class UseMacro
 {
 PF preSave($object)
 {
//...
 }
 
 }
 
 SCOPE_CLASS Internal
 {
 
 }
 
 I don know if there is a RFC for this feature.

Although I am a C developer and use macros I think it'd be horrible to add them 
to PHP (+ it's been discussed and rejected many times in the past).

Macros make it very hard for a third party person to read your code + goes 
directly against the verbosity spirit we've always had in the PHP project. 
Forget also the fact that it creates a lot of problems with solutions such as 
debuggers.

I suggest if it's something you really feel you need then implement it 
externally to PHP as part of your build and deployment environment. There are a 
variety of templating/pre-processor solutions out there including the 
C-compiler tools themselves.

Andi

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

RE: [PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())

[Andi Gutmans]

It's nice but as long as the browsers don't implement it natively then it's 
less useful for server to client communication.
Of course can still be quite useful with custom I/O or data sources that 
implement it natively i.e. mongodb.

 -Original Message-
 From: Ilia Alshanetsky [mailto:i...@prohost.org]
 Sent: Thursday, November 25, 2010 4:16 PM
 To: Pierre Joye
 Cc: Jonah H. Harris; Andi Gutmans; internals@lists.php.net
 Subject: Re: [PHP-DEV] Performance of buffer based functionality (JSON, AES,
 serialize())
 
 Just read over the BSON spec, looks fairly interesting, the only bit that 
 appears
 to be missing for PHP purposes is object support. We would need to introduce
 custom type on top of standard BSON. However from compactness and
 consistency standpoint it looks fairly appealing.
 
 On Thu, Nov 25, 2010 at 2:51 PM, Pierre Joye pierre@gmail.com wrote:
  On Thu, Nov 25, 2010 at 8:47 PM, Jonah H. Harris jonah.har...@gmail.com
 wrote:
  On Thu, Nov 25, 2010 at 2:14 PM, Pierre Joye pierre@gmail.com
 wrote:
 
  For the record here, igbinary is a very good example of such optimization:
 
  http://opensource.dynamoid.com/
 
  igbinary is a nice extension indeed.  However, for those of us who
  have environments which include multiple programming languages,
  custom serializations become a PITA.  As such, we generally go with
  something more portable such as Avro or straight JSON.  Awhile back,
  I had done some work rewriting the JSON serialization functions to
  use the fast (and BSD
  licensed) yajl JSON parser (https://github.com/lloyd/yajl).  Initial
  benchmarks showed a 4-7% performance improvement in
  serialization/deserialization.
 
  Good point indeed. That makes me think about bson
  (http://bsonspec.org/), which is used by mongodb for example.
 
  --
  Pierre
 
  @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
 
  --
  PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
  visit: http://www.php.net/unsub.php
 
 

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

RE: [PHP-DEV] Re: Hold off 5.4

[Andi Gutmans]

 -Original Message-
 From: Jani Taskinen [mailto:jani.taski...@iki.fi]
 Sent: Thursday, November 25, 2010 12:25 AM
 To: da...@php.net
 Cc: PHP Internals
 Subject: Re: [PHP-DEV] Re: Hold off 5.4
 
 Who says it has to be 5.4? People seem to be a bit fixated on the version 
 there.
 Major BC breaks just means the version released from trunk is 6.0. And it's 
 just
 a number. Big number, but still just a number.
 
 Merging (by and or by magic :) features into branch created from 5.3 just
 sounds like plane crash waiting to happen..

I agree and I don't think we're in as bad shape although there's some cleaning 
up that needs to be done.
For what it's worth the changes we've made in the Zend Engine around 
performance and memory use could warrant a major version. Every major version 
of PHP in the past has been driven foremost by major engine overhauls. I 
believe there's quite a bit more that we can do during the pre-beta phase in 
these areas to strengthen that and those changes with a combination of traits, 
some cleanup of deprecated e.g. safe_mode could warrant a major new version.
If we do go down that route I would advocate calling it PHP 7 and not PHP 6, 
not because I like jumping ahead so far (I don't like I am sure most people 
here don't) but we don't want people to search for PHP 6 and find past 
information which is not relevant to this version we release. Then again I can 
live with it either way but we should be aware of the negative implications 
there could be.

Andi

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

RE: [PHP-DEV] Re: Hold off 5.4

[Andi Gutmans]

 -Original Message-
 From: Johannes Schlüter [mailto:johan...@schlueters.de]
 Sent: Thursday, November 25, 2010 9:21 AM
 To: Andi Gutmans
 Cc: Jani Taskinen; da...@php.net; PHP Internals
 Subject: RE: [PHP-DEV] Re: Hold off 5.4
 
 On Thu, 2010-11-25 at 17:11 +, Andi Gutmans wrote:
  For what it's worth the changes we've made in the Zend Engine around
  performance and memory use could warrant a major version. Every major
  version of PHP in the past has been driven foremost by major engine
  overhauls.
 
 Yes, larger changes to the engine changed the major number. But all of them
 had a big effect. This is only performance. No functionality. 90% of the 
 users
 won't notice it. Whereas everbody oticed the change from3 to 4 or the new
 object model in 5. Changing the major number has two big
 effects: a) marketing b) more fear for doing the upgrade.
 
 I value b) as the more relevant factor to monitor.

I agree it is border line. I didn't say I feel strongly about it but I also 
wouldn't dismiss the changes we are making in PHP-next both from a core runtime 
point of view, backwards compatibility + new functionality as a minor version. 
As technologies mature new major versions are often a bit more balanced which 
makes sense given we have such a huge user base. This is no different in the 
Java world, C++ as it matured or some other technologies.

From a core runtime point of view I think the changes are actually quite far 
reaching. I also believe there's more that we can do and want to try and do.

From a BC point of view I do think it's an opportunity to clean up quite a bit. 
I am not an advocate of going crazy but I think we've already identified a few 
areas as a group that we feel comfortable with that strike a good balance 
between BC and helping move things forward. I think these are major version 
changes not minor version changes.

From a functionality point of view I actually think there's some good 
functionality here:
- Traits (I think this is major)
- Some additional language improvements around array dereferencing, 
configurable mbstring support at runtime (we still need to do some work there), 
closure enhancements, ...
- Some major and minor improvements in modules such as FastCGI, JSON, hashing, 
...

I think this is definitely more than minor version. I agree it may feel 
somewhat light as a major version but there is no such thing as a manor version 
:)

In the spirit of release early and often I would actually gravitate towards the 
major version and start with clean slate although I also understand the other 
side of the world. In this scenario I would not use the excuse of a major 
version to go crazy though. Keep it sane and similar to what we're discussing 
now with maybe some additional engine improvements, additional cleanup and some 
extension work that can probably still be done. It has to be extremely finite 
(short list) and managed in a good release process. I do think if we continue 
to do major minor versions like we've done in the 5.x branch we will probably 
stay in the 5.x branch perpetually and it could be confusing to our users when 
they get major BC breaks and changes within the same major version.

Andi 

RE: [PHP-DEV] Re: Hold off 5.4

[Andi Gutmans]

 -Original Message-
 From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
 Sent: Thursday, November 25, 2010 9:27 AM
 To: Johannes Schlüter
 Cc: Andi Gutmans; Jani Taskinen; da...@php.net; PHP Internals
 Subject: Re: [PHP-DEV] Re: Hold off 5.4
 
 Looking through trunk I think we are in pretty good shape.  I don't think 
 cherry-
 picking and branch merging is an issue at this point.  A
 5.4 with the performance improvements, Traits, minus the type hinting
 breakage is something we can get out pretty quickly without causing any sort 
 of
 PHP 6 confusion or breaking existing apps.


Btw, just to be clear I am also OK with this approach. I just wanted to make 
sure we consider the pros/cons of doing minor vs. major so we're all aligned 
re: the implications :)  I would pass on any type hinting patch because there's 
no consensus and if we rip it out we are pretty much set to go (and I do not 
see a major negative implication of taking it out). Less is more IMO and it 
will enable us to get good functionality out sooner. We will probably make some 
more engine enhancements during pre-beta but can freeze at any point in time.

Andi

[PHP-DEV] Performance of buffer based functionality (JSON, AES, serialize())

[Andi Gutmans]

Hi,

Completely different topic :)

I've been looking a bit into performance around json encoding, 
hashing+encryption (aes) and serialize()/unserialize(). Data that is marshaled 
and often transmitted over the wire.

I know there have been some high-end apps that have benefited from some custom 
serializers, etc... (typically platform dependent).
I wonder if people here think improvements in these areas would move the needle 
for the majority of mainstream apps or not.

Thanks,

Andi

RE: [PHP-DEV] Re: Hold off 5.4

[Andi Gutmans]

 -Original Message-
 From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
 Sent: Thursday, November 25, 2010 10:26 AM
 To: Ilia Alshanetsky
 Cc: Johannes Schlüter; Andi Gutmans; Jani Taskinen; da...@php.net; PHP
 Internals
 Subject: Re: [PHP-DEV] Re: Hold off 5.4
 
 We also need that non-null zend_parse_parameters type implemented to clean
 up the null-byte poisoning fixes in 5.3.  I can't see this slowing us down 
 much as
 it is pretty trivial.  Just takes someone to sit down for a couple of hours 
 and
 implementing it and finding all the places where parameters end up in paths.
 There are probably other places we don't want nulls either that currently have
 local checks that can be removed.

Yes I agree. We may be able to skip this check for interned strings which would 
be nice and potentially eliminate performance impact somewhat but it's 
something that would need to be looked into. It's non-trivial but doable (need 
to add a flag for interned strings whether they have a zero byte or not).

Andi

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

RE: [PHP-DEV] Re: Hold off 5.4

[Andi Gutmans]

 -Original Message-
 From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
 Sent: Thursday, November 25, 2010 10:46 AM
 To: Andi Gutmans
 Cc: Ilia Alshanetsky; Johannes Schlüter; da...@php.net; PHP Internals
 Subject: Re: [PHP-DEV] Re: Hold off 5.4
 
  Yes I agree. We may be able to skip this check for interned strings which
 would be nice and potentially eliminate performance impact somewhat but it's
 something that would need to be looked into. It's non-trivial but doable 
 (need to
 add a flag for interned strings whether they have a zero byte or not).
 
 I'm not too worried about the performance impact here.  Functions that need
 these non-null strings need them because they are about to access the file
 system in some way.  The time it takes to check for nulls compared to the file
 system access time is so small that I think we can safely ignore performance
 issues.

Yes I thought about that too after I sent the email :) It is negligible 
compared to the expensive filesystem operation.

Andi

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

RE: [PHP-DEV] [RFC] Release Process

[Andi Gutmans]

 -Original Message-
 From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
 Sent: Wednesday, November 24, 2010 9:39 PM
 To: Derick Rethans
 Cc: Felipe Pena; internals
 Subject: Re: [PHP-DEV] [RFC] Release Process
 
 Hi!
 
  With the recent chaos in the way we begin and ended releases, we
  would like to propose a clean way to deal with releases and related
  decisions: [1]
 
  Really? I think you're blowing this all way out of proportion.
 
  I don't mind a yearly release cycle, as we should get out more releases.
  I don't mind a monthly release cycle for .z releases.
 
 I think the idea is not focusing on yearly or monthly but having some
 predictable schedule. Nobody says it should be set in stone, let's be 
 realistic
 here - if we need to slip a release here and there, we'd do it. But having 
 known
 targets is the goal, not having releases whenever somebody on the list wakes
 up and decides to have a release. I think the project needs to grow up a bit 
 and
 have at least some semblance of release schedule. The mere existence of it
 written somewhere public would motivate people to adhere to it.

I agree with that. More structure and predictability will be very valuable to 
the project. We created a lot of structure in Zend Framework and it has really 
paid off.
Btw, we don't have to look far. Just the change in having people document their 
suggestions via RFCs already had a substantial impact on this project both in 
terms of peer review and having a long lasting trail of what made it into a 
given release.
More structure will typically yield in higher quality, more visibility and 
therefore more motivation for people to contribute, and I believe also in more 
deliverables rather than less as people will work towards clear goals + be 
accepting if they miss them and they need to wait for the next release train.

Andi

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

RE: [PHP-DEV] git anyone?

[Andi Gutmans]

 -Original Message-
 From: Pierre Joye [mailto:pierre@gmail.com]
 Sent: Wednesday, November 24, 2010 5:47 PM
 To: PHP internals
 Subject: [PHP-DEV] git anyone?
 
 hi,
 
 We have moved not too long ago and for what I see it gave some opportunities
 to many of us to see what are the other tools on the market, git and github in
 particular. I think 99% of the active developers here are on github or use 
 git in
 one way or another.
 
 I think git could be a great help, maintaining multiple branches will be 
 easier. It
 will also be very useful to develop new complex features requiring a longer
 development period. SVN works fine but merging is very limited and buggy,
 maintaining a branch while syncing changes from trunk/other branches is a
 very frustrating experiences.
 
 Please not I'm not requesting to do it now and here, only trying to get a
 feeling/poll about git usage.

I personally doubt moving will have a material positive impact on the project. 
I wouldn't particularly mind if all the issues were addressed but I wouldn't 
hold my breath that it will be game changing. It may be better to invest the 
effort elsewhere.

Andi
 


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

RE: [PHP-DEV] Adding path_len to all stream functions in trunk

[Andi Gutmans]

 -Original Message-
 From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
 Sent: Monday, November 15, 2010 8:21 PM
 To: Rasmus Lerdorf
 Cc: internals
 Subject: Re: [PHP-DEV] Adding path_len to all stream functions in trunk
 
 Hi!
 
  Ok, I went through all the 5.3 code.  This should fix the null
  poisoning problems in 5.3 without breaking binary compatibility:
 
  http://progphp.com/nullpatch.txt
 
 Looking at this patch, I wonder if it wouldn't be cleaner to add new type 
 (string
 without nulls) in parameter parsing and have it handled by parameter parsing
 in one place instead of doing it in dozens of different places? There might be
 some other places not covered but it would cover most functions - and it's
 easier to catch/fix those in extensions.

That's a nice idea and it also wouldn't break binary compatibility.

Andi


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

RE: [PHP-DEV] Adding path_len to all stream functions in trunk

[Andi Gutmans]

 -Original Message-
 From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
 Sent: Monday, November 15, 2010 9:25 PM
 To: Andi Gutmans
 Cc: Stas Malyshev; internals
 Subject: Re: [PHP-DEV] Adding path_len to all stream functions in trunk
 
 Well, it changes the signature of that function, so while we don't break
 backward binary compatibility, we break forward compatibility within the
 5.3 branch.  As in, if I change my extension to use this new NoNull string 
 flag, it
 will no longer work on 5.3.3 whereas if I do the
 if(strlen(filename) != filename_len) check, this will still work in all
 5.3 releases.

Yes that's correct although I am not sure of chances people would bump into 
this issue.
In any case, I think it's also fine to fix it the way you suggest in 5.3.x and 
then do it via API in the next minor/major version.



Andi

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

RE: [PHP-DEV] Adding path_len to all stream functions in trunk

[Andi Gutmans]

Hi Rasmus,

Hope I understood the problem correctly. If not, this answer won't make sense :)
I do not see a major problem in passing path_len but wonder how much it'd 
actually solve as we end up calling OS APIs that do not accept path_len, no? I 
assume we don't want to start searching all these strings for invalid chars 
before we pass them to the OS.

Andi

 -Original Message-
 From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
 Sent: Sunday, November 14, 2010 11:54 AM
 To: internals
 Subject: [PHP-DEV] Adding path_len to all stream functions in trunk
 
 I think we need to pass along the string length to all the stream functions to
 maintain binary string safety through this code.  This would fix annoying
 problems like http://bugs.php.net/39863 and a bunch of similar issues.
 Obviously not something we can do in 5.3 without breaking binary compatibility
 though.  Although we might be able to do something if we assume only chars
 valid in the current charset is valid in file paths.
 
 Anybody have any other thoughts on this one?
 
 -Rasmus
 
 --
 PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
 http://www.php.net/unsub.php


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

RE: [PHP-DEV] GPU Acceleration

[Andi Gutmans]

 -Original Message-
 From: Scott MacVicar [mailto:sc...@macvicar.net]
 Sent: Friday, November 12, 2010 8:22 AM
 To: Stefan Marr
 Cc: Kenan Sulayman; PHP internals
 Subject: Re: [PHP-DEV] GPU Acceleration
 
  What's not constructive about it? Seems pretty constructive to me. The 
  original
 poster has done research into the issue already.

What research are you referring to? I must have missed that.
There's no magic with GPUs. There are good reasons why few 
applications/infrastructure components use them. GPUs can be useful for very 
specific workloads but not necessarily general purpose app server.
Btw there are also some workloads that could benefit from leveraging some of 
the x86 extensions around encryption, vector computation, ...
So it boils down to being more specific re: where you think it could benefit 
and why.
Andi
 
 The reason most things don't exist is that no one has a patch for it. If it 
 doesn't
 core in core then it heads into a PECL module or lives as a patch on some 
 site.


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

RE: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Andi Gutmans]

The first google entry when you search for it gives you the answer. It is 
actually unbelievably easy to find the answer via search. If a new PHP 
developer can't find it then maybe they shouldn't be writing code.

This is a piece of history from the PHP 3 days and think it adds some 
character, a story (and history) to PHP. Don't think we should take this out 
after a good 12 years.

I would prefer this was not changed.

Andi

 -Original Message-
 From: admin [mailto:ad...@codeangel.org]
 Sent: Friday, October 29, 2010 5:47 PM
 To: internals php list
 Subject: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to
 T_DOUBLE_COLON
 
 WTF is T_PAAMAYIM_NEKUDOTAYIM?
 
 This has to be THE most asked question by new php developers when they
 come across it.  Can we please change the token name to T_DOUBLE_COLON
 so I don't have to hear about it constantly?
 
 Those that disagree don't do enough PHP support to know how often it is
 asked. it's worth it.
 
 Chad
 
 --
 PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
 http://www.php.net/unsub.php


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

RE: [PHP-DEV] Strict typing (was: Typehints)

[Andi Gutmans]

 -Original Message-
 From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org]
 Sent: Wednesday, August 11, 2010 5:19 AM
 To: rquadl...@googlemail.com
 Cc: Zeev Suraski; Ilia Alshanetsky; Stas Malyshev; Johannes Schlüter; Kalle
 Sommer Nielsen; Internals; Derick Rethans
 Subject: Re: [PHP-DEV] Strict typing (was: Typehints)
 
 
 On 11.08.2010, at 14:14, Richard Quadling wrote:
 
  So, the trunk keeps strict typing.
  
 no .. a controversial patch like this should never have gotten into trunk
 without a vote. the only place for this patch in the svn.php.net repo would be
 a feature branch.

I completely agree. I don't know how this patch sneaked in and there clearly is 
a vast majority against it. We have discussed several times over the years on 
why such strict type hinting does not make sense for PHP.

Andi


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

RE: [PHP-DEV] Strict typing (was: Typehints)

[Andi Gutmans]

I wouldn't mind living with neither but I think it's two separate discussions.

 -Original Message-
 From: Ilia Alshanetsky [mailto:i...@prohost.org]
 Sent: Wednesday, August 11, 2010 3:52 AM
 To: Zeev Suraski
 Cc: Stas Malyshev; Johannes Schlüter; Kalle Sommer Nielsen; Internals;
 Derick Rethans
 Subject: Re: [PHP-DEV] Strict typing (was: Typehints)
 
 I think that weak type-hinting defeats the whole purpose of the feature and I
 would rather not have it than have a non-obvious implementation.
 
 -1
 
 On Wed, Aug 11, 2010 at 2:03 AM, Zeev Suraski z...@zend.com wrote:
  At 01:47 11/08/2010, Stas Malyshev wrote:
 
  Hi!
 
  For the record: I consider the current implementation as (one of)
  the biggest mistakes in the last ten years.
 
  I agree completely. The fact that obvious absence of consensus is
  ignored and we are releasing feature that clearly has no consensus
  behind it as a part of an official release - when we have killed much
  lesser things for much lesser reasons - I think it is a very bad 
  development.
 
  I agree completely too.
 
  We've also had quite a lengthy discussion on this topic, and there was
  more support for 'weak' typing then there was for strict typing.
 
  The response to Johannes's blog also don't leave much room for
  speculation regarding what the community at large thinks.
 
  Facts:
  - When we introduced type hints, one of the 'conditions' were that
  we'll never, ever have type hints for scalars - for many different
  reasons - the strongest of which it simply doesn't fit PHP's theme.
  - We managed to come up with an alternative solution, in the form of
  auto-converting type hints for scalars, which does in fact fit PHP's
  theme perfectly.
  - I suggested we actually take the opportunity to slightly modify
  PHP's conversion rules in esoteric cases, where our historical
  decision is probably not the right one (e.g., silently converting
  abc into 0 in case of integer context - instead emit a new E_TYPE
  warning that would be off by default).
 
  My view in terms of preferences:
  #1 - Auto-converting type hints + minor changes to PHP's conversion
  rules
  #2 - Auto-converting type hints
  #3 - Doing nothing
  #inf - Introducing strict typing into PHP (current trunk status)
 
  As Stas said - there's clearly anything but consensus around strict
  typing, so our 'default' in case we can't reach agreement is #3 - the status
 quo.
   As everyone told me when this feature was committed to trunk - it
  doesn't mean anything, it's just trunk.  Let's stand behind that
  statement and revert it.
 
  Strict typing should go away before any 'official' package comes out
  of php.net.
 
  Zeev
 
  --
  PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
  visit: http://www.php.net/unsub.php
 
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
 http://www.php.net/unsub.php


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

Re: [PHP-DEV] APC in trunk

[Andi Gutmans]

Can we deduct from that a 6 version number for trunk? :) just kidding
I am also +1 on bundle but not on default. I think we should also reach out to 
other OSS caches to ensure they know they still have a place in our Eco system. 
 Some are preferred by certain use cases.  



On Jun 21, 2010, at 9:31 AM, Sebastian Bergmann s...@sebastian-bergmann.de 
wrote:

 Am 21.06.2010 13:05, schrieb Rob Richards:
 It was already agreed to include it into 6 before so why the need for
 another vote on this just because its a new trunk?
 
 Also eludes me :-)
 
 -- 
 Sebastian BergmannCo-Founder and Principal Consultant
 http://sebastian-bergmann.de/   http://thePHP.cc/
 
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 

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

RE: [PHP-DEV] Type hinting

[Andi Gutmans]

So which RFC should I be reviewing? Does this RFC reflect what Ilia's
patch does? I just want to be sure we are talking about the same thing
and can review and comment on it in detail. We've had many discussions
on this topic over the years and different people had different things
in mind so we need to make sure we have a good structured discussion
(and documented via RFC).

Andi

 -Original Message-
 From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org]
 Sent: Saturday, May 22, 2010 1:39 PM
 To: Josh Davis
 Cc: Zeev Suraski; internals@lists.php.net
 Subject: Re: [PHP-DEV] Type hinting
 
 
 On 22.05.2010, at 18:30, Josh Davis wrote:
 
  As you wrote, you worked on PHP's _type system_ which is dynamic,
  really cool, juggles strings with ints and what not. However, the
  topic here is the _type hinting system_. As far as I know, there's
no
  weak type hinting; if a method signature hints for an array and is
  given an integer, it throws a catchable fatal error. Therefore, as a
  user, what I am familiar to is a strict _type hinting system_.
  Anything else would feel inconsistent to me.
 
 
 can we please just stop calling a something a type hinting system,
which leads
 to a catchable fatal error when the type does not strictly match?
thats a very
 misleading euphemism. its simply strict typing, it has nothing to do
with hinting.
 
 anyway, yes there is a proposal for an actual hinting system as Zeev
has pointed
 out just a few mails early in the thread than yours:
 http://wiki.php.net/rfc/typecheckingstrictandweak
 
 regards,
 Lukas Kahwe Smith
 m...@pooteeweet.org
 
 
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List To unsubscribe,
visit:
 http://www.php.net/unsub.php


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

RE: [PHP-DEV] [RFC] Performance improvements

[Andi Gutmans]

Benjamin,

Thanks for testing and sharing the data. These are great results and validate 
the progress made.
Glad to see you're also seeing the improved memory usage which means that the 
runtime is not only faster but you can typically run more concurrent PHP 
instances.

Andi

 -Original Message-
 From: Benjamin Eberlei [mailto:kont...@beberlei.de]
 Sent: Thursday, April 29, 2010 3:08 AM
 To: internals@lists.php.net; r.borsc...@gmx.net
 Subject: Re: [PHP-DEV] [RFC] Performance improvements
 
 
 We wanted to share some of our insights on the performance patches.
 
 Roman did some tests on the Doctrine 2 performance testsuite to check the
 benefits of the performance improvements and they are pretty impressive
 (Thanks Dimitry!).
 
 Our performance testsuite containts pretty intense and heavy PHP looping,
 array and string crunching tests with very few to none calls to external 
 libraries
 using a mocked database along the lines of how long does php take to
 transform 1 database rows into an object structure.
 
 See his mail initially sent to the doctrine-dev list:
 
 Hi,
 
 I already shared this info with some of the core developers but thought it 
 might
 be of interest to anyone subscribed to this group.
 
 I just wanted to share some results I got with testing out the new performance
 improvements committed to PHP trunk recently.
 
 See: http://wiki.php.net/rfc/performanceimprovements
 
 I don't know whether all improvements mentioned in the Wiki have been
 committed yet, at least interned strings seem to be committed, but the results
 are already pretty good:
 
 Running: Doctrine/Tests/ORM/Performance/AllTests.php
 
 ; PHP 5.3.3-dev (SQLite in-memory) snapshot
 
 testSimpleQueryScalarHydrationPerformance1Rows - 0.19897103309631
 seconds .testSimpleQueryArrayHydrationPerformance1Rows -
 0.39269518852234 seconds
 .testMixedQueryFetchJoinArrayHydrationPerformance1Rows -
 0.85220384597778 seconds
 .testSimpleQueryPartialObjectHydrationPerformance1Rows -
 0.74572706222534 seconds
 .testSimpleQueryFullObjectHydrationPerformance1Rows -
 2.8694489002228 seconds
 .testMixedQueryFetchJoinPartialObjectHydrationPerformance2000Rows -
 0.32160806655884 seconds
 .testMixedQueryFetchJoinFullObjectHydrationPerformance2000Rows -
 0.61252403259277 seconds
 . Inserted 1 objects in 3.828871011734 seconds
 
 ; PHP trunk (SQLite in-memory) snapshot
 
 testSimpleQueryScalarHydrationPerformance1Rows - 0.16227412223816
 seconds .testSimpleQueryArrayHydrationPerformance1Rows -
 0.27942895889282 seconds
 .testMixedQueryFetchJoinArrayHydrationPerformance1Rows -
 0.60481095314026 seconds
 .testSimpleQueryPartialObjectHydrationPerformance1Rows -
 0.58688807487488 seconds
 .testSimpleQueryFullObjectHydrationPerformance1Rows -
 2.249853849411 seconds
 .testMixedQueryFetchJoinPartialObjectHydrationPerformance2000Rows -
 0.24576616287231 seconds
 .testMixedQueryFetchJoinFullObjectHydrationPerformance2000Rows -
 0.46355390548706 seconds
 . Inserted 1 objects in 2.773432970047 seconds
 
 The whole test suite runs noticeably faster, I would think at least 30-40%.
 
 Memory usage of the complete suite goes down by 10MB (32bit system):
 
 5.3.3-dev: 39 MB
 5.x trunk: 29.5 MB
 
 On Tue, 20 Apr 2010 15:29:21 +0400, Dmitry Stogov dmi...@zend.com
 wrote:
  Jordi Boggiano wrote:
  On 20.04.2010 12:41, Derick Rethans wrote:
  You're writing that the ZEND_CATCH opcode has to be used with a
  constant class name, so how would catch ( self $e ) be
  represented in op-codes now?
  I dropped such possibility. Does someone use it?
  For me it looks useless. If it's really necessary I can try not to
  drop it.
  You have a point, it looks quite useless. But of course, I am sure
  somebody has used this :)
 
  FWIW, Google Code Search returns no such thing as far as I could see,
 it
  obviously doesn't mean it doesn't exist, but if it triggers a parse
  error or something clear enough to the eventual unlucky guy that did
 use
  it, I guess it might be an acceptable BC break.
 
  Of course
 
  $ sapi/cli/php -n -r 'try {} catch (self $e) {}'
 
  Fatal error: Bad class name in the catch statement in Command line
  code on line 1
 
  Thanks. Dmitry.
 
  Cheers,
  Jordi
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
 http://www.php.net/unsub.php

RE: [PHP-DEV] trunk is alive and open

[Andi Gutmans]

 -Original Message-
 From: Johannes Schlüter [mailto:johan...@schlueters.de]
 Sent: Tuesday, April 27, 2010 9:40 AM
 To: Pierre Joye
 Cc: Gwynne Raskind; Ilia Alshanetsky; Kalle Sommer Nielsen; Lukas Kahwe
 Smith; Andi Gutmans; Derick Rethans; PHP Developers Mailing List
 Subject: Re: [PHP-DEV] trunk is alive and open
 
 On Tue, 2010-04-27 at 17:46 +0200, Pierre Joye wrote:
  Before even thinking about a planning, we have to define what we want
  in and how we go further.
 
 ACK, I think it makes sense to define some key features we want for the next
 release (traits seem to be one). An issue with 5.3 was that whenever really
 defined that but only said let's backport from 6 and add all stuff coming 
 in. I
 think it makes sense to define a set of key features (traits, what else?) and 
 once
 these are implemented in an accepted way (not meaning stable but having an
 accepted design) make a release branch (either by branching of or locking 
 trunk
 for bigger
 features or whatever) where stability of this is improved else we end up 
 adding
 feature after feature and introducing problem after problem.

As I've mentioned in the past I think we are better off with shorter release 
cycles and less features per cycle. Reduces risk and enables us to push out 
value faster. For example, we have made (and are still making) significant 
performance enhancements to the runtime. It'd be a shame if that waited until 
Q4 for alpha. I think with traits, performance enhancements and a few 
additional changes we already have a pretty substantial version.

Andi

RE: [PHP-DEV] On constructors: BC Break and Class compiler Improvements

[Andi Gutmans]

 -Original Message-
 From: Stanislav Malyshev [mailto:s...@zend.com]
 Sent: Thursday, April 01, 2010 12:34 PM
 To: Pierre Joye
 Cc: Ralph Schindler; internals
 Subject: Re: [PHP-DEV] On constructors: BC Break and Class compiler
 Improvements
 
 Hi!
 
  Well, I think the question here is more about dropping old style
  constructor that case sensitive functions/methods name. I'm in
favour
  of dropping in php-next.
 
 I don't feel comfortable with dropping class-named ctor altogether
(big BC
 issue) but dropping it in NS-classes seems to be easier (technically,
it's NOT
 the same name - the real class name is namespace\class) and would
solve
 99% of the problem without having almost any BC impact.

I agree. I would drop class-named ctors within namespaced classes and
possibly in the next major version also do an E_STRICT for these in
regular classes to try and get people to convert to __construct().
At a time where there's an increased focus on exposing dynamic services
I think the class-named ctors is becoming increasingly problematic.

Andi

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

RE: [PHP-DEV] php and multithreading (additional arguments)

[Andi Gutmans]

Hi,

I think that if we were ever to implement threading we would be best off
to enable spawning worker threads that have their own context with no
shared data (and therefore no requirement for locking). We could then
have a message passing API between the threads.
Advantages:
- Real multi-threading.
- Simple straightforward approach which doesn't require a comp. sci.
degree to use correctly.
- Very stable implementation.

You can tell by this that:
a) I think GIL is not the way to go. It's more complex, not truly
multi-threaded, and implementation may never be 100%.
b) True multi-threading with data sharing in my opinion is a recipe for
disaster. Not only because of the implementation complexities but I
think it makes life very hard for the developer and requires a lot of
sophistication.

So if I'd implement something I'd definitely do true multi-threading
with message passing (we basically already have the infrastructure with
TSRM to support that). Do I think this is a high priority item? Not
really but I can understand that it could add value to some. I think for
some Web requests it could actually allow for some parallel processing
with a rendezvous which could help reduce latency (not overall server
throughput).  Then again, there'd be some overhead for having a
thread-safe build so I don't see this as something that would be enabled
by the masses - at least not initially.

Andi


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

RE: [PHP-DEV] trunk is alive and open

[Andi Gutmans]

 -Original Message-
 From: Derick Rethans [mailto:der...@php.net]
 Sent: Tuesday, March 23, 2010 9:05 AM
 To: PHP Developers Mailing List
 Subject: [PHP-DEV] trunk is alive and open
 
 Hello,
 
 I've just created trunk for 5.3 again. I've set the version to
5.3.99-dev as to
 explicitly not decide on whether there will be 5.4 or
 6.0 next.
 
 New features should go to trunk; but anything other then trivial
additions
 should require an RFC and discussion. I think Antony has the FPM RFC
ready
 to show what sort of stuff would be useful to have. I'll let Antony
start a
 thread to discuss it (although I doubt there needs to be a lot of
discussion for
 it).
 
 I think Ilia mentioned that he wanted to do one more normal 5.2
release,
 after which it will be security fix only. So for now my suggestion
would be:
 
 - new features to to trunk
 - bug fixes go to 5.2 and 5.3.
 
 Let's see what cool stuff we can come up with for the next version!

What about defining a release manager for the next release? I think that
is an important aspect of moving things forward. I also thought the dual
RM in PHP 5.3 worked quite well although it is not necessarily a must. 

I do think we want to avoid ending up with another stale trunk. As I
mentioned in my previous note it's important to have a reasonable scope
for the next upcoming major (5.4/6.0) release and make sure we do have
the right amount of discussions re: new functionality committed. So I do
propose that in the coming weeks (as 80% of the ideas surface) the RMs
create a roadmap for the next version which clearly identifies the
must-haves and should-haves. This can always be changed/tweaked (as we
always have in the past) but it sets the tone for pushing out
functionality sooner rather than later (i.e. if a should-have is still
not quite fully baked but all must-haves are done then ship). 

As we saw with PHP 5.3 it ended up being a pretty major version and it
delivers a lot of incremental value. So it was good it didn't wait for
every single idea.

Andi

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

RE: [PHP-DEV] PHP 5.4 branch and trunk

[Andi Gutmans]

 -Original Message-
 From: Antony Dovgal [mailto:t...@daylessday.org]
 Sent: Wednesday, March 17, 2010 2:25 AM
 To: internals@lists.php.net
 Subject: Re: [PHP-DEV] PHP 5.4 branch and trunk
 
 On 03/16/2010 07:13 PM, Derick Rethans wrote:
  + merge php-fpm branch?
 
  Can't see why not. Is there an RFC for this?
 
 No, there are no RFCs on that.
 Just copy sapi/fpm to 5_4 and you've merged it.

I think it'd actually be a good idea to have RFCs for major pieces of new 
functionality even if they are retroactively written for cases such as sapi/fpm 
and new output buffering. Quite a bit of time has passed and it's good 
documentation for the new releases + gives people an opportunity to review as 
we work towards the next big release. It may just mean refactoring a past email 
that describes this in detail so doesn't have to be huge effort but would be 
good to be more organized with the new release.

Andi
 

RE: [PHP-DEV] PHP 6

[Andi Gutmans]

 -Original Message-
 From: Olivier Hill [mailto:olivier.h...@gmail.com]
 Sent: Saturday, March 13, 2010 10:15 AM
 To: Derick Rethans
 Cc: PHP Developers Mailing List
 Subject: Re: [PHP-DEV] PHP 6
 
 We need to focus on Unicode more than what some says, whether this
 means descoping the Unicode release or not. However, this means that
the
 development focus needs to be towards new features AND Unicode, not
 having the new feature branch, and the siberia branch with Unicode
support.

I think the key to rebuilding momentum in PHP development is to not try
and boil the ocean but to focus on smaller major releases. This would
enable us to manage a more predictable release cycle, lower the risk for
each release incl. better manage compatibility and increase motivation
for contributors as they know they can have an impact and if they can't
make one release they know the next isn't that far off (the latter also
eliminates pressure to push pre-mature functionality into a release).

In that spirit I would not necessarily couple Unicode support and the
next smaller major version. First I would suggest to build a
well-defined, reasonably scoped list of functionality for the next drop.
I think we should make only a few features must-haves and the rest
should-haves so that only high-priority pieces of functionality can
potentially hold up a release. It also helps with quality as high risk
functionality that feels unstable could be pushed out if needed. This
encourages pushing out functionality to our users sooner rather than
later (in the realm of reason).

Then as far as Unicode support is concerned I think we need to work in
parallel on various RFCs that can provide alternative ways of
approaching the Unicode problem. Given the performance hit, memory
overhead and complexity of the current implementation (which I also
supported) I think we should try and look for a solution that is more
pragmatic and is more explicit - giving the average PHP user the same
experience, compatibility and performance characteristics of PHP 5.x
while giving the more sophisticated users who need Unicode the tools to
build global applications.

Btw, I do think we should feel comfortable to call the next major
version PHP 6 no matter what its content is (if it warrants a major
version). I think the PHP dev community should put a stake in the ground
and feel comfortable to redefine what PHP 6 is, whether it's with or
without Unicode. This isn't a Perl 6 situation. This group shipped PHP
5.3 which was a very big step-up and a quite impressive major version.

My 2 cents.
Andi


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

RE: [PHP-DEV] About optimization

[Andi Gutmans]

 -Original Message-
 From: Tim Starling [mailto:tstarl...@wikimedia.org]
 Sent: Wednesday, January 13, 2010 7:19 PM
 To: Stas Malyshev
 Cc: internals@lists.php.net
 Subject: Re: [PHP-DEV] About optimization
 
 Stanislav Malyshev wrote:
 
  opcodes can be cached (bytecode caches do it) but op_array can't
  really be cached between requests because it contains dynamic
  structures. Unlike Java, PHP does full cleanup after each request,
  which means no preserving dynamic data.
 
 APC deep-copies the whole zend_op_array, see apc_copy_op_array() in
 apc_compile.c. It does it using an impressive pile of hacks which
break with
 every major release and in some minor releases too. Every time the
compiler
 allocates memory, there has to be a matching shared memory allocation
in
 APC.
 
 But maybe you missed my point. I'm talking about a cache which is
cheap to
 construct and cleared at the end of each request. It would optimise
tight loops
 of calls to user-defined functions. The dynamic data, like static
variable
 hashtables, would be in it. The compact pointerless structure could be
stored
 between requests, and would not contain dynamic data.
 
 Basically a structure like the current zend_op_array would be created
on
 demand by the executor instead of in advance by the compiler.
 
 
  I'm not sure how using pointers in op_array in such manner would
help
  though - you'd still need to store things like function names, for
  example, and since you need to store it somewhere, you'd also have
  some pointer to this place.
 
 You can do it with a length field and a char[1] at the end of the
structure. When
 you allocate memory for the structure, you add some on for the string.
Then
 you copy the string into the char[1], overflowing it.
 
 If you need several strings, then you can have several byte offsets,
which are
 added to the start of the char[1] to find the location of the string
in question.
 You can make the offset fields small, say 16 bits.
 
 But it's mostly zend_op I'm interested in rather than zend_op_array.
 Currently if a zend_op has a string literal argument, you'd make a
zval for it
 and copy it into op1.u.constant. But the zval allocation could be
avoided. The
 handler could cast the zend_op to a zend_op_with_a_string, which would
have
 a length field and an overflowed char[1] at the end for the string
argument. 

I tried the char[1] trick in the past. I can't quite remember why I
passed on it but I think because it now changed the sizes from zval from
being fixed and therefore couldn't efficiently cache zval allocations in
the memory manager (and of course this does not work with zend_opline
like structures where we have more than one zend_op(zval) in the
structure.

Andi

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

RE: [PHP-DEV] shebang skipping in 5.3.0

[Andi Gutmans]

 -Original Message-
 From: Tom Boutell [mailto:t...@punkave.com]
 Sent: Saturday, September 05, 2009 6:30 AM
 To: Marco Tabini
 Cc: Pierre Joye; jani.taski...@iki.fi; Andi Gutmans; Joey Smith;
 internals@lists.php.net
 Subject: Re: [PHP-DEV] shebang skipping in 5.3.0
 
-snip-
 Classic CGI has its advantages. It's simple to implement and memory
 leaks in individual instances don't matter. Embedded devices still use
 it quite a lot.
 
 Classic CGI is also an interesting transitional strategy when you're
 replacing a mixed bag of Perl, C and other CGI programs. Making it
 harder to transition to PHP isn't good for PHP. This is the Common
 part of CGI and shouldn't be forgotten.

If this is indeed a use-case for CGI then I think it's a valid argument
and we are probably better off supporting it. I did not remember shebang
works for real CGI.
There are still plenty of use-cases for running CGI (as opposed to
FastCGI) in the industry.
Question now is whether this should be done in the scanner or in the
SAPI.  I'll check with Dmitry who made this change.

Andi

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

RE: [PHP-DEV] shebang skipping in 5.3.0

[Andi Gutmans]

Shebang is for command line scripts (php-cli). It does not make sense to
support it for Web server scripts. It just adds unnecessary
code/complexity to that code base. Removing the support from php-cgi was
really a remnant of the old days when cli and cgi were the same SAPI.
I think we are better off this way.

Andi

 -Original Message-
 From: Joey Smith [mailto:j...@joeysmith.com]
 Sent: Friday, September 04, 2009 1:35 AM
 To: internals@lists.php.net
 Subject: Re: [PHP-DEV] shebang skipping in 5.3.0
 
 I definitely had the wrong changeset - sorry, Nuno. :) Looks
 like maybe 273177 is the problem child.
 
 http://tinyurl.com/lewcft
 
 
 On Fri, Sep 04, 2009 at 09:25:52AM +0100, Scott MacVicar wrote:
 
 
  On 4 Sep 2009, at 09:16, Joey Smith j...@joeysmith.com wrote:
 
  I can understand not having the 'shebang skipping' code
  in both the SAPI *and* the scanner, but we probably
  need to have it in at least ONE of them. :)
 
  Per his email[1] almost a year ago, Dmitry removed the
  shebang line check from sapi/cgi/cgi_main.c in changeset
  264153, saying:
 Removed shebang line check from CGI sapi (it is
 checked by scanner)
 
  In http://tinyurl.com/me8528 (changeset 262275), nlopess
  removed the code from the scanner.
 
  Oops?
 
  What's the problem your having? The skip code is still there just in
a
  different bit.
 
  Scott
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


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

RE: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/TSRM/tsrm_win32.c trunk/TSRM/tsrm_win32.c

[Andi Gutmans]

You may want to look at pcntl_exec() which is the UNIX equivalent of
what you want to do. It does not use sh and the pcntl extension is not
supported on Windows.
A Windows implementation may not fit this function signature but it's a
good place to start.

Andi

 -Original Message-
 From: Garrett Serack [mailto:garre...@microsoft.com]
 Sent: Thursday, August 20, 2009 7:24 AM
 To: Stas Malyshev; Pierre
 Cc: 'PHP Internals'
 Subject: RE: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/
branches/PHP_5_3/NEWS
 branches/PHP_5_3/TSRM/tsrm_win32.c trunk/TSRM/tsrm_win32.c
 
 Dammit.
 
 I am indeed wrong in this. I was pretty sure that popen on Unix
 *didn't* go via 'sh', but after digging deeper, you are completely
 correct.
 
 We should revert that patch, and I'll write a new separate routine
 that doesn't use cmd.exe as a gateway.
 
 My Apologies.
 
 G
 
 -Original Message-
 From: Stanislav Malyshev [mailto:s...@zend.com]
 Sent: Wednesday, August 19, 2009 2:40 PM
 To: Garrett Serack; Pierre
 Cc: 'PHP Internals'
 Subject: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/
branches/PHP_5_3/NEWS
 branches/PHP_5_3/TSRM/tsrm_win32.c trunk/TSRM/tsrm_win32.c
 
 Hi!
 
  Initially, this prevents popen_ex from failing when the actual
  executable doesn't exist, since cmd.exe /c c:\foo\bar\xxx.exe will
  *always* successfully start a process. This can be seen in bug
  #43327.
 
  Second, is that by having the intermediate process, I'm pretty sure
  there's some extra-buffering of the input/output streams going on
  (once for the child proc, and once for the cmd.exe). This (probably
  along with a too-small pipe buffer) contributes to the behavior
found
  in #44994.
 
  Finally, I can't for the life of me see what benefit this brings to
  the table.  Other languages don't need to put cmd.exe in the middle
  of their children. The only case may be where someone wants to use
  built-in cmd.exe commands like 'dir' on popen_ex() , which would not
  be right anyway, and they should explicitly include the command
  processor in their command line.
 
 It's pretty big semantic change, not just a bugfix, so I think it'd be
 nice to announce and discuss it on the list, not just put it as minor
 bugfix.
 
 Also it means that all output redirections, shell commands, etc. stop
 working for exec, system, etc. since they all use popen().
 
 I see code out there that uses popen-dependent functions with all this
 stuff, so it makes serious BC break.
 Also, on Unix system, popen etc. by default use shell.
 
 I recognize there might be a need for calling processes directly, but
I
 think this can and should be done in BC-compatible manner.
 --
 Stanislav Malyshev, Zend Software Architect
 s...@zend.com   http://www.zend.com/
 (408)253-8829   MSN: s...@zend.com
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


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

RE: [PHP-DEV] one RM to rule them all

[Andi Gutmans]

Hi Lukas,

Thanks for stepping up and helping Johannes make the PHP 5.3 release
come together.
Your tracking skills are definitely an asset :)

Andi

-Original Message-
From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org] 
Sent: Thursday, July 09, 2009 11:06 AM
To: PHP internals
Subject: [PHP-DEV] one RM to rule them all

Aloha,

FYI: Since 5.3.0 is out and we are now in maintenance mode for this  
branch, there is not really a need for a release manager in the strict  
meaning of the title. In other words we can now go back to the  
traditional model of having a single RM that is mostly busy with  
technical decisions. As such I am stepping down to avoid the confusion  
that people keep thinking of me as someone who can actually review  
patches. I will of course continue to do my best to track todo items  
for the various branches.

Go Johannes! :)

regards,
Lukas Kahwe Smith
m...@pooteeweet.org




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


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

[PHP-DEV] RE: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/standard/tests/file bug41874.phpt bug47767.phpt link_win32.phpt TSRM tsrm_virtual_cwd.c

[Andi Gutmans]

This really does not look like a very safe commit at this point in the
RC cycle.
These kind of patches are very challenging and can affect behavior of
applications. They are affected by many things incl. user permissions,
CIFS, applications that move files, and more... I am sure you have
tested it quite a bit but my experience with these kind of patches is
that they take a long time to iron out.
My recommendation for RMs is not to accept or push out the release if we
do.

Andi

-Original Message-
From: Pierre-Alain Joye [mailto:paj...@php.net] 
Sent: Monday, June 15, 2009 5:14 PM
To: php-...@lists.php.net
Subject: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/standard/tests/file
bug41874.phpt bug47767.phpt link_win32.phpt TSRM tsrm_virtual_cwd.c 

pajoye  Tue Jun 16 00:13:56 2009 UTC

  Added files: (Branch: PHP_5_3)
/php-src/ext/standard/tests/filebug47767.phpt 

  Modified files:  
/TSRM   tsrm_virtual_cwd.c 
/php-src/ext/standard/tests/filebug41874.phpt link_win32.phpt 
  Log:
  - #47767, include_once does not resolve windows symlinks or junctions
  

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

RE: [PHP-DEV] RE: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/standard/tests/file bug41874.phpt bug47767.phpt link_win32.phpt TSRM tsrm_virtual_cwd.c

[Andi Gutmans]

Btw, replied to one big patch but the following is the one that caught
my attention:
- Windows ACL cache support, update existing tests and add a new one

I'm all in favor of having such a cache given Windows file system has
been such an impediment on performance but this is not a patch that
should go in at a late RC stage or even at any stage in an RC as they
take some time to stabilize. 

Andi

-Original Message-
From: Andi Gutmans [mailto:a...@zend.com] 
Sent: Monday, June 15, 2009 10:37 PM
To: Pierre-Alain Joye
Cc: internals@lists.php.net
Subject: [PHP-DEV] RE: [PHP-CVS] cvs: php-src(PHP_5_3)
/ext/standard/tests/file bug41874.phpt bug47767.phpt link_win32.phpt
TSRM tsrm_virtual_cwd.c 

This really does not look like a very safe commit at this point in the
RC cycle.
These kind of patches are very challenging and can affect behavior of
applications. They are affected by many things incl. user permissions,
CIFS, applications that move files, and more... I am sure you have
tested it quite a bit but my experience with these kind of patches is
that they take a long time to iron out.
My recommendation for RMs is not to accept or push out the release if we
do.

Andi

-Original Message-
From: Pierre-Alain Joye [mailto:paj...@php.net] 
Sent: Monday, June 15, 2009 5:14 PM
To: php-...@lists.php.net
Subject: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/standard/tests/file
bug41874.phpt bug47767.phpt link_win32.phpt TSRM tsrm_virtual_cwd.c 

pajoye  Tue Jun 16 00:13:56 2009 UTC

  Added files: (Branch: PHP_5_3)
/php-src/ext/standard/tests/filebug47767.phpt 

  Modified files:  
/TSRM   tsrm_virtual_cwd.c 
/php-src/ext/standard/tests/filebug41874.phpt link_win32.phpt 
  Log:
  - #47767, include_once does not resolve windows symlinks or junctions
  

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


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

RE: [PHP-DEV] Notes from the PDM in Chicago

[Andi Gutmans]

 -Original Message-
 From: Elizabeth M Smith [mailto:auroraeosr...@gmail.com]
 Sent: Wednesday, June 03, 2009 2:43 PM
 To: internals@lists.php.net
 Subject: Re: [PHP-DEV] Notes from the PDM in Chicago
 yes Hannes - interfaces for userland implemented streams would help
 people trying to figure out if they have all the methods they need for
 a
 particular stream type (SeekableStream et al) - this would be backward
 compat (you wouldn't HAVE to implement the interfaces IIRC, at least
 not
 right away) but would help things along - Sara had the general ideas
 for
 how this would be done.

Btw, this is also true for PDO. We would want interfaces for PDOStatement and 
some other classes there too. That is in the TODO for PDO I believe but if we 
do this then let's make sure we do it consistently.

Andi

RE: [PHP-DEV] Notes from the PDM in Chicago

[Andi Gutmans]

 -Original Message-
 From: Pierre Joye [mailto:pierre@gmail.com]
 Sent: Wednesday, June 03, 2009 11:50 PM
 To: Andi Gutmans
 Cc: Elizabeth M Smith; internals@lists.php.net
 Subject: Re: [PHP-DEV] Notes from the PDM in Chicago
 
  Btw, this is also true for PDO. We would want interfaces for
 PDOStatement and some other classes there too. That is in the TODO for
 PDO I believe but if we do this then let's make sure we do it
 consistently.
 
 I would suggest to create a specific RFC about this topic in the wiki.

The requirement itself is captured in http://wiki.php.net/rfc/pdov1. The
problem is of course coming up with an RFC for a standard way to do
interfaces for internal classes that need that (naming convention).
Will try and look into what precedence we have and see what we can
suggest.
Andi

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

RE: [PHP-DEV] RFC: Removing the Zend API

[Andi Gutmans]

Hi Paul,

This is something I have considered in the past esp. as it would also reduce 
dependency of extensions on PHP runtime and make it easier for 3rd parties to 
distribute PHP extensions which don't have to be rebuilt per-PHP version. This 
is similar to JNI.

There are some real challenges though and JNI is a good example of those 
challenges. In order to completely abstract the API from data structure you 
need higher level API calls esp. for things like arrays and objects which 
typically incur a significant performance loss. JNI sucks big time on that 
front. Also it often leads to additional data copying.

Also this doesn't necessarily have to replace the Zend API but in fact be an 
engine independent API. Over time if everyone adopts then we could get rid of 
Zend API. However, if what I say above is correct, we may find that it's 
actually very complementary and that some core extensions prefer to hook into 
the engine very tightly while third parties (e.g. pdflib) and less core 
extensions prefer to stick to an independent API which can work across not only 
mini release of PHP but also minor and in some cases major release of PHP.

This API would need to be designed in great detail and we would need to make 
sure it is long lasting.

My 2 cents.
Andi

 -Original Message-
 From: Paul Biggar [mailto:paul.big...@gmail.com]
 Sent: Monday, March 30, 2009 4:07 PM
 To: PHP Internals
 Subject: [PHP-DEV] RFC: Removing the Zend API
 
 Hi,
 
 I've added a new RFC to the wiki
 (http://wiki.php.net/rfc/remove_zend_api). It details a plan to try
 and decouple the Zend engine from the libraries, in order to allow
 large scale changes to the Zend engine in the future. The RFC
 describes a prototype phase of the project, which could reasonably be
 done within a GSOC project, so I have added it to the GSOC 09 page
 (http://wiki.php.net/gsoc/2009#prototyping_removal_of_the_zend_api).
 
 If anybody has any comments, I'd be delighted to hear them. If anybody
 knows (or is) a good student looking for a GSOC project (and I've left
 it late, there are only 3 days left to apply), please encourage the
 student to look at this. Finally, if anybody is interested in helping
 mentor this as part of the GSOC, I'd be grateful for the help (I have
 to start writing my thesis soon).
 
 Thanks,
 Paul
 
 --
 Paul Biggar
 paul.big...@gmail.com
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Stream chunk size

[Andi Gutmans]

I don't see a fundamental issue why it could not be arbitrary.
The only challenge which may be an issue is that this code clearly allocates 
the buffer on the stack for what are probably performance reasons. If you allow 
arbitrary chunk size and use alloca() (do_alloca()) for stack allocation you 
might kill the stack.
I suggest you do some performance tests and if you need to keep it on the stack 
then create some arbitrary limit like 8K and use stack below that and use heap 
above that (code will be uglier).

Andi

 -Original Message-
 From: Jonathan Bond-Caron [mailto:jbo...@openmv.com]
 Sent: Monday, March 02, 2009 8:48 AM
 To: 'PHP Developers Mailing List'
 Subject: [PHP-DEV] Stream chunk size
 
 Hi everyone, I have a question about streams and the maximum 'chunk size' of
 8192.
 
 
 
 I've read README.STREAMS and found these slides by Wez:
 
 http://netevil.org/blog/2008/07/slides-php-streams
 
 
 
 While trying to write an Amazon S3 stream wrapper and I ran into an issue
 with large files:
 
 
 
 $fp = fopen('s3://mvtest/large.html', 'r'); // 30 mb
 
 
 
 // This is OK
 
 fseek($fp, 10);
 
 echo fread($fp, 100) . \n; // 100 bytes
 
 echo fread($fp, 100) . \n; // 100 bytes
 
 
 
 // This is OK (according to documentation, max 8192 bytes)
 
 echo fread($fp, 65536) . \n; // 8192 bytes
 
 
 
 My issue is I would like to request larger 'chunks', something like:
 
 stream_set_chunk_size($fp, 65536);
 
 
 
 echo fread($fp, 65536) . \n; // 65536 bytes
 
 echo fread($fp, 10) . \n; // 65536 bytes
 
 echo fread($fp, 15) . \n; // 15 bytes
 
 
 
 Then copying to a file and avoiding memory issues:
 
 
 
 $wfp = fopen('/tmp/large.html');
 
 stream_copy_to_stream($fp, $wfp); // read 65536 byte chunks, write default
 8192 byte chunks
 
 
 
 stream_set_chunk_size($wfp, 65536);
 
 stream_copy_to_stream($fp, $wfp); // read  write 65536 byte chunks
 
 copy('s3://mvtest/large.html', '/tmp/large.html'); // read  write default
 8192 byte chunks
 
 
 
 Going through the PHP 5.2 source, it looks like there's support for it but
 at some places the 8192 'chunk' is hardcoded:
 
 
 
 #define CHUNK_SIZE 8192
 
 
 
 PHPAPI size_t _php_stream_copy_to_stream(php_stream *src, php_stream *dest,
 size_t maxlen STREAMS_DC TSRMLS_DC)
 
 {
 
 char buf[CHUNK_SIZE]; ß  Is there any reason the php_stream
 *src-chunk_size isn't used?
 
 
 
 stream_set_chunk_size($fp, 65536); // Would mean src-chunk_size = 65536;
 
 
 
 I'd like to try to write a patch for it, anything that I should know about
 streams and why the limit is there?


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

RE: [PHP-DEV] 5.3 todos

[Andi Gutmans]

 -Original Message-
 From: shire [mailto:sh...@tekrat.com]
 Sent: Thursday, February 12, 2009 11:02 AM
 To: Lukas Kahwe Smith
 Cc: PHP Internals List
 Subject: Re: [PHP-DEV] 5.3 todos
 
 
 Seeing as I have an interest in this getting in 5_3, I'll work up a
patch for
 this unless someone wants to speak up that they've got it.  I don't
have Karma
 to Zend though, so I'll need someone to commit for me. ;-)

You can send me the patch.

Andi

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

RE: [PHP-DEV] 5.3 todos

[Andi Gutmans]

 -Original Message-
 From: Hannes Magnusson [mailto:hannes.magnus...@gmail.com]
 Sent: Saturday, February 14, 2009 6:04 PM
 To: Andi Gutmans
 Cc: shire; Lukas Kahwe Smith; PHP Internals List
 Subject: Re: [PHP-DEV] 5.3 todos
 
 And you are?
 CTO of some company? Claiming you wrote PHP?
 Why should the PHP community give a damn? There were way more people
 involved then you.
 Some of them even got fired few days ago.
 
 I have a great interest in the patch as well, and I have zend karma
 too. Who are you to judge if the patch makes sense or not? I am pretty
 damn sure I have done more fore PHP then you have in the past few
 months. Let the fudge community take care of his patch.

Just to set the record straight Hannes and I already communicated on
this and we are good.
I guess I should have been a bit more verbose because what I meant was
that I'd commit it but it seems that was misunderstood and caused
somewhat of an overreaction :)

Andi

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

RE: [PHP-DEV] towards the next 5.3 release

[Andi Gutmans]

 -Original Message-
 From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org]
 Sent: Friday, February 06, 2009 11:57 PM
 To: Andi Gutmans
 Cc: php-dev List
 Subject: Re: [PHP-DEV] towards the next 5.3 release
 
 Well we have established the primary testers mailinglist for this
 purpose. However the current release plan only includes mailing this
 list when the RC stage has been reached:
 http://www.php.net/reST/php-src/README.RELEASE_PROCESS
 
 So obviously this list can be used to get in contact with this group
 of projects. Maybe it makes sense to include them in x.y.0 releases.
 Then again the plan was to mail them once we hit RC1 anyways ...

OK that's good although it may make sense to push that up to beta.
In the past we have looked at Release Candidates as (We think it's
ready to release and if no one finds critical bugs we could just rename
the package). I doubt this is where you think we're at now and it's
more about making sure we get broader testing. It's a bit of a chicken
and egg so I understand the benefits of calling it RC. I guess what I
was suggesting was that we at least have folks do a quick sanity with
applications so we feel good about going into the RC.

Andi

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

RE: [PHP-DEV] towards the next 5.3 release

[Andi Gutmans]

 -Original Message-
 From: Lukas Kahwe Smith [mailto:m...@pooteeweet.org]
 Sent: Tuesday, February 03, 2009 5:42 AM
 To: php-dev List
 Subject: [PHP-DEV] towards the next 5.3 release
 
--snip--
 5) upgrading guide
--snip--

RC really signifies a feature complete + should be releasable state.
I think a good step before would be to reach out to some of the popular
PHP application authors and see if they can give b1 a try. This will
give us input for upgrading guide and it may raise some issues.

Maybe we can first collect a list here on internals@ on what apps have
been successfully been run on 5.3 and whether they required any
tweaking. If after we make a list there's still need to reach out I'd be
happy to do some of that.

Andi

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