On Sun, Jun 5, 2011 at 01:00, Andi Gutmans a...@zend.com wrote:
In parallel I'd also see if there are any key extensions which we think are
mainstream, stable and well maintained enough to be included. For example,
http comes to mind.
People have been afraid of suggesting new exts to core
How about the Yaml extension?, it looks well maintained enough:
http://pecl.php.net/package/yaml
Regards,
David
On Sun, Jun 5, 2011 at 2:33 AM, Hannes Magnusson hannes.magnus...@gmail.com
wrote:
On Sun, Jun 5, 2011 at 01:00, Andi Gutmans a...@zend.com wrote:
In parallel I'd also see if
Hi!
As far as I can see, bug 39863 was fixed in 5.3, but the fix still not
in trunk/5.4.
Should we merge the same patch into trunk/5.4 or somebody is
volunteering to fix it, e.g. like described here:
http://news.php.net/php.internals/50191?
See also the about it discussion:
hi,
Not apparently, it was not fixed in trunk.
There was a discussion about using zend_arg for paths and additional
function or macros to be used instead of duplicating the tests
everywhere. But no consensus or agreement have been reached.
Cheers,
On Sun, Jun 5, 2011 at 10:25 AM, Stas Malyshev
Am 05.06.2011 10:59, schrieb Stanislav Malyshev:
stas Sun, 05 Jun 2011 08:59:24 +
Revision: http://svn.php.net/viewvc?view=revisionrevision=311824
Log:
This method doesn't seem to be very useful without scalar types, so reverting
it too
It is
Am 05.06.2011 12:57, schrieb Pierre Joye:
The last point is that pecl allows a much more flexible release
management than the core will even do.
in theory
So instead of doing some marketing/communication actions by bundling some
known extensions, we should better promote pecl better.
hi,
On Sun, Jun 5, 2011 at 1:37 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 05.06.2011 12:57, schrieb Pierre Joye:
The last point is that pecl allows a much more flexible release
management than the core will even do.
in theory
So instead of doing some marketing/communication
Am 05.06.2011 13:40, schrieb Pierre Joye:
hi,
On Sun, Jun 5, 2011 at 1:37 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 05.06.2011 12:57, schrieb Pierre Joye:
The last point is that pecl allows a much more flexible release
management than the core will even do.
in theory
So
On Sun, Jun 5, 2011 at 1:00 AM, Andi Gutmans a...@zend.com wrote:
For starters I would bundle ext/mongo which is very well maintained; see if
we can get thrift_protocol contributed to PECL and included (support HBase
and Cassdandra and used by a few PHP SDKs integrating with these data
On 06/05/2011 08:50 AM, Reindl Harald wrote:
Also some exts are simply not used anymore or do not have active
developers
but they compile with recent versions and if not
the build will stop and someone fix it
Sorry, but that doesn't actually happen. Only commonly used core things
are
hi,
On Sun, Jun 5, 2011 at 1:50 PM, Reindl Harald h.rei...@thelounge.net wrote:
Being in core is not a sign of good maintenance. There are so many
poorly maintained part in core as well.
but they are running through some autotests
a fucking PECL extension which is not updated
for years and
Smells like a memory leak if gc_collect_cycles() doesn't fix it.
David
On 05.06.2011, at 00:01, Mike van Riel wrote:
Hey David,
That gives me the following output:
int(640720)
int(244001144)
Mike
On Sat, 2011-06-04 at 23:51 +0200, David Zülke wrote:
What does
Am 05.06.2011 13:58, schrieb Rasmus:
On 06/05/2011 08:50 AM, Reindl Harald wrote:
Also some exts are simply not used anymore or do not have active
developers
but they compile with recent 3versions and if not
the build will stop and someone fix it
Sorry, but that doesn't actually
On Jun 3, 2011, at 4:43 AM, Derick Rethans der...@php.net wrote:
On Fri, 3 Jun 2011, Stas Malyshev wrote:
- a call to vote is easily drowned out on the ML with all the noise
I read the same ML as you do :) Using threaded email client it is very
easy to separate new threads and see calls for
Hi,
2011/6/5 Pierre Joye pierre@gmail.com
hi,
Not apparently, it was not fixed in trunk.
There was a discussion about using zend_arg for paths and additional
function or macros to be used instead of duplicating the tests
everywhere. But no consensus or agreement have been reached.
On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson hannes.magnus...@gmail.com
wrote:
On Sun, Jun 5, 2011 at 12:57, Pierre Joye pierre@gmail.com wrote:
However, for technologies specific extension, be hyped or not, I see
no reason to bundle them. It makes no sense to bundle mongodb,
On Sun, Jun 5, 2011 at 1:50 PM, Reindl Harald h.rei...@thelounge.netwrote:
Am 05.06.2011 13:40, schrieb Pierre Joye:
hi,
On Sun, Jun 5, 2011 at 1:37 PM, Reindl Harald h.rei...@thelounge.net
wrote:
Am 05.06.2011 12:57, schrieb Pierre Joye:
The last point is that pecl allows a much
Seems like leak.
Try disabling ZendMM to see if something noticeable happens (memory
peak should be lower).
USE_ZEND_ALLOC=0
Cheers,
Julien
On Sun, Jun 5, 2011 at 2:01 PM, David Zülke
david.zue...@bitextender.com wrote:
Smells like a memory leak if gc_collect_cycles() doesn't fix it.
David
On Sat, 2011-06-04 at 23:00 +, Andi Gutmans wrote:
Hi,
I've been getting quite a few inquiries re: PHP's lack of support
for modern technologies such as NoSQL databases (for lack of better
term). There is some (mistaken) perception that PHP is behind on this
front.
I'm in the believe
On Jun 4, 2011, at 3:07 AM, Pierre Joye wrote:
On Sat, Jun 4, 2011 at 5:46 AM, Stas Malyshev smalys...@sugarcrm.com
wrote:
[VOTE] is a good idea, let's make it [VOTE].
There is no plugin used for it yet, and that's my problem with it.
Well, votes aren't announced yet either :)
On 06/05/2011 09:06 AM, Reindl Harald wrote:
Am 05.06.2011 13:58, schrieb Rasmus:
On 06/05/2011 08:50 AM, Reindl Harald wrote:
Also some exts are simply not used anymore or do not have active
developers
but they compile with recent 3versions and if not
the build will stop and someone fix
On Sun, Jun 5, 2011 at 4:18 PM, Zeev Suraski z...@zend.com wrote:
Some of you may have followed the twitter conversation that Pierre and I had
at the end of last week; In my opinion, this dry (or partially wet) run that
we had in the last few days of a voting process pointed to several
On Sun, Jun 5, 2011 at 17:20, Pierre Joye pierre@gmail.com wrote:
On Sun, Jun 5, 2011 at 4:18 PM, Zeev Suraski z...@zend.com wrote:
Some of you may have followed the twitter conversation that Pierre and I had
at the end of last week; In my opinion, this dry (or partially wet) run
that
On Jun 5, 2011, at 8:20 AM, Pierre Joye wrote:
I'd to say that I'm very happy to finally see such discussions
happening, let sort the base (99% is done by our existing RFC about
release process, let adopt it already!) and move on with 5.4.
This is a prime example of what we're talking
Hi all,
Reading our bug tracker I noticed a good feature request [1] from 2009 which
points to an interesting feature that I think makes sense for us, since we
are now working with $f() using objects and strings, and the array('class',
'method') is an old known for call_user_func()-like functions.
That can lead to quite a bit of simplifications in code where you now have to
check for is_array/is_callable/instanceof Closure and such. I like it.
On Sun, 5 Jun 2011 12:52:45 -0300
Felipe Pena felipe...@gmail.com wrote:
Hi all,
Reading our bug tracker I noticed a good feature request [1]
2011/6/5 Benjamin Eberlei kont...@beberlei.de
That can lead to quite a bit of simplifications in code where you now have
to check for is_array/is_callable/instanceof Closure and such. I like it.
Exactly, and since our current $x = 'hello::world'; $x(); doesn't support
method calls, the array
On Sun, Jun 5, 2011 at 5:46 PM, Hannes Magnusson
hannes.magnus...@gmail.com wrote:
On Sun, Jun 5, 2011 at 17:20, Pierre Joye pierre@gmail.com wrote:
On Sun, Jun 5, 2011 at 4:18 PM, Zeev Suraski z...@zend.com wrote:
Some of you may have followed the twitter conversation that Pierre and I
I consider this an improvement in terms of consistency w.r.t.
callbacks, so +1 from me, good job!
Best,
On Sun, Jun 5, 2011 at 18:21, Felipe Pena felipe...@gmail.com wrote:
2011/6/5 Benjamin Eberlei kont...@beberlei.de
That can lead to quite a bit of simplifications in code where you now have
Fixed crash in fastcgi due startup order...
SIGG() were being used before tsrm_startup().
2011/6/4 Felipe Pena felipe...@gmail.com
Fixed invalid sigaction() call passing NSIG as signal number.
- for (signo = 1; signo = NSIG; ++signo) {
+ for (signo = 1; signo NSIG; ++signo) {
Detected
(Andi - I sent this before going out this morning - but I can't see it on the
list this evening ... )
Andi Gutmans wrote:
I think one of the problems is that in the past we always ensured that the
extensions for key current technologies were bundled with PHP i.e. mysql, json
soap/xml. This
On Sun, Jun 5, 2011 at 5:52 PM, Felipe Pena felipe...@gmail.com wrote:
Hi all,
Reading our bug tracker I noticed a good feature request [1] from 2009
which
points to an interesting feature that I think makes sense for us, since we
are now working with $f() using objects and strings, and the
Could you open a bug for GeoIP? Being aware of bugs helps more than bitching
around.
Thanks
Olivier (iPhone)
Le 2011-06-05 à 04:37, Reindl Harald h.rei...@thelounge.net a écrit :
Am 05.06.2011 12:57, schrieb Pierre Joye:
The last point is that pecl allows a much more flexible release
done
http://pecl.php.net/bugs/bug.php?id=2274
BTW:
that PHP 5.3.5 is the highest version in the dropdown for bugreports
does not provide the feeling of maintaining
Am 05.06.2011 20:39, schrieb Olivier Hill:
Could you open a bug for GeoIP? Being aware of bugs helps more than bitching
around.
Hi!
It is still useful for array | class/interface name. Or?
Not really, since it returned only array or object, while real class
is returned by getClass() and isArray() returns if it's an array. We
could have method that returns class name or array if it's an array,
but that'd be
Hi!
Should http://felipe.ath.cx/diff/parse_arg_null_path.diff be enough
(beyond changing others function parse args, fixing the tests,
include+require part)?
$ sapi/cli/php -r 'fopen(a\0b, r);'
Warning: fopen() expects parameter 1 to be valid path, string given in
Command line code on line 1
2011/6/5 Stas Malyshev smalys...@sugarcrm.com
Hi!
Should http://felipe.ath.cx/diff/parse_arg_null_path.diff be enough
(beyond changing others function parse args, fixing the tests,
include+require part)?
$ sapi/cli/php -r 'fopen(a\0b, r);'
Warning: fopen() expects parameter 1 to be
On Sun, Jun 5, 2011 at 9:13 PM, Felipe Pena felipe...@gmail.com wrote:
2011/6/5 Stas Malyshev smalys...@sugarcrm.com
Hi!
Should http://felipe.ath.cx/diff/parse_arg_null_path.diff be enough
(beyond changing others function parse args, fixing the tests,
include+require part)?
$ sapi/cli/php
Hi!
Of course, I was just checking if it's what you guys are thinking first.
Well, there was basically two ideas:
1. Add filename length to streams and check inside streams
2. Check inside argument parser
Both have downsides: (1) does not capture cases when we don't use
streams (such as
Hi!
So, I wrote a patch [2] that allow such behavior to be consistent with
arrays. See some examples:
Looks good. Only question I have is that we seem to have that code
(calling a function based on variable) in two places instead of one, I
wonder if it's necessary and if we could unify
-Original Message-
class Hello {
public function world($x) {
echo Hello, $x\n; return $this;
}
}
$f = array(new Hello, 'foo');
$f();
Am I the only one who doesn't understand what this one is supposed to do..?
Zeev
On Sun, Jun 5, 2011 at 9:52 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
class Hello {
public function world($x) {
echo Hello, $x\n; return $this;
}
}
$f = array(new Hello, 'foo');
$f();
Am I the only one who doesn't understand what this one is supposed
Hi,
2011/6/5 Zeev Suraski z...@zend.com
-Original Message-
class Hello {
public function world($x) {
echo Hello, $x\n; return $this;
}
}
$f = array(new Hello, 'foo');
$f();
Am I the only one who doesn't understand what this one is supposed to do..?
If
Pierre,
I'm happy that we agree pretty much completely about the clarifications
updates needed for the RFC.
I do however want to point out that the problematic way the short array syntax
RFC was executed was the key reason that made me feel these updates were in
fact necessary - I don't
Ok, that makes much more sense. Given how everyone loved it I was beginning to
wonder whether I’ve become too old to understand simple pieces of code ☺
Zeev
From: Felipe Pena [mailto:felipe...@gmail.com]
Sent: Sunday, June 05, 2011 11:02 PM
To: Zeev Suraski
Cc: internals
Subject: Re: [PHP-DEV]
For those of you who lost these proposals in the flood of RFC related emails of
recent days, here they are again:
---
First, we need to make sure that the RFC is properly evaluated by the members
of internals@, and that there's enough time for the RFC to be discussed here on
the list. As
Hi!
I'd still like to hear from others what they think about my proposal.
I'd like to update the Release Process RFC with these suggestions if
people like them.
I think these voting process additions totally make sense. But I am not
sure it makes sense to put everything in one release RFC.
Hi,
2011/6/5 Stas Malyshev smalys...@sugarcrm.com
Hi!
So, I wrote a patch [2] that allow such behavior to be consistent with
arrays. See some examples:
Looks good. Only question I have is that we seem to have that code (calling
a function based on variable) in two places instead of
Hi!
We have the code to initialize the call from a object variable, and string
variable (function only) in this exact opcode ZEND_INIT_FCALL_BY_NAME, which
now treat the array case as well, there is no other place doing such stuff.
What about call_user_func() implementation? It must be doing
I'm fine if the entire 'Feature selection and development' part goes out of the
RFC, but if there's any reference to how features are determined, we'd better
get it right.
Making changes once we've approved this RFC is going to be much tougher. This
is big stuff - it's no coincidence we didn't
Thanks for working on this.
On Sun, Jun 5, 2011 at 3:30 AM, Sean Coates s...@seancoates.com wrote:
Please read, and if you have a comment that is not already covered in the
RFC, raise it here. I'm definitely open to discussion, but I would really
love to keep this discussion civil.
TBH, I
Hello,
On Sun, Jun 5, 2011 at 2:03 PM, Jordi Boggiano j.boggi...@seld.be wrote:
Thanks for working on this.
On Sun, Jun 5, 2011 at 3:30 AM, Sean Coates s...@seancoates.com wrote:
Please read, and if you have a comment that is not already covered in the
RFC, raise it here. I'm definitely
Ok, I found that Ruby added support for a new JSONy syntax a little while
ago, this is interesting:
http://www.strictlyuntyped.com/2010/12/new-ruby-19-hash-syntax.html
http://webonrails.com/2009/02/06/ruby-191-hash/
But it doesn't have anything to do with JSON interoperability.
On Sat, Jun 4,
2011/6/5 Stas Malyshev smalys...@sugarcrm.com
Hi!
We have the code to initialize the call from a object variable, and string
variable (function only) in this exact opcode ZEND_INIT_FCALL_BY_NAME,
which
now treat the array case as well, there is no other place doing such
stuff.
What
Hello everyone,
The following categorizes bundled/enabled/core, and lists extensions as they
stand today (compiled via snaps). I don't exactly know what this means, but
writing this feels appropriate:
- Bundled : An extension that is bundled
* ./configure --enable-ext (or --with-ext) is
I like the idea of supporting both = and :. Would this work?:
$foo = {
'bar' : function(){
echo 'baz';
}
};
$foo-bar();
And I'm guessing this shouldn't work:
$array = array('foo' : 'bar');
Regards,
David
On Sun, Jun 5, 2011 at 4:11 PM, Chris Stockton
-Original Message-
From: dukeofgaming [mailto:dukeofgam...@gmail.com]
Sent: Monday, June 06, 2011 12:18 AM
To: Chris Stockton
Cc: Jordi Boggiano; Sean Coates; PHP internals
Subject: Re: [PHP-DEV] Object and Array Literals
I like the idea of supporting both = and :. Would this
On 2011-06-05, Pierre Joye pierre@gmail.com wrote:
On Sun, Jun 5, 2011 at 5:52 PM, Philip Olson phi...@roshambo.org wrote:
I'd to say that I'm very happy to finally see such discussions
happening, let sort the base (99% is done by our existing RFC about
release process, let adopt it
$foo = {
'bar' : function(){
echo 'baz';
}
};
$foo-bar();
I guess it's not yet too late to surpass Perl in the front of obscurity...
Since the stuff to the right of the assignment operator (`:` in this case) is
valid PHP, I don't see why this wouldn't be allowed if we
+1
~Hannes
Hi!
Honestly there are other parts about the voting process that are much
hotter potatoes than the points I brought up - such as who gets to
vote, is 50%+1 enough or do we need stronger majorities for
substantial language changes (67%/75%), can someone who failed
passing an RFC just put it up
Hi!
1. We do not use zend_fcall_info stuff in the VM (which zend_is_callable
works in)
2. We have to use zend_do_fcall_common_helper instead of
zend_call_function() in the VM
Yes, I know, I just have a feeling we have two pieces of code doing the
same in different way. But I think your
On Sun, Jun 5, 2011 at 10:55 PM, Zeev Suraski z...@zend.com wrote:
I'm fine if the entire 'Feature selection and development' part goes out of
the RFC, but if there's any reference to how features are determined, we'd
better get it right.
Getting it totally out makes little sense as it
Can't bundle geoip with the database due to the license on it. Would make it a
pretty useless extension to have in that case.
S
On 5 Jun 2011, at 11:39, Olivier Hill olivier.h...@gmail.com wrote:
Could you open a bug for GeoIP? Being aware of bugs helps more than bitching
around.
Thanks
hi Zeev,
On Sun, Jun 5, 2011 at 10:05 PM, Zeev Suraski z...@zend.com wrote:
Pierre,
I'm happy that we agree pretty much completely about the clarifications
updates needed for the RFC.
Same here :)
I do however want to point out that the problematic way the short array
syntax RFC was
Hi!
On 2011-06-05, Pierre Joyepierre@gmail.com wrote:
On Sun, Jun 5, 2011 at 5:52 PM, Philip Olsonphi...@roshambo.org wrote:
I'd to say that I'm very happy to finally see such discussions
happening, let sort the base (99% is done by our existing RFC about
release process, let adopt it
Currently the Feature selection and development basically says we'd have
a public vote on features. It doesn't specify how exactly is the process for
a
vote, and while again I think your proposal is good, I don't see why it has
to be
part of this RFC - e.g., if we agree that we have to
there is no need to bundle GeoIP or the databae
GeoIP is part of the os-deployment and the database have
to be updated every month with a script, the problem here
was only that nobody cared about the extension over years
Am 06.06.2011 00:21, schrieb Scott MacVicar:
Can't bundle geoip with the
[resending as the list appears to reject bit.ly URLs]
As I agree on everything you wrote here, I don't feel like we need to redo it.
The votes result is pretty clear, despite 2-3 people not willing to
vote for whatever reasons:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote
Take a
test for brain dead SURBL
--
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
As ordered, I will stick to what I feel are community issues and try
to be impersonal.
If PHP users want to be clear that we have made an educated choice to
use/maintain the language, we should appear impeccably well-versed in
the technologies which complement and compete with PHP. I
take #4..
Hmmm, not sure I like the comparison (with Egypt).
Major parts in the process weren't executed properly (I've spelled them out
so I won't repeat them).
It's quite possible that if they were executed properly, we'd have different
results. Perhaps not, maybe even probably
Hi!
The way I see it, we can't employ the voting part of this RFC unless
we can agree on rules on how this voting works; It's fine that we
don't decide exactly how we're going to do it. But then, it means
that we don't get to do it until we do decide.
Well, we'd have to vote somehow, e.g.
Hi everybody,
if you know how to do some weird things to PHP¹s parser and like
functional¹ish elements in PHP, please read further.
I¹ve finally found some time to put together a first draft of an RFC for
currying (https://wiki.php.net/rfc/currying). This is basically meant as a
starting point
+1
On Jun 5, 2011, at 6:02 PM, Pierre Joye wrote:
test for brain dead SURBL
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals -
On Sun, Jun 5, 2011 at 6:06 PM, Sanford Whiteman
sa...@cypressintegrated.com wrote:
-- I do not feel that the acronym JSON has any clarifying nor edifying
place in the RFC describing this syntax.
Rather, I would suggest one of the following:
· JavaScript-like [object|array] literal syntax
On Mon, Jun 6, 2011 at 1:16 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
The way I see it, we can't employ the voting part of this RFC unless
we can agree on rules on how this voting works; It's fine that we
don't decide exactly how we're going to do it. But then, it means
that we don't
On Sat, Jun 4, 2011 at 4:52 AM, David Zülke
david.zue...@bitextender.com wrote:
Yes, I know. Then why are you and others demanding that the resulting syntax
be fully compatible with JSON so it could be parsed by other JSON parsers?
That makes no sense at all. A file with just [foo] in it
78 matches
Mail list logo
