hi Stas,
On Thu, Nov 10, 2011 at 8:12 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Nobody's denying voice to anybody. Anybody who's interested can feel free
to come to the list and bring forward their arguments and defend them and
convince people. However, if the situation comes out that a
On 11/10/2011 12:36 AM, Pierre Joye wrote:
The last example of such a case is the SplClassLoader, the gap between
our communities and us is getting even larger. I think it is time to
consider their views and voices, especially as we get new contributors
(you know, the people actually doing the
hi Stas,
On Thu, Nov 10, 2011 at 8:17 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
This attitude only makes me lose a lot of time answering questions
instead of focusing on actual RFC stability. I want to propose
something stable, I do not want to be pressured about should the RFC
On Thu, Nov 10, 2011 at 10:32 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 11/10/2011 12:36 AM, Pierre Joye wrote:
The last example of such a case is the SplClassLoader, the gap between
our communities and us is getting even larger. I think it is time to
consider their views and voices,
On Thu, Nov 10, 2011 at 10:36 AM, Pierre Joye pierre@gmail.com wrote:
hi Stas,
On Thu, Nov 10, 2011 at 8:17 AM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
This attitude only makes me lose a lot of time answering questions
instead of focusing on actual RFC stability. I want to
Hi!
But blocking the only thing so many PHP projects have ever agreed on
is a major mistake. And it is a political and religious choice
(religious as in php does not enforce standard). Even for something
that does not enforce anything if not used.
Nobody's blocking anything. I don't
Hi!
can keep dreaming about our famous let make it easy to people to
contribute, it won't work as we are not willing to give them a voice.
I don't think one implies the other. If one helps PHP project it's
great, really, but that doesn't mean one can have his pet feature pushed
through over
On Thu, Nov 10, 2011 at 10:39, Pierre Joye pierre@gmail.com wrote:
On Thu, Nov 10, 2011 at 10:32 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 11/10/2011 12:36 AM, Pierre Joye wrote:
The last example of such a case is the SplClassLoader, the gap between
our communities and us is getting
2011/11/10 Pierre Joye pierre@gmail.com:
hi Stas,
On Thu, Nov 10, 2011 at 8:17 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
This attitude only makes me lose a lot of time answering questions
instead of focusing on actual RFC stability. I want to propose
something stable, I do
On Wed Nov 9 10:01 PM, guilhermebla...@gmail.com wrote:
Some would simply say he only did that because he got 3 proposals
rejected. Others would say he is pressuring A to be in PHP. But not.
I learned the hard way and multiple times to hear a big NO. But at the
same time, I earn my salary
On Thu, Nov 10, 2011 at 11:07 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
can keep dreaming about our famous let make it easy to people to
contribute, it won't work as we are not willing to give them a voice.
I don't think one implies the other. If one helps PHP project it's great,
Hi Rasmus,
Comments inline.
On Thu, Nov 10, 2011 at 2:51 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 11/09/2011 07:01 PM, guilhermebla...@gmail.com wrote:
My short version of this entire email is very simple question. Is PHP
meritocracy based?
It is.
I'd rather say wort of, when
Hi Jonathan,
On Thu, Nov 10, 2011 at 11:12 AM, Jonathan Bond-Caron jbo...@openmv.com wrote:
On Wed Nov 9 10:01 PM, guilhermebla...@gmail.com wrote:
Some would simply say he only did that because he got 3 proposals
rejected. Others would say he is pressuring A to be in PHP. But not.
I learned
On Thu, Nov 10, 2011 at 11:00 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Nobody's blocking anything.
See the votes, that's pretty much us vs the rest. And it is not the
1st time (happened already in the past before we had the RFC process,
so it will become more and more visible.
And as
On Thu, Nov 10, 2011 at 11:13 AM, Patrick ALLAERT
patrickalla...@php.net wrote:
You're mixing stuff here.
RFC on PSR-0 support into PHP status != PSR-0 status
I do not. But we are confusing our old vision and what users are looking for.
However, *how* PSR-0 might be introduced into PHP, for
Guilherme et al,
Since you asked me for feedback on how I would suggest improving the
RFC, so here it goes...
I think I need to make one thing clear first. I don't think that I
can vote yes for this RFC in principle (I just don't agree this
belongs in core). However, with that said if the RFC
maybe someone else would be also interested in fixing the build.
-- Forwarded message --
From: Ferenc Kovacs tyr...@gmail.com
Date: Thu, Nov 10, 2011 at 3:34 PM
Subject: Re: [PHP-CVS] svn: /php/php-src/branches/PHP_5_4/ NEWS
ext/standard/exec.c
Comments are inline.
On Thu, Nov 10, 2011 at 2:19 PM, Pierre Joye pierre@gmail.com wrote:
On Thu, Nov 10, 2011 at 11:13 AM, Patrick ALLAERT
patrickalla...@php.net wrote:
You're mixing stuff here.
RFC on PSR-0 support into PHP status != PSR-0 status
I do not. But we are confusing our
However, and it is what we approved, OSS project leads have a voice,
today and here. And they are not random people, they know sometimes
much better than us what should be added to the core (be language, or
functions in an extension like spl).
Well, I would like to make a point here. Right
2) This isn't a bunch of developers, this is a bunch of the largest used
PHP libraries in the world (ZF, Symfony, Doctrine, PPI, Drupal),
Ok, I have to say it... You're a group of people who have done great
things. Good for you. Get over it. Stop trying to use that as a
justification or
On 11/10/2011 05:53 AM, guilhermebla...@gmail.com wrote:
I don't think so. You have classified that php-src have more weight in
voting because they do the biggest effort.
That's great, but you're forgetting that php-doc, php-web and php-test
do have a lot of effort too.
The fact when it comes
Hi!
See the votes, there is a patch, created by people able to maintain
it. It is especially obvious in this case as this RFC is supported by
a large part of our users.
Able != will. There are tons of people able to fix bugs in PHP, yet some
stay unfixed for years.
Supported by users doesn't
On Thu, Nov 10, 2011 at 5:40 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
If there is voting on an RFC related to php-doc stuff, then the
meritocracy shifts to the main php-doc contributors. Same goes for
testing-related issues. My vote on a doc issue carries considerable less
weight than my
On 11/10/2011 09:44 AM, Pierre Joye wrote:
That's another myth spread by the opponents of making our process
open. All RFCs proposed has been proposed with patches, implemented by
the proposers, with or without the help of other core developers.
Nobody ever succeed (except the alternative
On Thu, Nov 10, 2011 at 7:18 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
We are not talking about a specific RFC here. This discussion is about
changing the current way of voting.
Yes, and that's what I'm talking about too.
--
Pierre
@pierrejoye | http://blog.thepimp.net |
On Thu, Nov 10, 2011 at 6:38 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
See the votes, there is a patch, created by people able to maintain
it. It is especially obvious in this case as this RFC is supported by
a large part of our users.
Able != will. There are tons of people able
On 11/10/11 8:19 AM, Pierre Joye wrote:
What amazes me is this exact argument. We never had, in the whole PHP
history, so many leading projects agreeing on something, together and
propose it to the core. I, for one, have been waiting for that to
happen for years (PEAR, etc.), and now that it is
Hi!
well even for proposals which got accepted. This is not about specific
proposals but about this exact discussion to go back to our old model.
I'm totally against it. That will kill any effort we have put to get
more contributors and feedback or help from our users.
Nobody talks about
2011/11/10 Pierre Joye pierre@gmail.com:
On Thu, Nov 10, 2011 at 11:13 AM, Patrick ALLAERT
Some are blocking because they kinda feel forced if this is introduced.
Ignore those, PHP wouldn't have bundled ext/mysql for the same reasons
about 15 years ago.
I guess that some voted No because
Hey all,
I've spent a bunch of time tracking down this issue (which was
intermittent at best) and have identified the problem and have a patch
for the solution.
Details here: https://bugs.php.net/bug.php?id=60164
The attached patch is against trunk, PHP_5_4, PHP_5_3.
Seeing as though I've
On Thu, Nov 10, 2011 at 8:09 AM, Anthony Ferrara ircmax...@gmail.com wrote:
However, and it is what we approved, OSS project leads have a voice,
today and here. And they are not random people, they know sometimes
much better than us what should be added to the core (be language, or
functions
On 11/10/2011 11:44 AM, Ralph Schindler wrote:
Hey all,
I've spent a bunch of time tracking down this issue (which was
intermittent at best) and have identified the problem and have a patch
for the solution.
Details here: https://bugs.php.net/bug.php?id=60164
The attached patch is
Ronald,
Very well said. Thanks for the clarification.
Anthony
On Thu, Nov 10, 2011 at 2:49 PM, Ronald Chmara rona...@gmail.com wrote:
On Thu, Nov 10, 2011 at 8:09 AM, Anthony Ferrara ircmax...@gmail.com wrote:
However, and it is what we approved, OSS project leads have a voice,
today and
On 11/10/2011 10:38 AM, Pierre Joye wrote:
On Thu, Nov 10, 2011 at 7:18 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
We are not talking about a specific RFC here. This discussion is about
changing the current way of voting.
Yes, and that's what I'm talking about too.
Ok, then I guess I
Hello,
On Thu, Nov 10, 2011 at 11:45 AM, Pierre Joye pierre@gmail.com wrote:
We are not talking about giving a voice to totally irrelevant people
but well known PHP project leaders, who already contribute to PHP in
one way or another. We are not either talking about them telling us
what
Hello folks,
We've run into problems related to using Postgres as a datastore for sessions,
which appears to be identified in bug report 52389
(https://bugs.php.net/bug.php?id=52389). We've tried the patch attached to the
ticket, and have not seen our issue resolved. What steps can we take
Hi!
Sure, but this is another great example. If you wrote an RFC that
basically said, Let's rewrite the engine I bet it would get a lot of
We already have such proposal. It's called unicode support. Everybody
talks about how great it would be to have one. If we had a vote, I bet
there would
Hello!
Stas has packed PHP 5.4.0RC1 which you can find here:
http://downloads.php.net/stas/
The Windows team provides windows binaries which you find here:
http://windows.php.net/qa/
This is the first release candiate. No new features will be included
before the final version of PHP
On Thu, Nov 10, 2011 at 9:04 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 11/10/2011 10:38 AM, Pierre Joye wrote:
On Thu, Nov 10, 2011 at 7:18 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
We are not talking about a specific RFC here. This discussion is about
changing the current way of
All of the existing tests run.
I will make one change as per C. Jones request to use a const for the
hard coded 1024 window (since it's used twice).
Also, I am unable to run the php-tests.php with the -m (valgrind) on my
mac, so I'll need to run those on linux before I commit.
In the mean
Maintenance of the Phar extension (bug fixing, documentation fixes, etc)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I've notice, back in PHP 5.4.0 beta 2, that this test was failing:
Bug #48555 (ImageFTBBox() differs from previous versions for texts with new
lines) [ext/gd/tests/bug48555.phpt]
So I went to https://bugs.php.net/bug.php?id=48555 and left a comment.
The same test still fails in 5.4.0RC1 and
Hi List,
When testing out 5.4b2 , I've noticed that the default Phar stub runs
the first argument to Phar::createDefaultStub when run using the cli
server. Is this right? Should i file a bug?
Thanks
- Scott
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Thu, Nov 10, 2011 at 10:17 PM, Pierre Joye pierre@gmail.com wrote:
On Thu, Nov 10, 2011 at 9:04 PM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
On 11/10/2011 10:38 AM, Pierre Joye wrote:
On Thu, Nov 10, 2011 at 7:18 PM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
We are not talking
On 11/10/2011 01:17 PM, Pierre Joye wrote:
If that's not the case, and after a 2nd thought, it is actually not
the case, then we can just discard this whole thread and go back to
code and proposals. I only find very disturbing to have to explain and
argue so many times about that only because
Pierre Joye wrote:
If that's not the case, and after a 2nd thought, it is actually not
the case, then we can just discard this whole thread and go back to
code and proposals. I only find very disturbing to have to explain and
argue so many times about that only because we have a edge case in a
Surprised to say that I agree on just about everything you mentioned. I
would however love to see a useful autoloader included in core. I have
only one comment below.
4. The RFC should avoid implementing any pattern or style that may
make future feature addition difficult or pose risks towards
Well, the problem with adding methods later is that it will fatal any class
that implements the old one. A big no no.
You could get around that by doing something like traversable. Provide an
empty and non usable core SplAutoloader interface which is typehintable.
Then add a child
Hi!
As long as it is completely obvious what is being voted on and the
process is followed, the voting RFC rules are fine. It would be nice
though if we could iterate in order to get 2/3 approval on most
proposals. It is these 50/50 ones that are problematic and often boil
down to half the
Hey Arpad, looking through the code you added to
ext/standard/basic_functions.c it looks like you are doing some weird
key handling in the shutdown function hash.
In register_user_shutdown_function() you have:
zend_hash_update(BG(user_shutdown_function_names), function_name,
David
Sorry, I just RE read your reply. that's basically what you said, so in
essence I agree...
Anthony
On Nov 10, 2011 6:29 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Well, the problem with adding methods later is that it will fatal any
class that implements the old one. A big no no.
Hi Anthony,
Thanks immensely for your input.
Without such action, it's extremely hard to improve the RFC. =)
Awesome action from your side.
I'll place my comments inline.
On Thu, Nov 10, 2011 at 1:26 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Guilherme et al,
Since you asked me for
Here is the proposed patch (sans tests; we did our own manual testing
on 32-bit and 64-bit, and had to fix an unrelated bug; will provide
tests when you say so):
http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patch
The change to zlist_clean is necessary because otherwise
On 11/11/2011 01:31 PM, guilhermebla...@gmail.com wrote:
Hi Anthony,
Thanks immensely for your input.
Without such action, it's extremely hard to improve the RFC. =)
Awesome action from your side.
I'll place my comments inline.
On Thu, Nov 10, 2011 at 1:26 PM, Anthony Ferrara
Hi David,
On Fri, Nov 11, 2011 at 1:31 AM, David Muir davidkm...@gmail.com wrote:
On 11/11/2011 01:31 PM, guilhermebla...@gmail.com wrote:
Hi Anthony,
Thanks immensely for your input.
Without such action, it's extremely hard to improve the RFC. =)
Awesome action from your side.
I'll place
Guilherme,
Comments inline
Thanks immensely for your input.
Without such action, it's extremely hard to improve the RFC. =)
Awesome action from your side.
I'll place my comments inline.
Thanks. I didn't really intend for my other comments to get so...
aggressive. I saw the proposal being
Hi!
This is actually already supported.
The SplClassLoader$mode does exactly that. The $mode can be one of these values:
- MODE_NORMAL: Throws error while attempting to include an unexistent file
Why this should even exist? It's never OK for generic autoloader to
produce any errors when it
57 matches
Mail list logo
