On Thu, Apr 4, 2013 at 1:39 PM, Levi Morrison wrote:
> Did I just read that even though we have reasons to believe this is not a
> good addition that we are *still* going to launch 5.5 with it?
>
where did you read that(not a good addition)?
thanks
--
Laruence Xinchen Hui
http://www.laruence.
On 04/04/2013 04:09 AM, Sara Golemon wrote:
A logical extension of this idea would be to drop _array_ and cover
objects too, one uniform everything API is very appealing, and way
easier to document properly.
https://gist.github.com/krakjoe/5304945
I'd be happy to complete/test it if we think
Did I just read that even though we have reasons to believe this is not a
good addition that we are *still* going to launch 5.5 with it?
On Thu, Apr 4, 2013 at 5:37 AM, Hannes Magnusson wrote:
> On Wed, Apr 3, 2013 at 2:00 PM, Stas Malyshev
> wrote:
> > Hi!
> >
> >> There is absolutely no need for a RFC for it.
> >> Heck, even that initial curtesy mail was more then I would have
> expected.
> >
> > Agree, no need for full scale R
On Wed, Apr 3, 2013 at 10:42 PM, Hannes Magnusson <
hannes.magnus...@gmail.com> wrote:
> On Wed, Apr 3, 2013 at 5:42 AM, Ferenc Kovacs wrote:
> > On Wed, Apr 3, 2013 at 10:37 AM, Laruence wrote:
> >
>
> >> however, you are right, it's not a long time, so if objections
> becomes
> >> strong,
>> A logical extension of this idea would be to drop _array_ and cover
>> objects too, one uniform everything API is very appealing, and way
>> easier to document properly.
>>
>
> https://gist.github.com/krakjoe/5304945
>
> I'd be happy to complete/test it if we think it's a worthy direction to go
On Wed, Apr 3, 2013 at 2:00 PM, Stas Malyshev wrote:
> Hi!
>
>> There is absolutely no need for a RFC for it.
>> Heck, even that initial curtesy mail was more then I would have expected.
>
> Agree, no need for full scale RFC for one constant. However, sending an
> email to the list and actually wa
On Tue, 02 Apr 2013 02:11:24 +0200, chobie wrote:
Hi, I'm writing some socket client (fluentd client) with PHP and I have a
question.
I want to retry fwrite or some socket function when I met recoverable
errno (e.g, EAGAIN). but PHP does not have any function to determine
errno as far as I
Hi!
> There is absolutely no need for a RFC for it.
> Heck, even that initial curtesy mail was more then I would have expected.
Agree, no need for full scale RFC for one constant. However, sending an
email to the list and actually waiting for feedback is exactly what I
would expect, especially de
On Wed, Apr 3, 2013 at 5:42 AM, Ferenc Kovacs wrote:
> On Wed, Apr 3, 2013 at 10:37 AM, Laruence wrote:
>
>> however, you are right, it's not a long time, so if objections becomes
>> strong, I can revert it.
>>
>
> this is exactly the kind of behavior why we changed from the commit first
>
On 04/03/2013 08:43 PM, Joe Watkins wrote:
On 04/03/2013 06:23 PM, Sara Golemon wrote:
1a) The "c" modifier seems like an unnecessary microoptimization.
Compilers
should be able to optimize strlen() calls on constant strings away
and even
if they didn't, it wouldn't be much of a big deal. Also
On 04/03/2013 06:23 PM, Sara Golemon wrote:
1a) The "c" modifier seems like an unnecessary microoptimization. Compilers
should be able to optimize strlen() calls on constant strings away and even
if they didn't, it wouldn't be much of a big deal. Also using the
"c"-variants on a non-literal wou
Hi
2013/4/3 Johannes Schlüter :
> Any opinions on this?
Lets just get it committed, +1
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi
2013/4/3 Laruence :
> Hey:
>but as you see, many people was entrapped by the experimental feature,
> and whether the experimental is there is out of their hands.
>
>I, from a user aspect, I need to know whether my project can run in the
> host environment. if not, I can warn the use
Hi!
> https://github.com/johannes/php-src/commit/a1301253a44de3997548cbd8f83e38d79e4c331c
> the PHP module loader will, in case of an error, check for Zend
> Extension symbols and give a more verbose error .
Sounds like a good idea.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www
> 1a) The "c" modifier seems like an unnecessary microoptimization. Compilers
> should be able to optimize strlen() calls on constant strings away and even
> if they didn't, it wouldn't be much of a big deal. Also using the
> "c"-variants on a non-literal would not throw an error and just use an
>
> Nice API, I am a bit worried though about conversion routines.
> Specifically, php_array_zval_to_double() uses different conversion
> algorithm than PHP's standard zval to double conversion, which may
> result in different results in edge cases. Also, these functions seem to
> duplicate existing
> I would like to kill other APIs in next major as well, time for
> cleanup and ease maintenance. Yes, it is a bit more work for
> extensions developers but as you plan to do pecl releases as well for
> these inlined functions, that should be a good thing in the long run.
>
I'm not sure how you pla
2013/4/3 Johannes Schlüter :
> Hi,
>
> with opcache being bundled I expectr to see multiple bugs like #64568
> where users are trying to load opcache as PHP module (using extension=
> in php.ini), I tried to improve the error message a bit.
>
> In
> https://github.com/johannes/php-src/commit/a13012
On Wed, Apr 3, 2013 at 10:42 PM, Kalle Sommer Nielsen wrote:
> 2013/4/3 Laruence :
> > On Wed, Apr 3, 2013 at 4:22 PM, Stas Malyshev >wrote:
> >
> >> Hi!
> >>
> >> > Added new constant CURL_WRAPPERS_ENABLE in (include 5.4)
> >> >
> >>
> https://github.com/php/php-src/commit/d7f709a032a40cb47504
2013/4/3 Laruence :
> On Wed, Apr 3, 2013 at 4:22 PM, Stas Malyshev wrote:
>
>> Hi!
>>
>> > Added new constant CURL_WRAPPERS_ENABLE in (include 5.4)
>> >
>> https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7
>>
>> I must say the process of how it was done was not very g
On Wed, Apr 3, 2013 at 4:52 AM, Sara Golemon wrote:
> https://wiki.php.net/rfc/php-array-api
>
I like the idea behind this, though right now that API seems a bit like a
combinatorial explosion of functions and I think it would be better if one
could separate different parts of it.
So some feedb
发自我的 iPhone
在 2013-4-3，20:42，Ferenc Kovacs 写道：
On Wed, Apr 3, 2013 at 10:37 AM, Laruence wrote:
> On Wed, Apr 3, 2013 at 4:22 PM, Stas Malyshev >wrote:
>
> > Hi!
> >
> > > Added new constant CURL_WRAPPERS_ENABLE in (include 5.4)
> > >
> >
> https://github.com/php/php-src/commit/d7f709a032
On Wed, Apr 3, 2013 at 10:37 AM, Laruence wrote:
> On Wed, Apr 3, 2013 at 4:22 PM, Stas Malyshev >wrote:
>
> > Hi!
> >
> > > Added new constant CURL_WRAPPERS_ENABLE in (include 5.4)
> > >
> >
> https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7
> >
> > I must say the
>> Wed, Apr 3, 2013 at 11:01 AM, Johannes Schlüter >> wrote:
>>
>>> Hi,
>>>
>>> with opcache being bundled I expectr to see multiple bugs like #64568
>>> where users are trying to load opcache as PHP module (using extension=
>>> in php.ini), I tried to improve the error message a bit.
>>>
>>> In
>>
Looking good. +1.
On Apr 3, 2013 12:23 PM, "Julien Pauli" wrote:
> Wed, Apr 3, 2013 at 11:01 AM, Johannes Schlüter >wrote:
>
> > Hi,
> >
> > with opcache being bundled I expectr to see multiple bugs like #64568
> > where users are trying to load opcache as PHP module (using extension=
> > in php
Wed, Apr 3, 2013 at 11:01 AM, Johannes Schlüter wrote:
> Hi,
>
> with opcache being bundled I expectr to see multiple bugs like #64568
> where users are trying to load opcache as PHP module (using extension=
> in php.ini), I tried to improve the error message a bit.
>
> In
>
> https://github.com/j
Hi,
with opcache being bundled I expectr to see multiple bugs like #64568
where users are trying to load opcache as PHP module (using extension=
in php.ini), I tried to improve the error message a bit.
In
https://github.com/johannes/php-src/commit/a1301253a44de3997548cbd8f83e38d79e4c331c
the PHP
On Wed, Apr 3, 2013 at 10:22 AM, Stas Malyshev wrote:
> Hi!
>
>> Added new constant CURL_WRAPPERS_ENABLE in (include 5.4)
>> https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7
>
> I must say the process of how it was done was not very good. Not only
> there were no sub
On Wed, Apr 3, 2013 at 4:22 PM, Stas Malyshev wrote:
> Hi!
>
> > Added new constant CURL_WRAPPERS_ENABLE in (include 5.4)
> >
> https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7
>
> I must say the process of how it was done was not very good. Not only
> there were no
Hi!
> Added new constant CURL_WRAPPERS_ENABLE in (include 5.4)
> https://github.com/php/php-src/commit/d7f709a032a40cb475042b43db07a4698a2488b7
I must say the process of how it was done was not very good. Not only
there were no substantial discussion on adding this new thing in stable
version be
Hi!
> https://wiki.php.net/rfc/php-array-api
Nice API, I am a bit worried though about conversion routines.
Specifically, php_array_zval_to_double() uses different conversion
algorithm than PHP's standard zval to double conversion, which may
result in different results in edge cases. Also, these
2013/4/3 Hannes Magnusson :
> You'll actually have to assign the value of CURL_WRAPPERS_ENABLED to
> $curlwrappers, as defined() only checks if the constant exist.. not if
> its set to true :)
well, s/defined('CURL_WRAPPERS_ENABLED')/defined('CURL_WRAPPERS_ENABLED')
&& CURL_WRAPPERS_ENABLED/
Doe
On Wed, Apr 3, 2013 at 12:31 AM, Kalle Sommer Nielsen wrote:
> Hi Laruence
>
> 2013/3/31 Laruence
>>I propose to add a constant : bool CURL_WRAPPERS_ENABLE
>>
>>or, any other better name...
>>
>>objections?
>
> I'm a -1 on this, because as we sort of agreed on (like Hannes
> implied),
Hi Laruence
2013/3/31 Laruence
>I propose to add a constant : bool CURL_WRAPPERS_ENABLE
>
>or, any other better name...
>
>objections?
I'm a -1 on this, because as we sort of agreed on (like Hannes
implied), this experimental feature did not turn out as we wanted, its
buggy and nobod
hi Sara,
On Wed, Apr 3, 2013 at 4:52 AM, Sara Golemon wrote:
> https://wiki.php.net/rfc/php-array-api
Love it, great work. +1 :)
I would like to kill other APIs in next major as well, time for
cleanup and ease maintenance. Yes, it is a bit more work for
extensions developers but as you plan to
36 matches
Mail list logo
