Hey:
On Mon, Jan 26, 2015 at 8:43 AM, Stanislav Malyshev wrote:
> Hi!
>
> With recent moving of string lengths to size_t, it looks like PDO APIs
> weren't updated. I.e.:
>
> typedef int (*pdo_stmt_get_col_data_func)(pdo_stmt_t *stmt, int colno,
> char **ptr, zend_ulong *len, int *caller_frees);
>
Hi!
With recent moving of string lengths to size_t, it looks like PDO APIs
weren't updated. I.e.:
typedef int (*pdo_stmt_get_col_data_func)(pdo_stmt_t *stmt, int colno,
char **ptr, zend_ulong *len, int *caller_frees);
This looks like len should be size_t, and in fact fetch_value() in
pdo_stmt.c
On Jan 25, 2015 3:31 AM, "Jan Ehrhardt" wrote:
>
> Pavel Kou?il in php.internals (Sat, 24 Jan 2015 19:07:28 +0100):
> >>
https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm
> >>
https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip
>
> https://phpdev.toolsfo
Crib sheet for today's work ...
Slowly getting on top of all the bits I need to get my development site
running on PHP7. http://php7.lsces.org.uk/phpinfo.php is running in
parallel with http://lsces.org.uk/phpinfo.php.
Little niggles on the way to a matching shared library layout to match
the PHP
> On 25 Jan 2015, at 23:02, Juan Basso wrote:
>
> Andrea,
>
>
> I did a PR to Jakub's branch with changes of preserve fractional part rfc
> after it was approved. His branch has the same implementation that was merged
> into 5.6, but adapted to master.
>
> Also, as he mentioned, the same be
Michael Wallner in php.internals (Sun, 25 Jan 2015 18:32:18 +0100):
>On 23/01/15 22:18, Jan Ehrhardt wrote:
>> Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400):
>>> "master" branch.
>>
>> propro, raphf and pecl_http do not compile with the master branch.
>> You'll have to checkout
Andrea,
I did a PR to Jakub's branch with changes of preserve fractional part rfc
after it was approved. His branch has the same implementation that was
merged into 5.6, but adapted to master.
Also, as he mentioned, the same behavior, options disabled by default.
Juan Baso
On Jan 25, 2015 1:08
Hi all,
On Thu, Jan 22, 2015 at 2:05 PM, Yasuo Ohgaki wrote:
> I've made patch for master since PHP 5.6 is released already.
>
> https://wiki.php.net/rfc/session-lock-ini
> https://github.com/php/php-src/pull/1016
>
> Except comments, changes are almost minimal, but includes a few bug fixes
> th
On Sun, Jan 25, 2015 at 5:05 PM, Andrea Faulds wrote:
> Hi Pavel,
>
Hi, thanks for explaining some things.
>
> It can *sometimes* be a lossless conversion. Only sometimes.
>
> For float to int conversion:
>
> * Floats have the special values INF, NAN and -NAN, which cannot be preserved
> * Float
On Sun, Jan 25, 2015 at 6:27 PM, Stanislav Malyshev
wrote:
>
>
> Please do not forget to add all BC-breaking changes in UPGRADING
> (currently not part of the patch).
>
Just added in
https://github.com/bukka/php-src/commit/22394b79423b6c4eab3d43e246e03fc3feedfff5
. ;)
Thanks
Hi
On Sun, Jan 25, 2015 at 6:07 PM, Andrea Faulds wrote:
>
> What’s the status of the Preserve Fractional Part RFC with relation to the
> jsond extension?
>
The preserve fractional part RFC has been accepted as a non-default option.
It's also non-default option in jsond and the proposed patch.
Hi!
> https://wiki.php.net/rfc/jsond
>
> It's a simple Yes/No vote whether jsond should replace the current json
> extension in PHP 7.
Please do not forget to add all BC-breaking changes in UPGRADING
(currently not part of the patch).
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - P
> De : Dan Ackroyd [mailto:dan...@basereality.com]
>
> However I think there is a strong risk of people having to give a
> reason why they voted no being abused, particularly if it is shown
> while the voting was taking place, as people could be harassed for
> choosing an 'invalid' reason to reject
Hi!
> It was a fairly simple proposed change with a well-defined set of
> impacted change; what diversity of disagreement do you expect?
I've already have a number of reasons I haven't heard before, or didn't
know their relative importance to people. I think hearing people out -
not necessarily a
Hi!
> 2) I don't see a flood of people coming to the mailing list complaining
> about this feature, so I'm not compelled to want it in the language.
That's true for most features, and that's normal - in fact, I can't
remember a feature or a fix where we had a flood of people coming to the
list.
Hi Jakub,
What’s the status of the Preserve Fractional Part RFC with relation to the
jsond extension?
I’d like to know that before voting.
Thanks.
> On 25 Jan 2015, at 17:29, Jakub Zelenka wrote:
>
> Hi All!
>
> Voting on jsond is now open:
>
> https://wiki.php.net/rfc/jsond
>
> It's a si
Hi All!
Voting on jsond is now open:
https://wiki.php.net/rfc/jsond
It's a simple Yes/No vote whether jsond should replace the current json
extension in PHP 7.
Cheers
Jakub
On 23/01/15 22:18, Jan Ehrhardt wrote:
> Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400):
>> "master" branch.
>
> propro, raphf and pecl_http do not compile with the master branch.
> You'll have to checkout the phpng branch. These extensions did compile
> and load:
> https://phpde
On 25 January 2015 at 15:44, Dan Ackroyd wrote:
> On 25 January 2015 at 11:26, Peter Cowburn wrote:
> > That's what the mailing list threads are for, right?
>
>
> If someone has already said a reason on the list for why an RFC should
> be voted no, when someone else agrees with that reason it's
On Sun, Jan 25, 2015 at 3:18 PM, Lester Caine wrote:
> On 25/01/15 13:52, Matteo Beccati wrote:
> > Not yet. For now, use --without-pear.
>
> Just for the record ... There have been various comments about PEAR's
> future. There is a substantial base of code using it. However the
> versions downlo
Am 25.01.2015 um 17:17 schrieb Andi Gutmans:
> Can you provide more info re: operating system and version?
> Compiler version?
$ cat /etc/issue
Fedora release 21 (Twenty One)
$ clang --version
clang version 3.5.0 (tags/RELEASE_350/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix
Can you provide more info re: operating system and version? Compiler version?
Thanks.
Sent from my iPhone
> On Jan 24, 2015, at 11:57 PM, Sebastian Bergmann wrote:
>
> Nut sure whether this is an issue or not but I see it a lot while
> compiling master:
>
> Zend/zend_alloc.h:57:236: warning
Hi Pavel,
> On 25 Jan 2015, at 08:38, Pavel Kouřil wrote:
>
> personally I still don't like this RFC in it's current form and
> "shorter" declare won't change it.
I didn’t expect that making it shorter would really change anyone’s opinions,
except perhaps those who don’t like the term “type hi
On 25 January 2015 at 11:26, Peter Cowburn wrote:
> That's what the mailing list threads are for, right?
If someone has already said a reason on the list for why an RFC should
be voted no, when someone else agrees with that reason it's not common
for them to email, as it could be viewed as gener
On 25/01/15 13:52, Matteo Beccati wrote:
> Not yet. For now, use --without-pear.
Just for the record ... There have been various comments about PEAR's
future. There is a substantial base of code using it. However the
versions downloaded direct may not actually be usable currently so some
plan to m
On Sun, Jan 25, 2015 at 1:51 PM, Lester Caine wrote:
> On 19/01/15 15:17, Xinchen Hui wrote:
> > actually, it still fails with:
> >
> > Fatal error: Call to undefined function set_magic_quotes_runtime() in
> >
> phar:///home/huixinchen/opensource/trunk/pear/install-pear-nozlib.phar/PEAR/Config.ph
On 25/01/2015 13:51, Lester Caine wrote:
On 19/01/15 15:17, Xinchen Hui wrote:
actually, it still fails with:
Fatal error: Call to undefined function set_magic_quotes_runtime() in
phar:///home/huixinchen/opensource/trunk/pear/install-pear-nozlib.phar/PEAR/Config.php
on line 1026
make[1]: *** [i
On 19/01/15 15:17, Xinchen Hui wrote:
> actually, it still fails with:
>
> Fatal error: Call to undefined function set_magic_quotes_runtime() in
> phar:///home/huixinchen/opensource/trunk/pear/install-pear-nozlib.phar/PEAR/Config.php
> on line 1026
> make[1]: *** [install-pear-installer] Error 255
On 25 January 2015 at 08:07, Stanislav Malyshev wrote:
> I am a bit disappointed by the result, as I think it would be a good
> change, but I am much more disappointed by the fact that that 20 people
> voted against it and not even half of them - I would say maybe 1/5 of
> them - chose to particip
On 25 January 2015 at 10:52, Paul Dragoonis wrote:
> Hi Stas,
>
> Maybe a cool wiki feature addition is: once people vote they could
> optionally leave a comment right there on the wiki, which we could collect
> and read. Thoughts?
>
That's what the mailing list threads are for, right? In the m
> I am a bit disappointed by the result, as I think it would be a good
> change, but I am much more disappointed by the fact that that 20 people
> voted against it and not even half of them - I would say maybe 1/5 of
> them - chose to participate in discussion even minimally and explain
> what is w
Hi Stas,
Maybe a cool wiki feature addition is: once people vote they could
optionally leave a comment right there on the wiki, which we could collect
and read. Thoughts?
Here's my feedback for you on why i voted No.
1) It felt a bit too "magic" for me, with no real gain from an internal or
user
On 25/01/15 08:07, Stanislav Malyshev wrote:
> I think not bothering to
> discuss and then just voting "no" with no explanation is not how the
> healthy RFC process should be working.
One thought I had was 'Why would I be adding a constructor is the parent
did not require one?' Personally I would
Hi all,
On Sun, Jan 25, 2015 at 5:21 PM, Matteo Beccati wrote:
> On 25/01/2015 09:07, Stanislav Malyshev wrote:
>
>> I am a bit disappointed by the result, as I think it would be a good
>> change, but I am much more disappointed by the fact that that 20 people
>> voted against it and not even ha
Hi!
> class Baz extends Bar {
> function foo($a=default, $b=default) {
> // do something
> parent::foo($a, $b);
> }
> }
I tried to implement this, however there's a major issue that I do not
know how to overcome. The issue is that when we compile method foo() we
do not kno
On Sun, Jan 25, 2015 at 5:02 AM, Andrea Faulds wrote:
> Hi everyone,
>
> Just a few small updates.
>
> I’ve made a small change to this RFC. Instead of the strict mode syntax being
> declare(strict_typehints=TRUE), it’s now declare(strict_types=1) instead.
> This makes it a bit quicker to type -
Hi Stas,
On 25/01/2015 09:07, Stanislav Malyshev wrote:
I am a bit disappointed by the result, as I think it would be a good
change, but I am much more disappointed by the fact that that 20 people
voted against it and not even half of them - I would say maybe 1/5 of
them - chose to participate i
Hi!
The vote for RFC https://wiki.php.net/rfc/default_ctor has been
concluded, with the result of 27 vs. 20. Since 2/3 majority is required
for acceptance, the RFC has been declined.
I am a bit disappointed by the result, as I think it would be a good
change, but I am much more disappointed by th
38 matches
Mail list logo
