Re: [PHP-DEV] CS random values

[Philip Olson]

> As a noob here, what should I do next in order to pursue my objective? Is
> this what the PHP RFC is for?


Hi Tom,

I fully support a one-method-to-rule-them-all for generating random sauce. Long 
ago I created an incomplete RFC on the subject, but please feel free to ignore 
and create a new/better one. There are a couple of old related RFC entries, 
actually:

 - https://wiki.php.net/rfc/get-random
 - https://wiki.php.net/rfc/functiongetentropy

I suggest you apply for a wiki account, and it'll be approved with RFC karma, 
and then you can create the RFC.

Regards,
Philip


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

[PHP-DEV] Re: Wiki account application? [Re: [PHP-DEV] CS random values]

[Philip Olson]

On Jan 5, 2012, at 6:56 AM, Tom Worster wrote:

> On 12/29/11 2:03 PM, "Philip Olson"  wrote:
> 
>> Hi Tom,
>> 
>> I fully support a one-method-to-rule-them-all for generating random
>> sauce. Long ago I created an incomplete RFC on the subject, but please
>> feel free to ignore and create a new/better one. There are a couple of
>> old related RFC entries, actually:
>> 
>> - https://wiki.php.net/rfc/get-random
>> - https://wiki.php.net/rfc/functiongetentropy
>> 
>> I suggest you apply for a wiki account, and it'll be approved with RFC
>> karma, and then you can create the RFC.
> 
> Thanks, Philip.
> 
> How do I apply for a wiki account and RFC authoring privileges? (I googled
> but did not find.)

Hello Tom,

Your wiki account has been approved, with RFC namespace karma granted.

The registration page alludes to this by requesting that you write the 
webmaster list about what you'll be working on. I'll update that page
to make it clearer.

  https://wiki.php.net/start?do=register

Have fun :)

Regards,
Philip


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

[PHP-DEV] disabling ereg

[Philip Olson]

Hi geeks!

We're unable to disable the ereg extension today, yet it's been deprecated 
since PHP 5.3.0. Is this by design?

Regards,
Philip


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

Re: [PHP-DEV] disabling ereg

[Philip Olson]

Hello Pierre,

I mean that the ereg extension is deprecated, yet we cannot disable 
it while compiling PHP. In other words, ereg() and friends always 
exist in PHP, and emit E_DEPRECATED errors upon use. We should have
the option of creating fatal undefined function errors… basically.

Currently this exists for ereg:

  --with-regex[=TYPE]

So I guess we want:

  --without-regex

Even though --disable-ereg would feel more natural.

Regards,
Philip

On Jan 10, 2012, at 12:27 AM, Pierre Joye wrote:

> is it not emulated using pcre now? as in, the ereg library is not used anymore
> 
> On Tue, Jan 10, 2012 at 8:49 AM, Philip Olson  wrote:
>> Hi geeks!
>> 
>> We're unable to disable the ereg extension today, yet it's been deprecated 
>> since PHP 5.3.0. Is this by design?
>> 
>> Regards,
>> Philip
>> 
>> 
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
> 
> 
> 
> -- 
> 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] disabling ereg

[Philip Olson]

Hi!

This thread has veered off-course. So to summarize:

  (1) ereg is deprecated, and usage is discouraged
  (2) It emits E_DEPRECATED errors as of PHP 5.3
  (3) We cannot disable/remove ereg at compile time (today)

I'm suggesting we alter (3) so that we, the people who compile
PHP, can optionally remove this extension from our PHP 5.4+.

This means adding --without-regex to go along with --with-regex,
which is the current compile-time option for ext/ereg.

Any objections? Regardless of deprecation status, this option
should be available. Or if not, why?

Regards,
Philip

On Jan 10, 2012, at 10:41 AM, Pierre Joye wrote:

> Can you please carefully read what I wrote? Thanks.
> 
> I said:
> 
> " the deprecation is only an information via the documentation"
> 
> as in not adding noises to the language without any good reason.
> 
> On Tue, Jan 10, 2012 at 7:11 PM, Ferenc Kovacs  wrote:
>> 
>> 
>> On Tue, Jan 10, 2012 at 6:28 PM, Pierre Joye  wrote:
>>> 
>>> what I mean is that, as far as I remember, the deprecation is only an
>>> information via the documentation. We did not want to break BC and all
>>> that as it is now emulated through pcre.
>> 
>> 
>> no, we deprecated it, and albeit it was a discussion to un-deprecate it, we
>> kept it:
>> I think we have enough reasons to keep it deprecated as we have much better
>> alternative (pcre) which we want to recommend to the users.
>> http://lxr.php.net/opengrok/xref/PHP_5_4/ext/ereg/ereg.c#54
>> 
>> --
>> Ferenc Kovács
>> @Tyr43l - http://tyrael.hu
> 
> 
> 
> -- 
> 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] disabling ereg

[Philip Olson]

On Jan 10, 2012, at 11:54 AM, Rasmus Lerdorf wrote:

> On 01/10/2012 11:33 AM, Philip Olson wrote:
>> Any objections? Regardless of deprecation status, this option
>> should be available. Or if not, why?
> 
> The main reason is that we are not done removing all the dependencies.
> This is a large deprecation that is going to require the process to span
> multiple versions. We could add a way to disable it, but it is going to
> break some extensions in ways that are not obvious to the user.

Makes sense. Removing ereg dependencies from PHP 5.5 (trunk) seems like 
the wise choice, and adding --without-regex then as well.

Regards,
Philip


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

Re: [PHP-DEV] RFC: PHP 6 include E_NOTICE in default php.ini

[Philip Olson]

Hi Richard,

I'm a little confused. Showing E_NOTICE errors is already the default 
with both php.ini-* files. What does this RFC change? Are you proposing 
that the PHP default value (without a php.ini) be modified?

; error_reporting
;   Default Value: E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
;   Development Value: E_ALL
;   Production Value: E_ALL & ~E_DEPRECATED & ~E_STRICT

Regards,
Philip

Ref: 
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/php.ini-production?view=markup


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

Re: [PHP-DEV] PHP 5.4.0 released!

[Philip Olson]

On Mar 1, 2012, at 4:17 PM, Ángel González wrote:

> On 02/03/12 01:00, Simon Schick wrote:
>> Hi, all
>> 
>> When will the documentation be ready?
>> 
>> For example you wrote that something has changed to the keywords *continue 
>> *and
>> *break *- but I dont get what and it's not defined in here:
>> http://www.php.net/manual/en/control-structures.continue.php
>> 
>> Bye
>> Simon
> The option to use a variable as target for the break/continue.
> Ie. you no longer can do break $var; or continue $var;
> 
> It's not telling you that you can do that, so the docs don't
> seem wrong. :)


I like this logic :)

Also, the docs are updated in SVN, and will show up ~tomorrow.

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

Re: [PHP-DEV] PHP 5.4.0 released!

[Philip Olson]

The mirrors have not yet updated, which is why the announcement
linked specifically to docs.php.net (which builds the docs
4x daily[1]) for several entries.

So while not perfect… the mirrors will update tomorrow, and
will include additional information. Also, a few people are 
making migration54 commits while I type this message. :)

Regards,
Philip

[1] https://wiki.php.net/doc/builds

On Mar 1, 2012, at 4:18 PM, David Muir wrote:

> I noticed that too.
> 
> The migration guide is also missing a lot of stuff.
> 
> A quick overview:
> 
> http://au.php.net/manual/en/migration54.changes.php:
> content missing
> 
> http://au.php.net/manual/en/migration54.new-features.php:
> missing a lot of new features listed elsewhere
> 
> http://au.php.net/manual/en/migration54.functions.php:
> missing links and documentation for several functions
> 
> http://au.php.net/manual/en/migration54.class-constants.php:
> claims that there are several new class constants, but none are listed
> 
> http://au.php.net/manual/en/migration54.methods.php
> missing links and documentation for several methods
> 
> http://au.php.net/manual/en/migration54.new-extensions.php
> nothing listed
> 
> http://au.php.net/manual/en/migration54.extensions-other.php
> "The following extensions can no longer be disabled during build
> configuration: " but only one empty list element
> 
> Cheers,
> David
> 
> 
> 
> 
> 
> 
> 
> 
> On 02/03/12 11:00, Simon Schick wrote:
>> Hi, all
>> 
>> When will the documentation be ready?
>> 
>> For example you wrote that something has changed to the keywords *continue 
>> *and
>> *break *- but I dont get what and it's not defined in here:
>> http://www.php.net/manual/en/control-structures.continue.php
>> 
>> Bye
>> Simon
>> 
>> 2012/3/2 Kris Craig 
>> 
>>> Lol agreed.  I typically just build manually off the latest release
>>> anyway.  But not everybody does that.  There are a lot of servers out there
>>> running on PHP 5.1.x right now.
>>> 
>>> --Kris
>>> 
>>> 
>>> On Thu, Mar 1, 2012 at 3:52 PM, Reindl Harald >>> wrote:
 
 Am 02.03.2012 00:46, schrieb Kris Craig:
> LOL tell me about it!  The default PHP repos for many OSes are still
 using
> 5.1.x
 so what
 
 using 5.3.x in production since 3 months after release everywhere
 learning to build packages for your OS is the key
 
 
> 
> 
> -- 
> 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] get_magic_quotes_* != deprecated?

[Philip Olson]

Hello!

Please clarify whether or not get_magic_quotes_gpc() and 
get_magic_quotes_runtime() 
are deprecated, because I do not think they are. Deprecated means people should 
not
use them while writing new code, but they are perfectly sensible functions.

I propose that we do not describe get_magic_quotes_* as deprecated, and that 
they
exist forever, and always return false.

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

Re: [PHP-DEV] get_magic_quotes_* != deprecated?

[Philip Olson]

On Mar 1, 2012, at 6:26 PM, Adam Harvey wrote:

> On 2 March 2012 09:56, Philip Olson  wrote:
>> Please clarify whether or not get_magic_quotes_gpc() and 
>> get_magic_quotes_runtime()
>> are deprecated, because I do not think they are. Deprecated means people 
>> should not
>> use them while writing new code, but they are perfectly sensible functions.
>> 
>> I propose that we do not describe get_magic_quotes_* as deprecated, and that 
>> they
>> exist forever, and always return false.
> 
> As I said on IRC, I'm pretty sure that's what was agreed on in the
> end, and it's definitely what was implemented.

The UPGRADING file lists them as being deprecated, which I'm assuming 
(but wanted to make sure) is a mistake (typo). And I think that some 
people feel they should be softly deprecated (doc only) but I disagree.

Regards,
Philip


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

Re: [PHP-DEV] GIT commit mails

[Philip Olson]

On Mar 2, 2012, at 10:36 AM, Derick Rethans wrote:

> Hi!
> 
> Can we please fix the GIT commit mails before we move anything else 
> over?

+1

Regards,
Philip

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

Re: [PHP-DEV] PHP as a template language

[Philip Olson]

On Apr 5, 2012, at 8:22 PM, Rasmus Lerdorf wrote:

> On 04/05/2012 07:55 PM, Sébatien Durand wrote:
>> IMHO, PHP is a great template language. This is what makes it so simple 
>> and powerful, compared to other web languages.
>> 
>> So far, we have "> 
>> A suggestion : deprecate these old tags and replace them with a more 
>> elegant and a shorter implementation.
>> 
>> For example : "<%" and "<%=" or "{%" and "{{" ?
>> 
>> What do you think, guys ?
> 
> It is well past April 1.

Here's Rasmus proposing http://marc.info/?l=php-internals&m=90279104403805&w=2

Discussion ensues, and we end up with multiple tags. Too bad. ;)
Oh, and here's a list of possible possible options from back then,
taken from that thread:

  1. 
  2. 
  3. 
  4. <% code %>
  5. (1) and (3) combined using some fancy hard-to-code 
 scanner with dedicated XML support.
  6. 
  7. <_ code _>
  8. <: code :>
  9. << code >>
  10. 
  11. 
  12. <[ code ]>
  13. <{ code }>

Anyway, just a brief out-of-context look at the past. Woot!

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

Re: [PHP-DEV] voting without vcs accounts

[Philip Olson]

On Apr 16, 2012, at 6:21 PM, Ferenc Kovacs wrote:

> On Tue, Apr 17, 2012 at 3:14 AM, Kris Craig  wrote:
> 
>> 
>> 
>> On Mon, Apr 16, 2012 at 6:10 PM, Ferenc Kovacs  wrote:
>> 
>>> 
 Just to play devil's advocate (Satan and I go way back), what about
 people who are established PHP developers but who generally don't
 participate in the development/discussion of PHP core?  An argument could
 be made that, as the users of PHP, they should be able to have some say in
 its development.  That's not my position, mind you; I'm just throwing that
 premise out there to see if it holds up.  =)
 
>>> 
>>> could you please open a separate thread for that?
>>> btw. "regular participant of internals discussions" is one of the reason
>>> on which group someone can get voting karma.
>>> so if that is provided, anybody have a chance to get join
>>> the decision making process.
>>> 
>>> --
>>> Ferenc Kovács
>>> @Tyr43l - http://tyrael.hu
>>> 
>> 
>> Why would that be a separate thread?  Isn't that what we're talking
>> about?  I.e. determining who gets voting access and who doesn't?
> 
> 
> I just ask for clarification on how the community representatives (which is
> defined in the accepted voting RFC) can get their karma.
> You are talking about changing the requirements for somebody to be able to
> participate in the voting, thus changing/extending the original RFC.

The voting RFC is unclear but aside from that, there are two non-vcs 
accounts with voting karma today:

  User: damz:  Damien Tournoud - d...@damz.org
  User: hywan: Ivan Enderlin   - ivan.ender...@hoa-project.net

Not saying they should or should not, but just saying. And I'm not sure 
how/when they received the voting karma but it happened.

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

Re: [PHP-DEV] voting without vcs accounts

[Philip Olson]

On Apr 17, 2012, at 4:08 PM, Christopher Jones wrote:

> 
> 
> On 04/17/2012 03:50 PM, Stas Malyshev wrote:
>> Hi!
>> 
>>> sorry, I can't really follow you with that.
>>> do you have a problem allowing the non-vcs users (defined by the voting
>>> rfc) to vote, or do you have a problem providing a clear way for them to
>>> get their voting karma?
>> 
>> I have a problem that we don't have understanding of what is the goal of
>> this whole vote setup. What is it for? What we will be doing with it?
>> And please don't say "it says so in RFC" - it is not a goal.
> 
> Stas, I'm with Ferenc on this.  We just need one or two sentences somewhere
> in the wiki saying how non-contributors can get vote karma.  The sentences
> should give the physical process and what kind of people we will give karma 
> to.

The problem is that the voting RFC does not define who can vote. It contains
two parts:

  1. Those with SVN [sic] access (but how does karma come into play?)
  2. Those without (how do we provide such rights? to whom?)

If these are to be answered (they should) then I don't think an RFC can be 
edited like that (people already voted on it), so suspect we'd need a new 
RFC to replace it. Fun!

I suspect most people voted "Yes" for that RFC thinking it'd mean less noise
on this list while not caring about the details. That's only a guess. But 
trouble is, defining the "Who" is the most difficult part and a big reason why
general consensus is preferred. 

Regards,
Philip


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

Re: [PHP-DEV] [off] PHP: a fractal of bad design

[Philip Olson]

On Apr 18, 2012, at 1:34 AM, Hartmut Holzgraefe wrote:

> On 04/10/2012 06:20 PM, Adir Kuhn wrote:
>> Hi folks,
>> 
>> today I read this post, I think that some points are valid, follow the link 
>> for
>> you guys
> 
> as stuff like this comes up again and again (although not in as epic
> lenght as this one) i've been thinking whether it might make sense to
> have some
> 
> "PHP Gotchas, how they came to be, and why we can't simply fix them"
> 
> FAQ section in the manual or wiki?
> 
> If nothing else it would at least help with dealing with this kind
> of rant (nothing new here, move along, your concerns were already
> covered in ### in great detail), but also might help that would
> indeed want to understand why some things are as they are.
> 
> I'd rather proactively own this kind of discussions than just
> jump into them whenever they arise elsewhere …

Hello Hartmut,

Agreed, and I think it belongs in the manual. An example (not being
proposed as such, but is a rough idea):

  Why are function naming schemes seemingly random?

PHP glues many different API's together, and sometimes this
gets messy. PHP leans towards the C variant which is why the
likes of strlen() vs str_replace() exists, and …

As opposed to our current approach, which is via mailing lists and 
typically "RTFM." or "BC. Read archives." or the like. Ack!

And also include possible solutions/recommendations like this PHP FAQ
entry about haystack,needle ordering, which includes the following 
text:

A simple rule of thumb is as follows: Array function parameters 
are ordered as "needle, haystack" whereas String functions are the 
opposite, so "haystack, needle".

And thankfully there are already a lot of sites to steal the questions 
from, and often answers live within their user comments. :)

Regards,
Philip


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

[PHP-DEV] get_magic_quotes_gpc() returns false instead of 0

[Philip Olson]

Hello everyone,

The following bug report brings up a good point:

  https://bugs.php.net/61784

The get_magic_quotes_gpc() function returns 0/1 before 5.4, but now 
it returns boolean false. Instead it should return 0. Fixing this 
feels like a bug fix, which would go in 5.4.1. Thoughts?

Regards,
Philip



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

Re: [PHP-DEV] get_magic_quotes_gpc() returns false instead of 0

[Philip Olson]

On Apr 24, 2012, at 9:43 AM, Stas Malyshev wrote:

> Hi!
> 
>>  https://bugs.php.net/61784
>> 
>> The get_magic_quotes_gpc() function returns 0/1 before 5.4, but now 
>> it returns boolean false. Instead it should return 0. Fixing this 
>> feels like a bug fix, which would go in 5.4.1. Thoughts?
> 
> I do not see a reason to hold 5.4.1 for this.

The less people beginning to rely on this bug the better, and this is
a critical time. The impact of this BC break feels larger considering 
MQ is enabled by default in PHP 5.3 and below.

This change shouldn't damage the RC QA process as all this does (tm) 
is change the return of false to 0. And considering that the magic 
quotes feature is removed, this change should not affect other code.

Oh, sometimes it's nice that more people use == versus ===. ;)

Regards,
Philip

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

Re: [PHP-DEV] get_magic_quotes_gpc() returns false instead of 0

[Philip Olson]

On Apr 24, 2012, at 4:46 PM, Stas Malyshev wrote:

> Hi!
> 
>> The less people beginning to rely on this bug the better, and this is
>> a critical time. The impact of this BC break feels larger considering 
>> MQ is enabled by default in PHP 5.3 and below.
> 
> I understand but a) nobody should be using magic quotes anyway and b)
> holding release for 5.4.1 because of a very minor issue with easy
> workaround doesn't seem productive for me. If we hold release for each
> such thing, we'll never have 5.4.1 at all.

I don\'t understand why get_magic_quotes_gpc() and get_magic_quotes_runtime()
get such a bad wrap. People using these functions are not using magic
quotes, but instead they (most) are writing code that will work in environments
that have it enabled. This helps code work in PHP 5.4 and below, as opposed 
to only PHP 5.4 and above.

And yes, the number of people that use \"=== false\" here is small I reckon.
But this is a BC break in a BC function. Something feels very wrong about 
that.

So I understand that we cannot hold a release for every bug and that we 
have known bugs in every release, but will we revert this change after it
exists in two PHP releases? Whatever the case, this also means we\'ll have 
to document this change… and here I was trying to be lazy. :)

Regards,
Philip


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

Re: [PHP-DEV] Bringing users along ...

[Philip Olson]

On Aug 1, 2012, at 7:01 AM, Johannes Schlüter wrote:

> On Wed, 2012-08-01 at 13:38 +0100, Lester Caine wrote:
>> The default if it's not included in the .ini is ON, but the
>> sample .ini's both switch it off, and that is what the distributions
>> follow when creating a clean install.
>> 
>> ALL that was required when the problem was identified was that > handled in PHP5.3 the same way it IS now handled in PHP5.4 and the
>> problem would not exist. This is an example of not thinking through to
>> production a simple change in the core PHP ...
> 
> The default are the compiled in values. The provided ini files are
> suggestions with comments for improving the configuration above the
> default. Those values aren't the default for exactly the reason you
> identified. If distributions "force" those values on you complain there.
> 
> And no, we won't change the core language ( There should only be bugfixes, no feature changes.
> 
> If you want to help please test 5.5 snapshots before the release and
> identify possible issues there. As Rasmus and others said we try hard to
> make migration simple while allowing evolution to happen, sometimes we
> fail, that can only be fixed before a release, we can't change the past,
> yet.

One problem here is that we do not distribute a php.ini file with default 
values. The "what is the default value?" topic is real and comes up often. 
Is it time we get back to our roots and include a file like the old 
php.ini-dist? And become friends with distributions to suggest real default 
values to be used all across the world?

Today it feels dirty to mention "default values" in the PHP world as really
this concept does not exist. 

Regards,
Philip


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

[PHP-DEV] [PATCH] auto_globals_jit in php.ini*

[Philip Olson]

Hello!

This patch inserts the auto_globals_jit directive into the
php.ini files. Since the default value is 1 in main.c, this
value (On) is used in this patch. Please apply it to all PHP
5 branches.

Patch: http://boogle.com/tmp/patch_auto_globals_jit.txt

Regards,
Philip

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

[PHP-DEV] [PATCH] Install Documentation for Unix/Windows

[Philip Olson]

Hello!

Both win32/install.txt and INSTALL need an update before the
next PHP release so here's a patch for these two files:

 http://boogle.com/tmp/patch_phpsrc_install.txt

It's an enormous patch because the line endings were
incorrect for these files but have been fixed (install.txt =
\r\n and INSTALL = \n). If you're curious on what content
actually changed, see:

 http://boogle.com/tmp/patch_phpsrc_install_changed.txt

There have been some important changes to these docs so
please apply this patch ASAP.

Regards,
Philip

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

Re: [PHP-DEV] CVS Account Request: krid_

[Philip Olson]

On Nov 28, 2007, at 10:49 PM, Dirk Randhahn wrote:

Please send me a new CVS password as I forgot mine for the account  
krid ([EMAIL PROTECTED])





Hello Dirk,

  http://master.php.net/forgot.php

Regards,
Philip

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo

[Philip Olson]

On Nov 29, 2007, at 11:26 AM, Steph Fox wrote:


We do have peer-review after all.


Not on CLA'd code we don't.


Steph the CLA seems to just relate to the docbook xml specifications
for PDO.


Someone told you that, or have you developed psychic powers?

The same applies, regardless. If a commit to that module breaks the  
PHP manual build, you or I can't fix it. There was a time before  
now when a CLA'd module broke the snaps build, same problem.


FWIW, there is an IBM copyright attached to the "PDO Driver How-To"  
document here:


  http://php.net/manual/en/internals2.pdo.php

However, a ~couple months ago IBM gave permission to remove this  
copyright (because the authors are listed as general contributors,  
thus representing IBM) although we've not yet implemented this  
removal. We did [temporary] remove it about six months ago but...  
I'll make the update today.


Regards,
Philip

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

Re: [PHP-DEV] get_magic_quotes_gpc, get-magic-quotes-runtime in head, get a "final" decision

[Philip Olson]

It seems that there is voices in favor of keeping the GPC related
functions in HEAD/php6 but returning always FALSE. I thought the
decision was already done but I rather prefer to ask the list a second
time and be done with this topic (and be free to bogus any other bug
reports about this problem, especially when the reporters begin to
spam me and other with all possible funny words ;-)

There is not really a need to discuss the removal again, that's why I
ask for a simple vote:

+1: remove them (as it is now in HEAD)
-1: Restore them and always return FALSE (not 0)
 0: I don't care, do what you wish, I never use them anyway

Feel free to comment the topic but please don't start an endless
discussion, we already discuss it to death two years ago (yes, two
years ago :-)



I can only find archives[1] that decide they should exist in PHP 6,  
and NEWS[2] indicates this decision to be true. Where else was this  
decision decided?


Them existing should depend on if PHP 6 wants a chance to run plenty  
of PHP 5 code out-of-the-box. Is this desire known yet?


And since they return 0 now, why would the return value be changed to  
false for this BC function?


Regards,
Philip

[1] http://marc.info/?t=11417022263&r=1&w=2
[2] http://php.net/php6news

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

Re: [PHP-DEV] Updates to the QA pages

[Philip Olson]

Rob Nicholson and I have made a set updates the QA pages, mainly  
based on things that we've learned over the past
year of test case writing - we had a lot of input from Raghu and  
Marcus on this too of course.


The updated pages are here for review: http://zapt.info/phpt/write- 
test.php.


Greetings Zoe-

A few moons ago the following [rough] wiki page was started with the  
aim to answer questions not yet covered within the QA site, questions  
like "installing lcov", "how to test if a test covers what I want",  
and such. Please feel free to steal information from it for qaweb:


  http://doc.php.net/wiki/writing-tests

Regarding your proposed changes, could you provide a unified diff?  
Looks good, but it's difficult to see what's been updated. Or, just  
commit... :)


Regards,
Philip

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

Re: [PHP-DEV] _REQUEST and variable_order

[Philip Olson]

On Feb 13, 2008, at 1:50 PM, Stanislav Malyshev wrote:

Yes, that's why php.ini-recommended should have GP. However,  
php.ini-dist documents *the default* - which should be GPC, like  
it is right now.


The default is NULL, which means using variables_order - just as  
before.  I don't see a lot of reason to change it to GPC - it would  
be neither old compatible way (using variables_order) nor new  
recommended way (using request_order=GP).


The default behaviour is proper in php.ini-dist and GPC is the  
default if no php.ini exists. The use of GP should be documented in  
php.ini-recommended like the other changes there, but php.ini-dist is  
not the place for that except it should mention that variables_order  
is the default like it currently does in the patch.


Regards,
Philip

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

Re: [PHP-DEV] magic_quotes and the question of BC

[Philip Olson]

On Feb 8, 2008, at 8:46 AM, Pierre Joye wrote:


On Feb 8, 2008 5:38 PM, Gregory Beaver <[EMAIL PROTECTED]> wrote:


Frankly, I don't see why there is any vote whatsoever.  It's plain
stupid to consider removing them when a fully backwards-compatible
solution exists that has no performance penalty, no security penalty,
and in fact no penalty at all.


It is not plain stupid to remove something when the underlying
features do not exist. It is expected.

Talking about BC in this case is a closed to be a complete non sense.
For two reasons:

1. If can't do that between two major versions, let define a rule: we
can't change _anything_ in PHP, no matter when (think: roll back all
these fatal errors)


The change here is to remove magical quotes and then have these  
functions always return 0, so yes we can change and keep [some] BC in  
one smooth motion.



2. it is fixable in three lines (with braces). PEAR had much harder
issues already, you can document the upgrade process (upgrade pear
then php, make install will work if you include a full upgrading
solution in go-pear.phar, if it is not the case already)


But the general problem is with old code working in PHP 6, not new or  
updated code working in PHP 6. These functions should remain, and if  
not, then PHP 6 should break everything... meaning, be the "make PHP  
do what we want it to do with little BC in mind" instead of only  
doing that sometimes. Which is it? What is the PHP 6 mission statement?


Regards,
Philip

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

[PHP-DEV] RFC: How PHP utilizes the Google SoC

[Philip Olson]

The Google Summer of Code sponsors students to work on Open Source  
projects over each summer. This RFC introduces guidelines and goals  
involving how we handle the SoC process.


Synopsis:
-
Nominate an administrator early, encourage idea development year  
round, and focus on nominating current contributors over new ones.


The Administrator:
-
The SoC Administrator is designated - hopefully before February 1.

Administrative duties:
-
- organize the ideas page with summer long tasks
- evaluate PHP project contributors for possible mentors and students
- mind all official SoC guidelines/timelines
- begin process for the following year

Choosing projects:
-
An official goal[1] of SoC is to encourage new contributors to the  
Open Source world. This RFC selfishly proposes an alternative yet  
defined angle for accomplishing this goal. We first encourage  
students to become accustomed to the PHP process, peers, and learn  
the quirks that go on around here. And later, they may apply for an  
SoC project.


Benefits:
- efficiency - can start work today
- in-house feel
- better retention
- a higher bus factor

Downsides:
- distracted by other php.net tasks
- encourages less outside proposals
- delays - "i'll wait for the summer"

The benefits are good, and while kept in mind the downsides can be  
dealt with.


Dealing with the downsides:
-
- students are discouraged by peers to work on other parts of the PHP  
project

- peers are encouraged to take on the students current php.net tasks
- be clear that all ideas by anyone are accepted, but in-house is  
preferred

- maintain a "How can I help PHP today?" guide with HOWTO:
  - create and submit a patch
  - resolve bugs
  - help maintain a pecl extension
  - write unit tests
  - write documentation, and/or translate
  - deal with user notes
  - ...

Ideas:
-
Idea generation and brain storming is encouraged all year, and ideas  
may be implemented at any time by any person. But once the summer  
nears, they (the ones not yet started) essentially become reserved as  
possible SoC proposals. Ideas that directly help php.net operations  
receive moderate preference.


Eventually idea management becomes its own beast, with SoC ideas  
being only a small part of that task.


This year:
-
This year we assign both new and current people, but in future years  
encourage people to join the PHP project first, and then potentially  
utilize the Google SoC later.



Regards,
Philip

[1] http://code.google.com/soc/2008/faqs.html#0.1_goals


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

Re: [PHP-DEV] RFC: How PHP utilizes the Google SoC

[Philip Olson]

On Mar 4, 2008, at 7:07 PM, Daniel Brown wrote:

On Tue, Mar 4, 2008 at 5:17 PM, Philip Olson <[EMAIL PROTECTED]>  
wrote:


 The Google Summer of Code sponsors students to work on Open Source
 projects over each summer. This RFC introduces guidelines and goals
 involving how we handle the SoC process.

[snip="important info"]

Philip (or anyone else who can answer);

According to the information I've read (and I'll admit, I've
*heard* of the GSoC, but am by no means familiar with it), the
organization receives a small stipend as the representative group.  My
question is: how is this usually spent?

The reason I ask is because I'd be very interested in mentoring a
student on a project if we can use this money to help move the RFC
Wiki (or similar) idea forward.  Besides, I'd be killing two birds
with one stone as it was, I was trying to figure out how I'd
afford the box and bandwidth as it is, because the Wiki idea - as I
think others may agree - is an excellent step toward the future of the
development of PHP.  So it's not an unselfish move on my part.



Hello Daniel,

Lack of funding is rarely a cause for such issues. Where there is a  
will, there is a free way. Many entities exist out there that are  
willing to donate boxes and bandwidth but people just need to find them.


The wiki is moving forward after delays for many reasons including  
unknowns about if PHP wants a wiki (some people hate them), our  
chaotic nature, and lack of time.  Lukas is now working on the wiki  
and it already has a domain (wiki.php.net) and CVS module (php-wiki- 
web) and once it goes online I have a feeling other new tools will  
start evolving. Just a guess. These were created yesterday.


As for where the mentor SoC money goes, I think it finds its way  
towards random PHP user groups.


Regards,
Philip



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

Re: [PHP-DEV] CVS Account Request: santiago

[Philip Olson]

On 22 Mar 2008, at 10:27, Alexey Romanenko wrote:


I would like to
request a CVS account to commit the translations to the russian  
translation of the php manual.

I have discussed with Antony Dovgal about it.


Hello Alexey-

This account has been created with karma added, welcome to the team! :)

Regards,
Philip


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

Re: [PHP-DEV] The Untouchables

[Philip Olson]

2. I didn't have a response yet regarding pecl/muscat, but it's been  
superceded by another GPL'd extension which is sited elswhere  
(Xapian). So I guess we're clear there too, I'd just rather have it  
from the horse's mouth.


Recently the pecl/muscat documentation was removed from phpdoc CVS. No  
horse mouth was involved, but it seemed like a good time.


Regards,
Philip


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

Re: [PHP-DEV] [PATCH] Scanner fixes and tweaks

[Philip Olson]

On 10 Apr 2008, at 09:48, Marcus Boerger wrote:

Hello Matt,

Thursday, April 10, 2008, 3:50:41 PM, you wrote:


Hi Scott,


I noticed that Nuno changed yyless() to be like flex after your  
commit (not
in HEAD?  I considered that, but figured you guys wanted it  
different :-)),
but now the heredoc end part is wrong again (hehe), and I see Tony  
reported
the broken tests...  Attached patch puts it back to pre-re2c  
state.  Also
remembered a useless "case EOF;" to remove in zendlex() to match  
HEAD's

(added at end of '05 (v1.647.2.18) for bug #35382, later fixed in the
scanner; doesn't look like it ever did much anyway).


BTW, maybe you could change the name in that 5.2 NEWS entry to just  
"Matt"?
No big deal, but that's what it's been other than the first few  
entries. :-)


We use short names only for people with a php.net account.


Hello Matt-

Just in case you've not seen this page yet, please go here and apply :)

  http://php.net/cvs-php.php

Regards,
Philip


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

Re: [PHP-DEV] spl documentation

[Philip Olson]

On 11/04/2008, Alexey Zakhlestin <[EMAIL PROTECTED]> wrote:
I noticed, that http://www.php.net/~helly/php/ext/spl/was updated

almost a year ago. Is the newer version available anywhere?



Good point, there're so many new things in there. Marcus? Etienne?
Anyone up to do regenerate some docs ?





I've a more recent build that covers DLLists, but only Marcus is  
able to

upload it to ~helly.

I guess a new version will be online as soon as I finish documenting  
Heaps

and priority queues.


I think all effort should go into writing real documentation within  
the phpdoc cvs module instead of unreadable and unofficial doxygen  
output. Personally I feel the link to the doxygen output should be  
removed from php.net/spl (but won't) so anyway those are my feelings.  
Etienne is planning to work on both, which is great, but I encourage  
everyone to update the official spl documentation and not worry much  
about doxygen.


Regards,
Philip


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

Re: [PHP-DEV] Float comparison

[Philip Olson]

On 2 May 2008, at 18:07, Stanislav Malyshev wrote:

Hi!


Is it not possible to overload operators?
Though this would probably even more work to do.


Well, overloading operators in theory would be less work to do,  
technically, since extension points would be easier to identify.  
However, I'm not sure we'd want to open that can of worms :)


Overloading operators in PHP sounds crazy... so it's possible. :)

  http://pecl.php.net/package/operator

Regards,
Philip

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

[PHP-DEV] Help write the 5.3 upgrade guide

[Philip Olson]

Hello everyone,

It's that time of year again, time to write a PHP migration/upgrade  
guide! It's being created a little differently this time around, first  
wiki then later converted to DocBook and inserted into the manual.  
Please have a look and add/modify the information. Every change is  
worth mentioning so don't be shy:


  PHP 5.3 Upgrade and Migration guide:
  - http://wiki.php.net/doc/scratchpad/upgrade/53

Regards,
Philip

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

[PHP-DEV] magic quotes finale

[Philip Olson]

Hello everyone-

PHP 5.3 is approaching fast, so let's conclude our dealings with  
magical quotes... this should be the last time. Please have a look at  
the following RFC and discuss it within this thread.


  Magic Quotes in PHP 5.3 and beyond
  - http://wiki.php.net/rfc/magicquotes

It recommends changes to both 5_3 and 6_0 branches, namely, removing  
E_DEPRECATED from the get_ magical quote functions. Silence means  
you're okay with the RFC being implemented.


Regards,
Philip

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

Re: [PHP-DEV] magic quotes finale

[Philip Olson]

On 20 May 2008, at 13:53, Pierre Joye wrote:


hi Philip,

On Tue, May 20, 2008 at 9:55 PM, Philip Olson <[EMAIL PROTECTED]>  
wrote:

Hello everyone-

PHP 5.3 is approaching fast, so let's conclude our dealings with  
magical
quotes... this should be the last time. Please have a look at the  
following

RFC and discuss it within this thread.

Magic Quotes in PHP 5.3 and beyond
- http://wiki.php.net/rfc/magicquotes

It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED from the get_ magical quote functions. Silence means  
you're

okay with the RFC being implemented.


We already agreed on restoring them in HEAD but with a warning
(instead of the fatal error introduced by the removals). We still
leave the E_DEPRECATED in 5.3 as it is actually deprecated.


I disagree that we agreed on this, as our last discussion was murky at  
best. Getting and setting are totally different and should be  
clarified as such... the RFC does this.


Regards,
Philip

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

Re: [PHP-DEV] Short syntax for array literals [...]

[Philip Olson]

On 22 May 2008, at 07:29, Pierre Joye wrote:

On Thu, May 22, 2008 at 3:56 PM, Johannes Schlüter  
<[EMAIL PROTECTED]> wrote:

Hi,

On Thu, 2008-05-22 at 12:33 +0200, "Pierre Joye" wrote:

Agreed, we should simply go through a vote and be done with that.


Vote until all are annoyed and don't vote against it anymore just to
stop voting? ("it's less annoying to have it than vote about it every
two months") There was some voting about this feature quite recently,
don't have the archive link at hand.


Really? I missed the conclusion then. But if there was one, let  
begin to count.


Whether something is concluded or not is in the eye of the beholder...  
but it appears the conclusion here is:


 This is too much [unnecessary] magic:
 - http://php.markmail.org/message/k2xoyx5ql65vj6r6

Regards,
Philip


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

Re: [PHP-DEV] magic quotes finale

[Philip Olson]

PHP 5.3 is approaching fast, so let's conclude our dealings with
magical quotes... this should be the last time. Please have a look at
the following RFC and discuss it within this thread.

  Magic Quotes in PHP 5.3 and beyond
  - http://wiki.php.net/rfc/magicquotes

It recommends changes to both 5_3 and 6_0 branches, namely, removing
E_DEPRECATED from the get_ magical quote functions. Silence means
you're okay with the RFC being implemented.


Why should we leave get_magic_quotes_gpc()? If someone wants to be
backwards compatible, just use
if (function_exists('get_magic_quotes_gpc') and  
@get_magic_quotes_gpc())

Let's just add this to the manual, and everything is fine.


We leave it because it's a developer friendly function that people  
use. The checking of this feature is not deprecated, but rather, the  
feature itself is deprecated and will be removed. And asking people to  
update past and present code because we don't want the string  
"magic_quotes" in php-src doesn't sound like much fun.



I don't see a problem with this at all and it has the advantage of
allowing use to remove all the traces of magic quotes in 6. Magic  
quotes

are considered a bad practice for a long time.


That's why good developers check for it, and why we shouldn't punish  
them for that. These E_* errors (and formally proposed removal  
outright) equal punishment. Also note that magic_quotes_gpc is enabled  
by default... even in PHP 5.3. So people have always checked for it,  
and will continue to do so, and we already have get_magic_quotes_*()  
so let's keep it with no E_rrors. Of course setting MQ is a totally  
different story.



cu, Lars
P.S.: Silence agrees doesn't work, silence is void.


In this case all silence would have done is temporarily move the  
conversation to [EMAIL PROTECTED]


Regards,
Philip


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

Re: [PHP-DEV] magic quotes finale

[Philip Olson]

We have covered this a bunch of times already.  magic_quotes_gpc  
are gone,
but we leave in the function that tells userspace code that they  
are off.
get_magic_quotes_gpc() will always return false which means that  
thousands

of applications out there will run unchanged and will simply take the
magic_quotes off code path.


Exactly, what I said in my very first reply to this thread. With all
respects to Philip, this RFC and discussion are pointless, the
solution has been approved and the problem is about to be solved (when
I get two and half mins to apply my patch, probably early next week).



But Rasmus, the patch planned by Pierre will emit errors. Even  
E_WARNING in 6.0. So here's possible upcoming documentation:


  "Checking for magic quotes is deprecated, as is setting them, so do  
neither in your code; else suffer errors."


And:

  "Yes, magic_quotes_gpc is on by default in PHP 5.3 but checking its  
value is deprecated. Instead, assume they are always on or off."


Maybe this makes the point clear to everyone? This is my last plea on  
the subject.


Regards,
Philip


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

Re: [PHP-DEV] Re: Short syntax for array literals [...]

[Philip Olson]

On 27 May 2008, at 19:44, Greg Beaver wrote:


Stanislav Malyshev wrote:

please add your votes

I'm +1.
BTW - how hard would it be to add voting interface to the wiki?


Not hard at all.  Certifying that people only vote once - hard


I vote we don't talk about voting methodology in this thread.

Regards,
Philip

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

Re: [PHP-DEV] Re: Short syntax for array literals [...]

[Philip Olson]

I also re-added the "Discusssion on the Web" section, because it  
reflects what the user base is thinking on this topic.


This section of random blogs is unnecessary especially considering how  
open the lists are to the world. I consider this section to be a bad  
"If I want my voice really heard I'll post a blog entry instead of  
this list, and I'll even get a link out of the deal" precedent.


Regards,
Philip


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

Re: [PHP-DEV] Where is PHP 5 Bug Summary Report?

[Philip Olson]

On 2 Jun 2008, at 07:54, Felipe Pena wrote:


Hi all

Em Seg, 2008-05-26 às 08:18 -0700, Philip Olson escreveu:

On 26 May 2008, at 05:45, Guilherme Blanco wrote:


Hi,

Read the subject...

Have anyone disabled it?


This summary has finally reached 100kb so it's too large for the  
list.

Possible solutions:

 - Close bugs :)
 - Remove the feature request part
 - Remove the (reminders sent) part


What about doing that two last solutions?

http://rafb.net/p/9jAnET10.html


Looks good, I committed something similar that keeps the assigned bug  
information for now so let's see how that goes. It provides a feature  
request count too... there are about 600 of them!


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

[PHP-DEV] deprecation status of $str{42} versus $str[42]

[Philip Olson]

Hello geeks,

This email is to confirm that $str{42} is deprecated in favour of  
$str[42] as of PHP 6. There is some confusion so let's make something  
official here.


A little history:
 - May, 2001: $str[42]: is documented as deprecated since PHP 4
 - Nov, 2005: $str[42]: kept while $str{42} is instead deprecated.  
Discussed:

- http://markmail.org/message/tmvkpknlzfij5k5o
 - Nov, 2005: $str{42}: 5.1 RC5 throws E_STRICT for $str{42} but  
removed before release

 - May, 2006: $str[42]: switches from deprecated to "preferred" in docs
 - Aug, 2006: $str{42}: documentation reads "deprecated as of PHP 6"

Currently it emits no errors when one plan was to deprecate it in PHP  
5.x and remove in PHP 6.0 but that doesn't appear the plan today.


So unless this thread changes something, an E_DEPRECATED will be added  
to HEAD (PHP 6.0.0) for curly brace string access ( $str{42} ) and the  
documentation will remain as is.


Regards,
Philip


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

Re: [PHP-DEV] extensions status, to move to pecl or to drop

[Philip Olson]

/ Un*x: Get a .tar.gz,
unpack, phpize, configure and make (last time I tried that didn't  
work for

me, must've been some wrong auto-whatever).


If the release is done correctly, a simple pecl install sybase works.


This is an important point because unfortunately in the past a "moved  
to PECL" was theoretical. Instead, if it meant the moved extension  
could be found at pecl.php.net/extname, have its own bug category, and  
be installable via the pecl command... the word "PECL" would be a lot  
less scary. And it's worth noting that Pierre will release the  
extensions mentioned in this thread so they won't be hidden in the  
pecl CVS module.


And on a related note, have we considered any sort of fetch  
integration with configure? You know, like --with-apc would grab it  
much like 'pecl download apc' does today. Or more likely a trigger,  
like --with-apc=fetch,beta ... you get the idea. A friendlier this[1].


Regards,
Philip

[1] http://php.net/install.pecl.static


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

Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP

[Philip Olson]

.
Anyway, feel free to comment.


Should comments from user-space folk be posted here or as comments  
at the

bottom of the wiki page?


We're all users... so here.

Regards,
Philip

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

Re: [PHP-DEV] cleaning up the functions - any volunteers?

[Philip Olson]

While we nearing the release of 5.3 (hopefully?), there are many
functions in the PHP code which still use old parameter parsing API
(zend_get_parameters_ex) instead of the new one  
(zend_parse_parameters).




Yeah, I have noticed... That's also in my TODO.


Where is the Felipe fan club signup sheet?

Regards,
Philip

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

Re: [PHP-DEV] towards a 5.3 release

[Philip Olson]

On 2 Jul 2008, at 14:38, Johannes Schlüter wrote:


On Wed, 2008-07-02 at 22:24 +0200, "Hannes Magnusson" wrote:
On Wed, Jul 2, 2008 at 22:00, Lukas Kahwe Smith  
<[EMAIL PROTECTED]> wrote:
@Philipp: Since you are the god of documentation .. How are things  
looking

on the scratchpad [8] you started?


Philip, one p, recently moved to Nicaragua (last weekend actually)  
and

isn't really "available" these days :)


Nice :-)


Indeed! :)


Furthermore I haven't seen Nuno for a while and "you guys" stole
Felipe from "us" and I recently found out that school is heckofalot
easier than work :]

So... any and all help in the documentation area would be  
appreciated.

The scratchpad wiki page is a good start, but I doubt these are the
"only" changes/new features in 5.3...
Of the top of my head; a list of error changes (especially
functions/features now throwing E_DEPRECATED) is missing...


Also the changes to zend_parse_prameters() should be checked for tiny
changes (like the current()/next() changes already documented on that
wiki page)

Help from any lurker here is appreciated!



Essentially the plan is to DocBookify it once 5.3 nears release but  
today that page requires additional content. Random people add content  
randomly and unfortunately I'm no longer able to lead this effort so  
please take over the task of 5.3 upgrade docs procurement. I'll move  
it to DocBook if/when needed. In other words, to something similar to http://php.net/migration52


 Wiki: http://wiki.php.net/doc/scratchpad/upgrade/53

As for integrating 5.3 goodness into the PHP manual itself, most  
features are folded within. All are welcome to edit the CVS module  
named phpdoc and today only a recent PHP release is required (no make/ 
xsltproc/etc.) Or write an email, post a simple text file, and/or edit  
the wiki page. Also, thanks to all who use the [DOC] tag!


And lastly, ideas are welcome for dealing with the current style as  
we'll end up having the following separate migration guides:


  5.0 -> 5.1
  5.1 -> 5.2
  5.2 -> 5.3

Not a terrible problem but it's something to think about at [EMAIL PROTECTED] 
.


Regards,
Philip



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

Re: [PHP-DEV] PHP 4.4.9

[Philip Olson]

On 7 Jul 2008, at 14:00, Rasmus Lerdorf wrote:


Derick Rethans wrote:

On Mon, 7 Jul 2008, Marcus Boerger wrote:

 how about this. We edit php_config.h to be version 4.4.8pl1. Then
provide a patch for download. All reasonable distributions will  
pick up
that patch anyway. But at least we didn't do a release as we  
promised, we

wouldn't.
Uh, no. We didn't promise we wouldn't make releases. It clearly  
says that if there are security issues we look at them case-by-case  
to see if we should make a release. There are security issues, we  
make a release. There is nothing more to discuss about this.


We did actually.  The exact text from the announcement was:

 After 2007-12-31 there will be no more releases of PHP 4.4. We will
 continue to make critical security fixes available on a case-by-case
 basis until 2008-08-08.

The two statements do contradict each other a little bit, and I am  
ok with another release, but technically Marcus is correct.


However, to further extend our analysis of past writings... the  
following is taken from the 4.4.8 release announcement[1]:


 "... This release wraps up all the outstanding patches for
 the PHP 4.4 series, and is therefore the last normal PHP 4.4
 release. If necessary, releases to address security issues
 could be made until 2008-08-08."

This indicates a potential future release.

Regards,
Philip

[1] http://news.php.net/php.announce/72


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

[PHP-DEV] Re: Commit messages dead?

[Philip Olson]

Hello all,

An online editing mechanism was discussed and started[1] but let's be  
honest here and stare at the larger problem. The documentation team is  
on extended holiday and why? I don't know... maybe it's cyclical? Or  
maybe we need a larger marketing budget. But really if making it  
easier to inject words into the manual is seen as the main problem  
here then great, that sounds easy to fix, but writing good  
documentation is time consuming and I guess many humans prefer not  
doing it at all even though it's an art too. But maybe removing the "I  
don't have time to setup/test yet another tool chain" excuse is a good  
start. The new doc build system has gone a long way to do this.


We recently reviewed the doc TODO situation and one of the first tasks  
is streamlining the HOWTO because it's a bit lengthy and dated. As for  
the required tool chain it's not too difficult anymore, and DocBook  
knowledge and special tools are not needed except to know XML   
is like a  in HTML. Basically. Almost.


The online editor thread with demo:
  [1] http://markmail.org/message/xchvvhk4hlvg33a3

Regards,
Philip


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

Re: [PHP-DEV] About dropping magic_quotes in 5.3 (was: Re: [PHP-DEV] Re: PHP 5.2.7 + magic_quotes_gpc broken)

[Philip Olson]

On 8 Dec 2008, at 08:18, Hannes Magnusson wrote:

On Mon, Dec 8, 2008 at 16:57, Pierre Joye <[EMAIL PROTECTED]>  
wrote:
On Mon, Dec 8, 2008 at 4:47 PM, Johannes Schlüter  
<[EMAIL PROTECTED]> wrote:


When dropping magic_quotes the hosting company can do one of two  
things:


a) not update to 5.3 so we either have to maintain 5.2 for some  
time or

let them have problems


+1


We cannot simply nuke a feature that was once upon a time sold as a
security feature, and is still enabled by default, just "out of the
blue".


Agreed, going from on by default to removed just feels odd.

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

Re: [PHP-DEV] Is Empty functionality to the Directory Functions

[Philip Olson]

Oh and I should to sit down over the holidays and write examples for
the SPL Directory functions and send over to the documentation team.


The email address for that task is php...@lists.php.net :)

Regards,
Philip


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

Re: [PHP-DEV] Re: Bug #40698 Re-use search term in the quicksearch input field

[Philip Olson]

Greetings Josef,

Nice, you're already looking at code and proposing patches! :)

My first patch (very easy). I have one more idea about this. The  
text

will stay in intputbox only if not found. What do you think ?
Bug is mentioned here : http://bugs.php.net/bug.php?id=40698


Seems logical, except bugsweb has a clean() function that should be  
used when presenting user data. However, I would prefer we mark the  
bug as Won't Fix and suggest these users use the advanced search  
instead.



I was studying bug tracker code, because of GSOC. I want to join one
idea about bug tracker (improve him). Now, I'm searching for some  
bugs

in tracker to repair. So next patches will be posted soon.
If anyone know some bug or have some idea connected with improving
bugtracker please write me.


As we previously discussed in private, scouring the list archives (and  
wikis) for peoples ideas and coming up with a simple plan seems the  
best way to go. We don't need a complete rewrite but some change (and  
clean up) is needed. Whether we take this opportunity to combine PECL  
(and GTK) I'm not sure but let's discuss it.


Regards,
Philip

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

Re: [PHP-DEV] Bug tracker code refactoring

[Philip Olson]

Greetings Josef,

Most people on this list have no desire to look at or work on the bug  
tracker code, so it's a good idea to not ask questions about it here.  
I'm volunteering to mentor you [if your gsoc application is accepted]  
so as such please either write me or for global discussions write the  
php-webmaster@ list. Sorry I wasn't clear about that earlier.



I have one question. I'm writing bug tracker README file. There is
config.php with MySQL access parametrs (only), but the code is not
using them. So i replaced all parametrs in mysql_connection and
mysql_select_db functions used in code. Now I can simply write into
README file something like : create mysql tables using bugs.sql, edit
config.php file with your mysql access ...


Sounds good so far. Also, the DEVBOX constant and perhaps an email  
address or three.



But there is one problem. Bug tracker have few files in include folder
(config.php also), but in code is used only (for example) require_once
"prepend.inc" (prepend.inc is in include diretory too). So there
should be include folder in php path (or tracker is not working -
can't find those files). Is better to write into the README, that
include folder must be in php path or to rewrite require_once
parameters (using DIRECTORY_SEPARATOR constant and path to include
directory) ?


It's better to not force developers to adjust their master  
include_path directive.


Regards,
Philip


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

Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?

[Philip Olson]

Today this topic may be the cloudiest and most heated in all of PHP.  
Here's the factual history of our poor little short_open_tag directive:



php.ini values : short_open_tag


PHP 4, 5_0
 * Default behaviour   : on
 * php.ini-dist: on
 * php.ini-recommended : on

PHP 5_1, 5_2:
 * Default behaviour   : on
 * php.ini-dist: on
 * php.ini-recommended : off

PHP 5_3:
 * Default behaviour   : on
 * php.ini-development : off
 * php.ini-production  : off


php.ini descriptions : short_open_tag


In 5_2 our reason for discouraging it is:

; - short_open_tag = Off   [Portability]
; Using short tags is discouraged when developing code meant for  
redistribution

; since short tags may not be supported on the target server.
; Allow the  tags are  
recognized.
; NOTE: Using short tags should be avoided when developing  
applications or

; libraries that are meant for redistribution, or deployment on PHP
; servers which are not under your control, because short tags may not
; be supported on the target server. For portable, redistributable code,
; be sure not to use short tags.

In 5_3 it's:

; This directive determines whether or not PHP will recognize code  
between
;  tags as PHP source which should be processed as such. It's  
been
; recommended for several years that you not use the short tag "short  
cut" and
; instead to use the full  tag combination. With the wide  
spread use
; of XML and use of these tags by other languages, the server can  
become easily
; confused and end up parsing the wrong code in the wrong context. But  
because
; this short cut has been a feature for such a long time, it's  
currently still
; supported for backwards compatibility, but we recommend you don't  
use them.




This history strongly suggests PHP is hoping and subtly forcing the  
world to stop using this directive, and although it's not deprecated  
the wording and treatment makes it feel it could be any day now. This  
situation must be clarified before 5_3 is released, and will likely  
require our BDFL to do it.


In related news, what came of this RFC? It still says "Under  
Discussion":


  - http://wiki.php.net/rfc/shortags

Regards,
Philip



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

Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?

[Philip Olson]

PLEASE, let the dead horse be!


Apparently, this horse is not as dead as some would like it to be :)


The horse is not dead or if so then no proper burial service was  
given. People are still waiting for the invitations and wanting to  
hear the eulogy.


So, instead I'll make the following assumptions and engrave them into  
this topics tombstone:


 - short_open_tag is fully alive
 - short_open_tag is PHP_INI_SYSTEM|PHP_INI_PERDIR
 - all distributed php.ini files disable it (5.3+)
 - the default will be enabled, forever, unless #5 is used
 - --disable-short-tags will exist, forever
 - no new alternative syntax will be implemented, ever

That's the situation people should understand and since this horse is  
considered dead I will:


 - update php.ini ini descriptions to reflect this
 - update documentation to reflect this
 - mark http://wiki.php.net/rfc/shortags as declined
 - point to the declined rfc when people suggest these alternatives

All discussion is over unless a human knows the above synopsis is  
false, because CVS has spoken. RIP.


Regards,
Philip


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

Re: [PHP-DEV] Re: [PHP-WIN] RE: [PHP-DEV] Re: Win32 PECL pre-built binaries.

[Philip Olson]

It seems like this isn't going to be fixed any time soon.

220 extensions which may have version specific external libraries and
each one needing to be built at least 20 ways (VC6/9, ts/nts,
5.0/5.1/5.2/5.3/6.0). That gives 4,400 build processes. Debug? 8,800
builds. And then more if there are different external libraries,
though I would hope that a version of a PECL extension would only run
with a single version of an external library. I don't know if the
dependencies are maintained in any easy way.

Compare that with PHP's handful of builds.



DLL downloads will be offered at pecl.php.net for active PHP branches  
(5_2, 5_3, 6_0).


However, this does not exist today so yesterday I removed all  
references to pecl4win from the PHP manual and referred to the "build  
it yourself" documentation. If the documentation is wrong/outdated  
then please report a bug.


Regards,
Philip


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

[PHP-DEV] Re: Win32 PECL pre-built binaries.

[Philip Olson]

If the documentation is wrong/outdated then please report a bug.


I notice that every time someone files a bug about the broken links  
in the "Building PHP for Windows" documentation, a PHP developer  
closes the bug and says to follow the Wiki notes instead (http://wiki.php.net/internals/windows/stepbystepbuild 
) which are unfortunately not complete...hence my confusion.


I see one such bug, are there others?

  - http://bugs.php.net/bug.php?id=46021

In the very least the "Building PHP for Windows" section should not  
include broken links, so, this bug has been reopened.


Regards,
Philip

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

[PHP-DEV] Re: [PHP-WIN] Re: Win32 PECL pre-built binaries.

[Philip Olson]

I see one such bug, are there others?
 - http://bugs.php.net/bug.php?id=46021


Here are some:


Duplicate bugs are given the bogus status and typically link to the  
parent bug. Looks like that happened a few times here, but the bug  
evolved and was prematurely closed. It's open now. Windows geeks,  
please look into bug #46021 and close it. If it's not closed by Friday  
(when the manual builds) I'll address [hack] it the best I can.


I can see why some people were against us having a wiki because these  
'where is what when how?' problems become more frequent. But as for  
the Windows build stuff, I consider the manual to be documentation and  
the wiki entry a supplemental to it.


And as for the Windows PECL binaries, this large task could use more  
bodies so people feel free to help. Pierre, please post an update/todo  
regarding this task so we all know about it and how to help.


Regards,
Philip


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

Re: [PHP-DEV] Is there a technical reason

[Philip Olson]

On May 18, 2009, at 5:33 PM, Roman I wrote:

From what I know, in the future versions of PHP short tags are going  
to be

disabled by default.



Common misunderstanding but the short_open_tag directive will never be  
disabled by default. There are distributed php.ini-* files that  
disable them, but those don't contain default values.


Regards,
Philip


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

Re: [PHP-DEV] How to contribute for PHP Internals

[Philip Olson]

Great topic... a few thoughts:

- Internals documentation

This task needs volunteers. Ideally a mix of people who have either  
no, some or enormous knowledge of internals but all with desire to  
both learn and teach it. Gwynne started the task but ran out of steam  
(life and the svn migration got in the way) but some good content  
exists. But, this is its own topic. Volunteers please email me and  
let's organize a hackfestish type event.


- Bug tracker as a starting point

The idea of intentionally creating nice bug reports for fairly simple  
non-critical issues, and promoting these as tasks for new people  
definitely sounds worth the extra effort. All ideas for how the bug  
tracker could help with this are welcome.


- A "Get Involved" guide

Some nice thoughts in this thread, and similar ones for a _rough_ TOC  
here:


  - http://wiki.php.net/doc/scratchpad/wheretohelp

The basic idea is to create and promote a "Get Involved" section. To  
digress, awhile back while thinking about this (and wondering how the  
php.net project survives without it) I stumbled around and started a  
different yet related project:


  - http://teachingopensource.org/index.php/Teaching_Get_Involved

The plan is to learn how best to approach this topic and then apply it  
to php.net. If people are interested in working on this or only  
php.net specific parts then please let me know. So what that it's  
taken us 10 years to write a nice "Get Involved" guide, but at least  
we now have several resources to learn [steal!] ideas from while we  
create our own :) Common problems like repeated, lost and outdated  
content can no doubt be overcome.


Regards,
Philip



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

Re: [PHP-DEV] Is there a technical reason

[Philip Olson]

On May 30, 2009, at 12:49 PM, Roman I wrote:


Philip Olson wrote:


On May 18, 2009, at 5:33 PM, Roman I wrote:


From what I know, in the future versions of PHP short tags are going
to be
disabled by default.



Common misunderstanding but the short_open_tag directive will never  
be

disabled by default. There are distributed php.ini-* files that
disable them, but those don't contain default values.


This neither answers nor invalidates the original question, though.


Unfortunately I do not remember everything about this but do know that:

  - Decoupling happen
  - Allowing it to be enabled at runtime was discussed, and did not  
happen

  - The issues with I've not read every thread or discussion on this (there are many) but  
CVS speaks for itself. Here's one thought comparing the two viewpoints:


  - http://marc.info/?l=php-internals&m=120614525214419&w=2

The following RFC mentions this decoupling, yet was declined:

  - http://wiki.php.net/rfc/shortags

And lastly, the general topic of short tags came up recently while  
several people discussed PHP 6:


  - http://wiki.php.net/summits/pdmnotesmay09

In summary: It's a topic people don't want to talk about. :)

Regards,
Philip


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

Re: [PHP-DEV] Compiling 5.3 Snap on OS.X (embed & static/shared compile issue)

[Philip Olson]

My issue:

 ld: duplicate symbol _spl_ce_SplDoublyLinkedList in ext/spl/.libs/ 
spl_dllist.o and ext/spl/.libs/php_spl.o

 collect2: ld returned 1 exit status
 make: *** [libphp5.la] Error 1


I can confirm the exact same error after "./configure --enable-embed"  
but know nothing beyond that.


Regards,
Philip

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

Re: [PHP-DEV] Is there a technical reason

[Philip Olson]

On Jun 5, 2009, at 12:53 AM, Rasmus Lerdorf wrote:


Hannes Magnusson wrote:
On Fri, Jun 5, 2009 at 07:47, Rasmus Lerdorf  
wrote:

Nobody is going to pass a PHP script through an XML parser, and PHP
itself will never be well-formed, so that is a lost cause.  We'd  
have to

start tossing CDATA blocks and write code like:

if( 2 < 3 ) echo "2 is less than 3";


No you don't. & and < are perfectly legal in PIs


And that just isn't going to happen.  The only valid argument  
against
short_tags itself is that it clashes with named PI tags and does not

have that same problem.




The point still stands.  If you are trying to parse PHP with an XML
parser, you are doing it wrong.  I have absolutely no problems  
annoying

the one or two pedantic people who care about this for the benefit of
thousands who don't.


The RFC was marked declined due to repeated discussions and lack of  
change, but declined without much fanfare or official yay or nay  
discussion aside from a mention in a recent related thread, IRC, and  
CVS.


So it feels like decoupling Rasmus or Stas, could you please propose exactly how this might  
happen? Like when, and if the fate of short_open_tag would be affected  
(which is never deprecate nor disable by default).


And while few want to talk about short tags (again), it's worth noting  
that a discussion specific to decoupling really hasn't taken place  
except for silence and a few "yeah, that might be alright... sometime"


Regards,
Philip


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

[PHP-DEV] A 5.3 UPGRADING guide update

[Philip Olson]

Hello everyone,

The wiki entry[1] titled "PHP 5.3 upgrading notes" should no longer be  
edited, because it's been replaced by UPGRADING[2] within the PHP_5_3  
branch.


Today I synced and updated UPGRADING assuming that:
 - The UPGRADING file added on Jan 28 17:23:28 2009 UTC was fully in  
sync with the wiki around that date
 - Since then, people added all noteworthy changes to at least one of  
these locations (not forgotten)


I am not searching through NEWS or CVS to find additional entries for  
UPGRADING (or vice versa) but am creating an upgrading guide for the  
PHP Manual similar to the 5.2 guide[3].


Regards,
Philip

[1] http://wiki.php.net/doc/scratchpad/upgrade/53
[2] http://cvs.php.net/viewvc.cgi/php-src/UPGRADING?view=markup&pathrev=PHP_5_3
[3] http://php.net/migration52


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

Re: [PHP-DEV] set_magic_quotes_runtime is still E_DEPRECATED

[Philip Olson]

On Jun 16, 2009, at 11:59 AM, Stefan Walk wrote:



On 16 Jun 2009, at 20:49, Lukas Kahwe Smith wrote:


1) its not about "punishing", its about alerting people that they  
are relying on stuff that will go away
2) E_DEPRECATE is for development only and only as a check you  
enable now and then

3) its off in both of the php.ini's we will ship with 5.3



IMHO, if the setting is consistent in both php.inis, the no-ini  
behaviour (default value) should be the same ...


PHP no longer ships a php.ini file that adheres to default values,  
which is something php.ini-dist did in the past. In most (all?) cases,  
the default differs for BC reasons.


Regards,
Philip

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

Re: [PHP-DEV] CVS Account Request: bobby

[Philip Olson]

Hello all!

Please create this CVS account with phpdoc karma. Thanks!

Regards,
Philip


On Sep 1, 2006, at 8:15 AM, Bobby Matthis wrote:


Hello There,
My name is Bobby Matthis and I would like to be granted a CVS  
account to help maintain the user notes on the PHP Manual.  I am a  
very passionate PHP programmer and just want to help out the PHP  
movement any way I can.  I am a Zend Certified Engineer and I have  
a little over 2 years of PHP programming experience, but I do know  
that I still have a lot to learn.  Even if all I am doing is  
helping clear out some of the SPAM postings, Bug postings, etcI  
at least know that I am helping out where I can.  I assure you that  
if granted a CVS account, I will use it only for good.  I hope that  
you will see and agree that this is something that I really want to  
do.


Thank you to all of you that have been so helpful and for your  
direction.  Your hard work on the php documents may not get you a  
lot of praise, but it is much appreciated!  I just want to show my  
appreciation by helping with what I can.


--
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] Module API Changes

[Philip Olson]

Erm, no they aren't in the upgrade guide, because the upgrade  
guide is aimed
at user issues and this was seen primarily as an extension author  
issue. Do
people generally think the module and extension API bumps should  
be in

there?


Rasmus was talking about the internals change and ask if they can be
put in this file. I think it is a very good suggestion and no, I did
not have the time (and will not in the next 10 days) to do it :)


And a FYI, the documentation team has decided to create migration  
pages for minor releases of PHP and will use these README files as a  
base for this documentation. Before only major versions were  
documented this way. All should feel free to contribute to these  
docs :-)


Regards,
Philip

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

Re: [PHP-DEV] RSS feed for bugs.php.net

[Philip Olson]

Do we have an RSS feed for bugs.php.net? It would really help  
maintainers
keep on top of bugs opened for their extension as email isn't great  
because

a lot of it gets filtered into the generic PHP Bugs folders :)



There are a couple of unadvertised files here:

http://bugs.php.net/rss/

Since /search.php and /rss/search.php take the same arguments,  
perhaps /search.php results should link to /rss/search.php


Regards,
Philip

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

Re: [PHP-DEV] an configure option to "enable-all"

[Philip Olson]

On Sep 17, 2012, at 8:30 AM, jpauli wrote:

> On Mon, Sep 17, 2012 at 2:48 PM, Hannes Magnusson
>  wrote:
>> On Mon, Sep 17, 2012 at 9:59 AM, jpauli  wrote:
 
 I'm confused.. --enable-all is already supported, just like --disable-all ?
 
 -Hannes
>>> 
>>> AFAIR no :) We have a --disable-all , but no --enable-all.
>>> 
>>> I'm +1 to add such an option if possible :)
>> 
>> 
>> Can you please explain to me how it is not working?
>> 
>> ~/Sources/php/php-5.3 (PHP-5.3) $ ./configure --enable-all
>> configure: error: Cannot find enchant
>> 
>> And no, ext/enchant is not enabled by default.
> 
> So the answer is : there is --enable-all switch , but it's not listed
> in the --help output

Hello all,

Interesting, I didn't think it existed but now realize why. It's not
documented and it's not very useful.

There's an old feature request (I wrote it so am surprised I forgot
this exists) about differentiating between --with and --enable, 
along with checking if those are actually available on the system:

  https://bugs.php.net/24337
  https://bugs.php.net/33186

Awhile ago Rasmus mentioned an idea about creating a shell script that'd
check which options do (and do not) pass configure. I'm not sure how to 
do that but maybe someone else does. Just imagine being able to enable
all possible extensions available on a system.. great for 'make test' :)

As for the original question, yes you can do that. For example, this
will enable all extensions except for enchant:

  ./configure --enable-all --without-enchant

Much like --disable-all allows enabling specific extensions:

  ./configure --disable-all --with-enchant

Regards,
Philip




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

Re: [PHP-DEV] Incomprehension with preg_match and utf8

[Philip Olson]

On Nov 5, 2012, at 8:55 AM, Rasmus Lerdorf wrote:

> On 11/05/2012 08:41 AM, Jean-Sébastien Hedde wrote:
>> On Mon, 05 Nov 2012 08:04:06 -0800, Rasmus Lerdorf 
>> wrote:
>>> 
>>> I think the documentation is wrong on that. In Unicode mode [[:alnum:]]
>>> actually becomes \p{Xan} which should match Unicode chars as well, but
>>> only if PCRE was compiled with Unicode support. So I suspect you don't
>>> actually have a Unicode-capable PCRE build in some cases there.
>>> 
>>> -Rasmus
>> 
>> I will report the bug to the package maintainers (remi, debian too...).
>> 
>> Is there anyway for us to avoid those "wrong" builds ?
> 
> I don't see how.


Hi geeks,

Does anyone have a suggestion on how the documentation should be
updated? The quote is from here:

  http://php.net/manual/en/regexp.reference.character-classes.php

With the quote being:

  "In UTF-8 mode, characters with values greater than 128 do 
   not match any of the POSIX character classes."

A few simple/related facts:

  - PCRE_UCP exists as of PCRE 8.10
  - Gustavo mentioned the related PHP change on Oct 3, 2010 (not sure 
what PHP version, and googling for "87a237342" turns up empty, 
and I miss SVN version numbers)

Anyway, how should this be documented?

Regards,
Philip


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

Re: [PHP-DEV] RFC: ext/mysql deprecation

[Philip Olson]

> The main argument is that we haven't actually made it clear in the
> manual that the extension is going to be deprecated. There is a user
> note on http://www.php.net/manual/en/book.mysql.php and a "This
> extension is not recommended for writing new code" on
> http://www.php.net/manual/en/intro.mysql.php
> 
> As Anthony mentioned, this is a very weak best-practice type of message
> that we are only barely whispering here. To go from that to start
> throwing deprecation warnings on what is perhaps the most heavily used
> PHP extension ever is a rather drastic step. Your argument seems to be,
> "Well, there is no point documenting it because people won't read it
> anyway", which may be true, but we haven't actually tried that yet and
> for something like this I think it should be the first step.


I wanted to clarify that it was intentional to not use the word 
"deprecated" in the documentation because it's not deprecated. However, 
the documentation for *every* ext/mysql function begins with a pink box 
that says it's discouraged, and these boxes suggest alternatives via 
mysqli/pdo_mysql.

Whatever the case, we'll update the documentation now. It'll clarify that
one day this extension will be deprecated. The only question here is the 
"how" and "when" but that's not a showstopper for the docs.

As for the ext/mysql->mysqli conversion script. It's outdated and difficult 
to find but we'll make an official php.net version and promote/update it so 
eventually it'll become awesome. It's certainly not ready today. I suspect
people will also want an ext/mysql->pdo_mysql version. No promises there… :)

Regards,
Philip


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

[PHP-DEV] Where did the _logo_ functions go?

[Philip Olson]

Hello geeks,

Why does PHP 5.5 remove the *_logo_* functions? Is this a security 
related move? Shouldn't these emit E_DEPRECATED errors in 5.5?

Regards,
Philip

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

Re: [PHP-DEV] RFC: ext/mysql deprecation

[Philip Olson]

On Nov 16, 2012, at 12:55 AM, Rasmus Lerdorf wrote:

> On 11/16/2012 12:51 AM, Patrick ALLAERT wrote:
>> Rasmus,
>> 
>> As per the RFC: adding E_DEPRECATED only in mysql_connect(),
>> mysql_pconnect(). Which means only one error (normally) by request.
> 
> I still don't see the point of using E_DEPRECATED like this for an
> entire extension. And I think it will hurt more than it will help for an
> extension this heavily used. It is going to encourage people to simply
> turn off that warning because they will get it on every single request
> which means they will never see the more subtle and granular
> E_DEPRECATED warnings from other parts of their code.

Most front page google results for "E_DEPRECATED" are questions about 
how to hide these errors. This thought has put me over the edge and 
into the land of not having E_DEPRECATED for ext/mysql in 5.5. Let us 
prepare for this first as we are not ready. Seriously, we are not ready.
And it makes me wonder about "E_DEPRECATED" as a whole.

But this seriously makes me wonder if we should add something like 
how_do_i_make_my_code_more_awesome(). That may look insane (well, the
function name is) but imagine it saying "Stop using ext/mysql" and
then users hear about this, run it, and ask Wordpress "Dude, this
would be more awesome without ext/mysql" and so on. Brainstorming. :)

Regards,
Philip

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

Re: [PHP-DEV] Where did the _logo_ functions go?

[Philip Olson]

Thanks everyone, I didn't remember thinking about this so was 
impulsively curious. Dug a little now, so here's what happened:
 
  Proposal to internals (July 14, 2012) with discussion July 14-18:
  --
Thread: http://markmail.org/thread/kewdoz3dowrr7rfv

Summary:Seemed okay, discussed more "how" than "why", and 
more "yes" than "maybe" approved. 
Conclusion: No clear decision was reached.

  The patch: 
  --
Patch: https://github.com/php/php-src/pull/132
Pull:  http://git.php.net/?p=php-src.git;a=commitdiff;h=c9eb641

Summary:Mostly a technical/patch related discussion there, 
several tweaks, then pulled.
Conclusion: Merged/pulled into master on August 4, 2012.

  What happened:
  --
- The PHP logo GUIDs were removed, and replaced with data URIs 
  in phpinfo() and friends.
- BC: Removed four *_logo_* functions, and GUID usage.
- E_DEPRECATED was not used beforehand, nor doc updates, they 
  were simply removed. FWIW, also no RFC.

It's understandable how a minimally used feature can be changed and 
removed without much worry/thought. But, they appear to be the only 
functions removed in 5.5, and this helps it feel even easier to not 
break BC for this not-so-important change. 

Proposal: I propose we revert this change. Future consideration might 
include E_DEPRECATED for these functions in 5.5, although I am not 
proposing that part. Seems sensible, though.

Regards,
Philip


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

Re: [PHP-DEV] Where did the _logo_ functions go?

[Philip Olson]

On Nov 20, 2012, at 10:34 PM, Stas Malyshev wrote:

> Hi!
> 
>> The issue I have with this is just that we don't seem to be making
>> much of an effort to stick to the promises we've made around BC when
> 
> We make a lot of effort to do this. But it does not mean we should be
> blindly and stupidly following the rigid rules even when it makes zero
> sense in practice.

We made sense, and are not being blind and stupid. You may disagree but
I don't understand why this discussion has to become so harsh.

>> it doesn't suit us to. I agree: in practice, I can't imagine anyone
>> caring a jot about these functions being removed, but we've said that
>> when we're going to remove something, we'll deprecate for a minor
>> release, then remove. Why don't we live up to it?
> 
> Exactly because in practice it is not important. So on one side, you
> have making PHP better without any practical downside. On the other
> side, you have delaying making PHP better, but feeling good about
> strictly following bureaucratic rules. I prefer the former.
> 
> Rules are important, but it is also important to not lose the sight of
> the goal - why these rules exist and when they make sense. And when they
> don't.

It's the inconsistency that bothers me. I think a rule like "Never remove
a ~function without it first emitting E_DEPRECATED" can be followed 100% 
of the time, and don't see this as a bureaucratic rule but instead think
this consistency would make PHP better.

Regards,
Philip


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

Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5

[Philip Olson]

On Nov 28, 2012, at 2:08 AM, Pierre Joye wrote:

> hi,
> 
> On Wed, Nov 28, 2012 at 10:55 AM, Alexey Zakhlestin  
> wrote:
>> I voted "no", "(b)"
>> We should mention deprecation in manual as hard as possible, we should
>> mention it in ext/mysql/config.m4 and any other place we can reach.
>> Then, at some point (I'm fine with 5.6, but 6.0 would do also), we
>> should just move it to PECL, without using E_DEPRECATED
> 
> That's exactly why we should use E_DEPRECATED now and not in 5.x+1.
> Also no way to kill it in 5.x, that would be worst than anything else.

The idea of adding E_DEPRECATED now, and then removing it in PECL, is
not an opinion held by everyone.

> That being said, let not start this thread, every argument has been
> mentioned many times already. Let vote.

The idea of moving it to PECL is not represented in the vote. But
it's something to consider as it's a real possibility. It could 
both symbolize that we are serious about not using ext/mysql, and 
considering most Linux distros would simply switch to offering the 
PECL version, it'd probably not break much. Worth thinking about, 
at least.

I'm not yet certain what we should do but this PECL topic is 
intriguing. Hopefully a few others will weigh in with their related
thoughts.

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

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

[Philip Olson]

On Mar 7, 2013, at 1:00 PM, David Soria Parra  wrote:

> On 2013-03-07, Rasmus Lerdorf  wrote:
>> On 03/07/2013 09:01 AM, Anthony Ferrara wrote:
>> 
>>> So my proposal is to slow down for a minute and not call this RFC
>>> accepted or not until we can come to some consensus as to if it
>>> classifies as a language change or not... Better to clarify for the
>>> health of the project than to plow through and risk causing further
>>> strife...
>> 
>> And how do you propose we do that? Vote on it? Will that vote need 2/3
>> as well? I think most of us accepted that language-level changes meant
>> syntax changes. Things that add new features to the language itself.
> 
> I think the only thing requiring a 2/3 vote would be the decision on
> wheather to enable it by default or not. As long as it's in ext/
> and not enabled a 50% should be sufficient.

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

This makes PHP better. Please, PHP, add it to 5.5. 

Regards,
Philip


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

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

[Philip Olson]

On Mar 7, 2013, at 1:58 PM, Anthony Ferrara  wrote:

> 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).
> 
> Either we stick to the rules, or we throw them out and install a BDFL.
> Either way, I don't care. I just think the current
> they-sometimes-matter-depending-on-who-and-when-it-is-raised stance is
> deeper than BS, it's dangerous and is actively turning away contributors
> (as well as harming the project)…


Hello Anthony,

Good points. And the vague release/voting RFCs also contribute to this.

And FWIW, I think PHP needs a BDFL, but we'll have to convince the one 
potential candidate to agree. :)

Regards,
Philip


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

Re: [PHP-DEV] PHP 5.3: Is the use of {} to access string offsets deprecated?

[Philip Olson]

On Jul 6, 2009, at 9:00 AM, Christian Schneider wrote:

The migration guide states that "The use of {} to access string  
offsets

is deprecated.  Use [] instead." but the code in zend_compile.c is
commented out with #ifdef ilia_0.

What's the take on this? Will it be deprecated later or should that  
part

be removed from the migration document?



It's been awhile but I once researched this, spoke with humans, and  
determined this syntax is deprecated as of PHP 6 and documented[1] it  
as such. However, that was almost three years ago so maybe the times  
have changed.


Regards,
Philip

[1] 
http://php.net/manual/en/language.types.string.php#language.types.string.substr


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

Re: [PHP-DEV] Type hinting/casting request for vote

[Philip Olson]

I would like to ask all developers to voice their opinions of  
whether it makes sense to add this to 5.3 or to throw it away  
(either one is fine btw). To keep the process simple & flamewar  
free, please restrict yourself to +/- (1/0), next week monday I'll  
run a tally of the votes and based on the result we can determine  
how to proceed further.


I'm struggling here but must emit -1 because PHP does not add features  
within point (5.3.x) releases, especially those affecting syntax like  
this. But if this philosophy changes, then also add traits. :)


Regards,
Philip


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

[PHP-DEV] bug tracker planning

[Philip Olson]

The bug system today works fine but improvements are being made. I've  
gone through the lists and details from past attempts and will list  
ideas here. Please do not vote, but if a particular item appears like  
a bad idea then please explain. Or, discuss additional (or modified)  
ideas that will be useful to the PHP project.


The new system[1] is based off the pear.php.net bug system (via Jani),  
which long ago was a fork of our current (bugs.php.net). Because of  
this, some of these items are already available via the pear geeks.  
The plan is to have one bug tracker that includes PEAR+PECL+Core+GTK 
+Etc. It's also planning to go live after Stage #1 is completed, and  
also Jani and 2009 GSoC student Felipe Ribeiro are working on this  
project. Soonish a test system will be setup for all to break. Yes,  
this really is happening.


Most people like the current system because it's simple, and I don't  
foresee this changing.


First stage:
- Cleanup code (in progress)
- Attachments : For a diff, test, backtrace, screenshot, whatever.  
(done)
- Package/Type separation : Packages (like extensions) and Bug Types  
(like feature requests) are separate (done)
- Defined/Documented permissions : For example, so we all know if a  
random person can comment on a bogus bug

- Preview button, instead of only submit (almost done)
- Deal with bug id clashes from current PECL/PEAR/PHP bug trackers,  
and associated links

- Importing
- Testing

Second stage:
- Additional history : When a bug was opened/closed etc. Currently we  
don't log this except in emails
- Reclassification : Discuss how we handle this, like should old/new  
lists both receive emails?

- Consider different captcha (like reCaptcha) for anonymous users
- Voting : Do we use or care about this? Improve?
- nofeedback improvements : People assume this means closed, when it  
does not


Third stage:
- Subscriptions : Allow people to subscribe to RSS and/or receive  
emails per bug/package

- Tagging : Allow people to optionally attach tags to bugs
- IRC integration : Allow bot integration to an IRC channel, like a  
#php.bugs resurrection

- Optional milestones (in pearweb today)
- Integrate with VCS. Research this, KISS. Ex. A commit containing  
"PHP Bug #42" automagically appends info to the bugs db

- Befriend systems like http://bts-link.alioth.debian.org/
- OpenID support, see also http://wiki.php.net/ideas/phpnetauth
- Username finder for the 'assigned' boxes, see also http://people.php.net/

And as always, additional volunteers are welcome.

Regards,
Philip

[1] http://cvs.php.net/viewvc.cgi/pear/Bugtracker/


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

[PHP-DEV] Garbage collection in PHP

[Philip Olson]

A volunteer is needed to document GC functionality with PHP 5.3+.  
Ideally this means:


1. Create a FAQ about:
- What the heck this is
- Why we care
- Why we might disable it

2. Document via the following:
- http://php.net/zend.enable-gc
- http://php.net/gc-collect-cycles
- http://php.net/gc-disable
- http://php.net/gc-enable
- http://php.net/gc-enabled

3. Said volunteer(s) can do either:
- Commit to the docs
- Write a plain old text file with the information, send to php...@lists.php.net
- Discuss the topic of GC within this thread

Regards,
Philip


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

Re: [PHP-DEV] bug tracker planning

[Philip Olson]

On Jul 15, 2009, at 11:47 AM, Jani Taskinen wrote:


Sriram Natarajan wrote:

Hi
bug tracking system also need the ability to mark a current bug as  
duplicate . Currently, all those bugs are marked as 'Bogus'. Also,  
it would be nice if we can have the ability to capture related bugs  
together.

- Sriram


And we're not adding anymore statuses. Status is irrelevant for bug  
being related to something or not.


I think we should bring back the duplicate status for duplicate bugs,  
and include a bug number field to be submitted instead of sometimes  
writing a bug number as a comment that links if we remembered the  
syntax. And besides, the new Bugtracker already has the duplicate  
status much like its mother pearweb/bugs has.


As for 'capturing related bugs', I imagine the [optional] tagging  
would help with that... or do you have something specific in mind?


Regards,
Philip


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

Re: [PHP-DEV] Attempt to get 5.3.1 release one step further

[Philip Olson]

Greetings,

A question, using an example from today for PHP 5.3.1:

 RC: 5.3.1RC1 (via svn co tags/php_5_3_1RC1 or qa.php.net)
 RC-dev: 5.3.1RC2-dev (via svn co branches/PHP_5_3_1)
 Snap:   5.3.2-dev(via svn co branches/PHP_5_3, or snaps.php.net)

While updating qaweb to allow failed 5.3.2-dev make tests, I now  
realize it's not the same as 5.3.1RC2-dev so this presents a problem.  
People who report bugs about an RC are sometimes told to try a  
snapshot (which we no longer have in this case) and besides, this may  
lead to confusion. Please explain how this will work.


Regards,
Philip


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

Re: [PHP-DEV] Why is ereg being deprecated?

[Philip Olson]

Hello everyone,

Let's create a guide for people wanting to convert code from ereg to  
preg. Please post a few items that belong like:


1. Delimiters are needed with PCRE
2. /i versus eregi
3. Something needed to be said about named classes?

What else?

Regards,
Philip


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

Re: [PHP-DEV] Regarding constructions like func()[0]

[Philip Olson]

On 07.11.2009, at 12:42, melfar wrote:

Hello!

I have filed a bug (suggestion) at http://bugs.php.net/bug.php?id=50003
What do you think about enabling such a constructions in future  
versions of

php?



On Nov 9, 2009, at 1:41 AM, David Zülke wrote:

It's already on the list for PHP6:

http://wiki.php.net/summits/pdmnotesmay09 (see Day 2, PHP 6, #13).

No need to discuss this further, I think. You might also want to  
have that bug closed, it's redundant.


There's also a declined-ish RFC on this matter:

- http://wiki.php.net/rfc/functionarraydereferencing

Regards,
Philip



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

[PHP-DEV] Re: SVN Account Request: satoruyoshida (Re: [PHP-DOC] Can I get CVS account?)

[Philip Olson]

On Nov 29, 2009, at 6:17 PM, TAKAGI Masahiro wrote:

> # Cc'ed to internals list.
> 
> Hi,
> 
> Could you please give him the karma for phpdoc (or at least phpdoc/ja) ?

Greetings Yoshida and all,

I don't believe a SVN account request is on record, so please apply for one and 
it will be approved (with karma granted):

 - http://www.php.net/svn-php

Regards,
Philip



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

Re: [PHP-DEV] Test OpenGrok installation (LXR replacement?)

[Philip Olson]

On Dec 27, 2009, at 1:17 PM, Michael Maclean wrote:

> Hi,
> Since LXR hasn't been updating since the shift to SVN, I've been 
> investigating bringing it back. Today, though, I came across OpenGrok which 
> appears to be a far more modern implementation of the same thing, using 
> Lucene as the back end. I've set up a test installation of it at 
> http://php-og.mgdm.net if anyone is interested in playing with it.
> 
> Advantages seem to be:
> * It's really quite fast
> * It has a nicer UI, in my opinion
> * It's not too hard to set up
> * It handles multiple branches *relatively* well
> * It does incremental indexing, which I don't think LXR does
> 
> It has the potential disadvantage that it requires Tomcat, which means 
> running another web server somewhere, but I'm quite willing to volunteer to 
> look after it if we can find a php.net machine to put it on at some point. 
> For now, the test install is updating each branch from SVN and reindexing 
> once every two hours.
> 
> Any comments?

Looks great, and much nicer. If you feel pb11[1] could handle it, then we could 
dedicate this box to OpenGrok (as grok.php.net?).

Regards,
Philip

[1] http://wiki.php.net/systems/pb11


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

Re: [PHP-DEV] invalid params return value

[Philip Olson]

On Dec 31, 2009, at 5:22 AM, Johannes Schlüter wrote:

> On Thu, 2009-12-31 at 12:20 +, Derick Rethans wrote:
>> Hmm, I don't actually think many people test whether parsing parameters 
>> failed, but they do test the return value. AFAIK, our "standard" is to 
>> return NULL for parameter parsing failures (at least that's what all the 
>> examples in README.PARAMETER_PARSING_API do). I'd like to see that be 
>> the case for all things, but changing it now could be quite a bit of a 
>> BC break.
> 
> This is also the documented as the general convention:
> http://de.php.net/manual/en/functions.internal.php
> 
> While there are exceptions to this on purpose: For instance get_object
> is documented to "Return FALSE if /object/ is not an object" (this
> exception was discussed in detail in the past)

Ideally the documentation would be explicit, as currently it says:

"In this case it will likely return NULL but this is just a convention, and 
cannot be relied upon."

Knowing exactly which do (and do not) follow this rule would be great.

Regards,
Philip


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

Re: [PHP-DEV] 5.3 release schedule and other bits

[Philip Olson]

>> 
>> For example, you discussed changing some ini settings and the possibility
>> of making short tags throw deprecated warnings.  So I wouldn't be
>> surprised if there are other changes in your forks.
> 
> The change on the ini file is to avoid breaking applications (that 
> incorrectly rely on short_open_tag being On) on upgrade (which is very 
> important). We aren't doing anything really different, the default value in 
> the interpreter is still On.
> 
> The warning was being proposed to make sure those applications are fixed to 
> avoid having to carry the ini patch too long.

It's worth noting that PHP (as of 5.3) does not distribute a php.ini file that 
contains default values (like php.ini-dist essentially did). So I imagine 
issues arise when distributions want to enable one during the PHP install. 

Curious, do you enable one of the php.ini-* files by default? Which? Perhaps 
with a few other changed values to meet the defaults, like with short_open_tag?

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

Re: [PHP-DEV] Subscribe to PDO list (was Re: [PHP-DEV] [PATCH] PDO DBLIB)

[Philip Olson]

On Jan 22, 2010, at 1:19 PM, Joey Smith wrote:

> On Fri, Jan 22, 2010 at 04:32:55AM +, Niel Archer wrote:
>> Well whaddya-know! This time it worked for me, although 45 minutes wait
>> seems long. I'd given up 20 minutes after the other requests had been
>> answered.
> 
> I had the same problem and waited several weeks between attempts, checking
> my inbox for the email to no avail. Finally, I realized "Well, it's an
> ezmlm list, I can just send it commands", and this worked just fine - so
> if you want to subscribe to the PDO list, instead of trying to use the
> web interface (which appears to be broken for that list at least), you can
> just send an email to pdo-subscr...@lists.php.net

The phpweb code had "php-pdo" instead of "pdo" so it likely never worked. This 
has been fixed in SVN.

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

Re: [PHP-DEV] PHP 5 Bug Summary Report

[Philip Olson]

On Jan 25, 2010, at 1:30 AM, internals@lists.php.net wrote:

> PHP 5 Bug Database summary - http://bugs.php.net/
> 
> Num Status Summary (1595 total -- which includes 1036 feature requests)

Curious, does anybody use or read these? These emails have probably outgrown 
their use, so let's evaluate: 

 - Reasons for removal:  The content is overwhelming, and does clutter the list 
search results
 - Reasons for changing: Same as above, and good ideas would result
 - Reasons for keeping:  Old timers like old things, it reminds us that we have 
many bugs, and ^f

Like, they could instead show simple statistics similar to ones presented here:

 - http://bugs.php.net/lstats.php?phpver=5&per_category=1
 - http://bugs.php.net/bugstats.php?phpver=5

And while doing this, we could show how many were open/closed the previous 
week. I think I just volunteered to make that happen, if desired by others.

Other ideas (some crazier than others):

 - Show who closed bugs (positive)
 - Show how long bugs have been assigned to people (negative)
 - Show the top 5 buggiest and bug free extensions (both)
 - ...

Hopefully others have ideas, especially for positive reinforcement as it 
unfortunately feels much easier to come up with negative ones. But, that's okay 
too. ;)

Regards,
Philip


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

Re: [PHP-DEV] PHP6: status of short_open_tag and asp_tags

[Philip Olson]

On Mar 9, 2010, at 6:00 PM, Lee Powers wrote:

> Is short_open_tag set to be removed or deprecated in PHP6? I don't see any
> deprecated/removal alerts in the documentation, yet I've heard all sorts of
> conjecture about the availability of short_open_tag along with asp_tags in 6
> and would like to get a more official indication of their status.

short_open_tag is not deprecated. However, decoupling http://www.php.net/unsub.php

Re: [PHP-DEV] 5.3 release schedule and other bits

[Philip Olson]

On Mar 11, 2010, at 4:02 PM, Raphael Geissert wrote:

> Hi Johannes,
> 
> Johannes Schlüter wrote:
>> for 5.3.3 it depends on security issues being reported, bug fixes going
>> in, ... maybe 3 months after.
> 
> With the current discussion about moving 6.0 to a branch and continuing the 
> development of 5.4+ in trunk, I was wondering if there is going to be a 
> change of plan.
> 
> I'm mostly interested in knowing if it would be possible to get 5.3.3 out in 
> a month, more or less (the latter preferred). This would be of great help 
> from a Debian POV, as it would reduce the divergence; otherwise at Debian we 
> are going to end up with 5.3.2 with many patches (probably more than those 
> we included in 5.2.6 for lenny, because of our current work to get the 
> testsuite to pass).

Also, Mac users have the same desire. A recent bug fix makes compiling PHP 5.3 
on Mac much easier.

Regards,
Philip


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

Re: [PHP-DEV] PHP 6

[Philip Olson]

On Mar 12, 2010, at 10:46 AM, Stanislav Malyshev wrote:

> Hi!
> 
>> Yeah.
>> We tried it, and it simply didn't pan out (performance, bc, lost interest, 
>> ..).
> 
> I think it is a bit premature to declare the death of Unicode in PHP. Yes, we 
> know there are problems, and yes, it was harder that initially thought, so we 
> may want to take a step back and rethink it. Also we may want to get Unicode 
> out of the way of other PHP development, since it's taking longer than 
> planned. But that doesn't mean we should bury it.

How have other languages progressed down the unicode road? Is there anything we 
can learn from their progress over these past few years? 

Or is the problem simply lack of volunteer hours? If so, maybe a strong effort 
to create real internals documentation (that includes unicode goodness) a 
possible solution?

Regards,
Philip


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

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

[Philip Olson]

On Mar 13, 2010, at 1:56 PM, Lukas Kahwe Smith wrote:

> 
> On 13.03.2010, at 22:52, Stefan Marr wrote:
> 
>> 
>> On 13 Mar 2010, at 22:43, Sebastian Bergmann wrote:
>> 
>>> Rasmus Lerdorf wrote:
 No, not ok.  We will call the next release whatever we like.  People who
 have written books or articles about PHP 6 inferring they knew what the
 final state of PHP 6 would be were misguided.  We never got to the point
 of a final feature set much less a release date.
>>> 
>>> +1
>>> 
>>> Authors that wrote, publishers that published and readers that bought
>>> books on PHP 6 need to be ... punished ;-)
>> Is that wise and well-considered or something the community might regret in 
>> the long run?
> 
> 
> Nobody needs to be punished and I think Rasmus stayed clear of such words for 
> a reason. The name of the next version is not really all that relevant more 
> if the next version will be a minor bump (aka x.y+1) or a major (aka x+1.y).

The PHP manual refers to "PHP 6" over 200 times, and there are probably a few 
people who've written code that takes this information into account. I'm not 
saying the proposal in this thread is a solution or needed, but there is a 
valid concern here.

The PHP manual will be updated once this is figured out, with extra care 
ensuring unicode and PHP 6 information is current. All suggestions for how to 
handle this today are welcome.

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

Re: [PHP-DEV] Hi

[Philip Olson]

On Mar 29, 2010, at 9:36 AM, GM wrote:

> Hey guys. I'm glad to be on the internals list -- I just signed up. I've been 
> a PHP developer for many years, and I have a couple ideas that might make PHP 
> 6 better. Is this a good forum to bring up proposals of that kind?

Greetings Gregory,

Writing an RFC for largish features is typically a good idea:

  http://wiki.php.net/rfc

But you may want to first discuss these ideas on this list.

Regards,
Philip


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

Re: [PHP-DEV] Have we reached 1,000 authors for the PHP project?

[Philip Olson]

From that data (that covers all of SVN, including docs/pear/pecl/etc.) we have 
the following:

1996 First: 4   Last: 1
1997 First: 21  Last: 6
1998 First: 27  Last: 13
1999 First: 40  Last: 18
2000 First: 71  Last: 36
2001 First: 115 Last: 56
2002 First: 170 Last: 101
2003 First: 104 Last: 84
2004 First: 86  Last: 72
2005 First: 65  Last: 79
2006 First: 64  Last: 64
2007 First: 72  Last: 86
2008 First: 72  Last: 103
2009 First: 77  Last: 145
2010 First: 12  Last: 136 (as of March)

Not sure what that means (if anything), but they are statistics where:

- first = first commit made that year
- last  = last  commit made that year (so far)

Also, it looks like 136 people have made commits in 2010 :)

Regards,
Philip


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