Hi Bob,
Now I think it's not fixable by design :(
I'll try to think about it later today.
Could you please collect all related issues.
Thanks. Dmitry.
On Mon, Jul 21, 2014 at 8:36 PM, Bob Weinand bobw...@hotmail.com wrote:
Am 2.7.2014 um 15:43 schrieb Dmitry Stogov dmi...@zend.com:
I
Pierre,
I don't replay to you, because it's bad for my health. Many people here
would agree with me.
I prefer to do things instead of endlessly repeated words.
According to PHPNG - we set one big goal (performance), and worked on it
really hard. Now everyone may see the result. It's just not
Hi David,
On Tue, Jul 22, 2014 at 2:42 PM, David Soria Parra dso...@gmx.net wrote:
Even if we have PHP-5.7 branch, we have merge up policy. Therefore,
any new feature will end up with master, I suppose. If a new feature is
only available to PHP-5.7 branch, it's a merge bug, isn't it?
On 22/07/14 03:58, Pierre Joye wrote:
Now, as I already suggested many times (but with zero reply from
Zend's), let step back, get our roadmap setup, todos, goals, agreement
and get back to work. But a forcing move to php-next within a year
with almost only phpng is a major mistake and will
On 22/07/14 07:44, Dmitry Stogov wrote:
Big PHP users just can't not to care about performance, because it's money.
I know most of them already experimented with HHVM.
Big users don't use PHP ...
If we don't provide adequate replay, we may turn back into the language for
home pages.
Is that
On Tue, Jul 22, 2014 at 11:11 AM, Lester Caine les...@lsces.co.uk wrote:
On 22/07/14 07:44, Dmitry Stogov wrote:
Big PHP users just can't not to care about performance, because it's
money.
I know most of them already experimented with HHVM.
Big users don't use PHP ...
You are wrong :)
Hi Anthony,
I noticed I've made silly mistakes in previous reply. I've added little
more.
Even if I remove text formatting, gmail insists strange formatting. It may
be hard to read...
Please disregard old one and read this.
On Mon, Jul 21, 2014 at 11:32 PM, Anthony Ferrara ircmax...@gmail.com
-Original Message-
From: Lester Caine [mailto:les...@lsces.co.uk]
Sent: Tuesday, July 22, 2014 10:12 AM
To: PHP internals
Subject: Re: [PHP-DEV] RFC: Move phpng to master
Big users don't use PHP ...
Just to elaborate (slightly) on Dmitry's answer - this is an absolutely
wrong and
hi,
On Tue, Jul 22, 2014 at 9:52 AM, Zeev Suraski z...@zend.com wrote:
I stand by my statement that I'm
sure a great deal of users (my guesstimate - the majority) would happily
upgrade to PHP.NEXT even if the huge performance gains were the only thing
there.
I fully agree with you about
On Tue, Jul 22, 2014 at 10:45 AM, Pierre Joye pierre@gmail.com wrote:
hi,
On Tue, Jul 22, 2014 at 9:52 AM, Zeev Suraski z...@zend.com wrote:
I stand by my statement that I'm
sure a great deal of users (my guesstimate - the majority) would happily
upgrade to PHP.NEXT even if the
On Tue, Jul 22, 2014 at 11:18 AM, Benjamin Eberlei kont...@beberlei.de wrote:
This is the opportunity to do the cleanup now, based on phpng branch. Since
the branch is pulic on Github, how is development secret?
Benjamin, please check the background before replying. 80% of phpng
development
On 22/07/14 10:32, Pierre Joye wrote:
As i understood Nikita and laurence they are already improving it based on
the first prototype from month ago. Honestly, if Nikita says converting his
extensions improved the API a lot then this is a good sign for me already.
It does not improve anything
On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui larue...@gmail.com wrote:
Hey:
I really don't like arguing in english, so this will be my last
reply in this thread.
sorry to bother you, and my backlash wasn't really targeted you
personally.
On Tue, Jul 22, 2014 at 12:10 AM, Ferenc
On Tue, Jul 22, 2014 at 11:32 AM, Pierre Joye pierre@gmail.com wrote:
On Tue, Jul 22, 2014 at 11:18 AM, Benjamin Eberlei kont...@beberlei.de
wrote:
This is the opportunity to do the cleanup now, based on phpng branch.
Since
the branch is pulic on Github, how is development secret?
On Tue, Jul 22, 2014 at 11:58 AM, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui larue...@gmail.com wrote:
Hey:
I really don't like arguing in english, so this will be my last
reply in this thread.
sorry to bother you, and my backlash wasn't
On Tue, Jul 22, 2014 at 12:11 PM, Benjamin Eberlei kont...@beberlei.de wrote:
On Tue, Jul 22, 2014 at 11:32 AM, Pierre Joye pierre@gmail.com wrote:
On Tue, Jul 22, 2014 at 11:18 AM, Benjamin Eberlei kont...@beberlei.de
wrote:
This is the opportunity to do the cleanup now, based on phpng
On Mon, Jun 30, 2014 at 8:10 PM, Alexey Zakhlestin indey...@gmail.com
wrote:
On 30 Jun 2014, at 11:10, Stas Malyshev smalys...@sugarcrm.com wrote:
I think we should move away from the practice of using serializer for
something it was never made for, namely a weird way of instantiating
To unsubscribe from the lists you responded to (and appear to be
trying to unsubscribe from), please send a message to the following
addresses:
php-general-unsubscr...@lists.php.net
php-announce-unsubscr...@lists.php.net
internals-unsubscr...@lists.php.net
On 21 July 2014 07:18, Jon Arano
On Tue, Jul 22, 2014 at 12:15 PM, Nikita Popov nikita@gmail.com wrote:
On Tue, Jul 22, 2014 at 11:58 AM, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Jul 22, 2014 at 3:42 AM, Xinchen Hui larue...@gmail.com wrote:
Hey:
I really don't like arguing in english, so this will be my
On Tue, Jul 22, 2014 at 12:27 PM, Ferenc Kovacs tyr...@gmail.com wrote:
sorry for the late reply.
you are right and after looking into the implementation I think classes
having custom object storage (eg. create_object) shouldn't assume that
their __construct will be called, but either do the
On Tue, Jul 22, 2014 at 1:48 PM, Nikita Popov nikita@gmail.com wrote:
On Tue, Jul 22, 2014 at 12:27 PM, Ferenc Kovacs tyr...@gmail.com wrote:
sorry for the late reply.
you are right and after looking into the implementation I think classes
having custom object storage (eg. create_object)
On Mon, Jul 21, 2014 at 12:31 PM, Zeev Suraski z...@zend.com wrote:
He just asks if we will have a 5.7 release while working on the next major
in master.
I don't think that we can release the php-next under a years, so I think
that an 5.7 could be warranted (to keep up with our roadmap),
On Mon, Jul 14, 2014 at 6:35 PM, Nikita Popov nikita@gmail.com wrote:
On Mon, Jul 7, 2014 at 4:18 PM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
I've started the vote on the Uniform Variable Syntax RFC:
https://wiki.php.net/rfc/uniform_variable_syntax#vote
You
On 22/07/14 13:17, Ferenc Kovacs wrote:
The discussion seems to be sidetracked by the topic on when should we
release PHP-NEXT and what else should it contains.
Could we agree to put that aside for now, and agree to discuss this later,
after we managed to have a consensus on merging phpng to
On 22 Jul 2014, at 13:38, Ferenc Kovacs tyr...@gmail.com wrote:
Derick mentioned in his blogpost(
http://derickrethans.nl/uniform-variable-syntax.html) that You can't
really write a scanner for it, as the code could already have been
converted.”.
Of course what he said was true, but I’m not
On Tue, Jul 22, 2014 at 2:17 PM, Ferenc Kovacs tyr...@gmail.com wrote:
Hi Zeev,
The discussion seems to be sidetracked by the topic on when should we
release PHP-NEXT and what else should it contains.
Could we agree to put that aside for now, and agree to discuss this later,
after we
On 22 ביול 2014, at 15:17, Ferenc Kovacs tyr...@gmail.com wrote:
Hi Zeev,
The discussion seems to be sidetracked by the topic on when should we release
PHP-NEXT and what else should it contains.
Could we agree to put that aside for now, and agree to discuss this later,
after we managed
Hi Ferenc,
On 22.07.2014, at 14:38, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Jul 14, 2014 at 6:35 PM, Nikita Popov nikita@gmail.com wrote:
On Mon, Jul 7, 2014 at 4:18 PM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
I've started the vote on the Uniform Variable
On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski z...@zend.com wrote:
Once the RFC is approved (I hope)
Before the merge RFC can be considered for voting, I think it is critical
that you provide a comprehensive migration guide highlighting the changes
required from core developers.
This means
Andrea Faulds wrote (on 20/07/2014):
I’ve cancelled the vote because I don’t think the case for 6 is sufficiently
fleshed out. The RFC is now massively imbalanced in favour of 7, which isn’t
really fair to the 6 side, and I don’t think we can hold a vote while that’s
still the case.
I've
On Tue, 22 Jul 2014, Etienne Kneuss wrote:
On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski z...@zend.com wrote:
Once the RFC is approved (I hope)
Before the merge RFC can be considered for voting, I think it is
critical that you provide a comprehensive migration guide highlighting
the
I'll try to do this.
It would be great, if someone may help.
Thanks. Dmitry.
On Tue, Jul 22, 2014 at 5:18 PM, Etienne Kneuss etienne.kne...@epfl.ch
wrote:
On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski z...@zend.com wrote:
Once the RFC is approved (I hope)
Before the merge RFC can be
On 22/07/14 14:37, Derick Rethans wrote:
Before the merge RFC can be considered for voting, I think it is
critical that you provide a comprehensive migration guide highlighting
the changes required from core developers. This means
https://wiki.php.net/phpng-upgrading should be completed
Jannik Zschiesche wrote (on 22/07/2014):
the point Derick was trying to make is that you can’t build a scanner that
automatically checks whether you rewrote this particular piece of code already
or not.
You can find the code pieces which match the constructs affected by the BC, but
the
On 22 Jul 2014, at 14:47, Rowan Collins rowan.coll...@gmail.com wrote:
I thought for each ambiguous case whose behaviour would change, there is a
pair of unambiguous forms (one for each interpretation) which work the same
under both parsers?
That’s correct. For projects you want to run on
On 22 Jul 2014, at 14:27, Rowan Collins rowan.coll...@gmail.com wrote:
the RFC would be much better with a different structure. Currently, it's laid
out in what you might call an adversarial style - arguments for one side,
then arguments for the other; this doesn't lend itself well to
On Tue, Jul 22, 2014 at 2:56 PM, Andrea Faulds a...@ajf.me wrote:
On 22 Jul 2014, at 14:27, Rowan Collins rowan.coll...@gmail.com wrote:
Maybe if I have some time I’ll try to restructure the RFC.
--
Andrea Faulds
http://ajf.me/
Or, (maybe this is controversial in itself), drop the entire
On 22/07/2014 15:37, Derick Rethans wrote:
On Tue, 22 Jul 2014, Etienne Kneuss wrote:
On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski z...@zend.com wrote:
Once the RFC is approved (I hope)
Before the merge RFC can be considered for voting, I think it is
critical that you provide a
On 22 Jul 2014, at 15:12, Jonny Stirling phoe...@jonstirling.co.uk wrote:
Or, (maybe this is controversial in itself), drop the entire thing.
Until there is in fact, a next major version, what its name will be is surely
moot, and until there is a GA release (or at the earliest alphas /
Yasuo,
However, I don't mind at all to write RFC raising E_NOTICE for
password_hash()
with PASSWORD_BCRYPT.
Awesome, thanks!
Although cryptgraphic hash functions are supposed work cryptgraphic way, but
many of them are failing. This was in real world and I aware of the risk.
It's less
On Tue, Jul 22, 2014 at 4:10 PM, Matteo Beccati p...@beccati.com wrote:
On 22/07/2014 15:37, Derick Rethans wrote:
On Tue, 22 Jul 2014, Etienne Kneuss wrote:
On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski z...@zend.com wrote:
Once the RFC is approved (I hope)
Before the merge RFC
On Tue, Jul 22, 2014 at 3:22 PM, Andrea Faulds a...@ajf.me wrote:
On 22 Jul 2014, at 15:12, Jonny Stirling phoe...@jonstirling.co.uk
wrote:
Or, (maybe this is controversial in itself), drop the entire thing.
Until there is in fact, a next major version, what its name will be is
surely
Hi,
On Tue, Jul 22, 2014 at 3:18 PM, Etienne Kneuss etienne.kne...@epfl.ch wrote:
This means https://wiki.php.net/phpng-upgrading should be completed to
reflect all changes.
as a pure consumer maintaining some internal extensions, I would very
much like to see this too, at least when you
Or, (maybe this is controversial in itself), drop the entire thing.
Until there is in fact, a next major version, what its name will be is
surely moot, and until there is a GA release (or at the earliest alphas /
beta test releases), there should be no such thing as a versioned /
numbered
-Original Message-
From: Kris Craig [mailto:kris.cr...@gmail.com]
Sent: Tuesday, July 22, 2014 8:59 AM
To: Michael Wallner
Cc: Andrea Faulds; PHP Internals; Derick Rethans; Nikita Popov
Subject: Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP
Andrea and Zeev,
If it's not
On Tue, Jul 22, 2014 at 4:35 PM, Brian Moon br...@moonspot.net wrote:
Or, (maybe this is controversial in itself), drop the entire thing.
Until there is in fact, a next major version, what its name will be is
surely moot, and until there is a GA release (or at the earliest alphas /
beta test
On 22 Jul 2014, at 15:38, Zeev Suraski z...@zend.com wrote:
I made some more edits and I think the Case for 7 is ready.
We're ready to go to a vote as early as tomorrow as far as I'm concerned…
I quite like what you’ve done to the PHP 6 section, it’s much nicer than it was
before, thanks!
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Tuesday, July 22, 2014 4:56 PM
To: Rowan Collins
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP
Maybe if I have some time I'll try to restructure the RFC.
Please don't.
I think the way it's laid out
-Original Message-
From: Andrea Faulds [mailto:a...@ajf.me]
Sent: Tuesday, July 22, 2014 5:42 PM
To: Zeev Suraski
Cc: Kris Craig; PHP Internals
Subject: Re: [PHP-DEV] [VOTE][RFC] Name of Next Release of PHP
On 22 Jul 2014, at 15:38, Zeev Suraski z...@zend.com wrote:
I made some
On 22 Jul 2014, at 15:48, Zeev Suraski z...@zend.com wrote:
Maybe if I have some time I'll try to restructure the RFC.
Please don’t.
I was going to, but I’m actually happy with it now, so I won’t bother.
To those who are saying 'let's bury it for now', I absolutely think we
should go all
On 22 Jul 2014, at 15:51, Zeev Suraski z...@zend.com wrote:
You're welcome! But really, the glory belongs to Nikita - he rewrote this
section (and moved it below the Case for 7, for whatever reasons :)
Actually, I moved it below the Case for 7, because I realised that most of the
case for
On 22/07/14 15:30, Jonny Stirling wrote:
PHP6 / 7 / whatever, does not exist, and will not exist (like I said) until
official releases as the next major version are put out. Tis a pretty
simple solution for a problem that does not actually exist in the present.
PHP6 existed - it was simply
Maybe then an option should be added to vote not now or similar. You're
forcing people into a decision for this or that when some may not wish for
the decision to be made right now, and without the ability to abstain from
either option.
Neither of you are going to change your minds anyway, and
On Tue, Jul 22, 2014 at 2:04 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Jul 22, 2014 at 1:48 PM, Nikita Popov nikita@gmail.com wrote:
On Tue, Jul 22, 2014 at 12:27 PM, Ferenc Kovacs tyr...@gmail.com wrote:
sorry for the late reply.
you are right and after looking into the
Zeev Suraski wrote (on 22/07/2014):
I think the way it's laid out right now makes sense. Let's not try to
sweep this under the carpet - we two mutually exclusive options and we
need to decide between them.
How is laying out the arguments more clearly sweeping it under the
carpet? The
On 22 ביול 2014, at 19:25, Rowan Collins rowan.coll...@gmail.com wrote:
Zeev Suraski wrote (on 22/07/2014):
I think the way it's laid out right now makes sense. Let's not try to
sweep this under the carpet - we two mutually exclusive options and we
need to decide between them.
How is
Zeev Suraski wrote (on 22/07/2014):
If I understood you correctly you seem to believe that we should aim
for consensus when it's pretty clear there isn't going to be one. I
can't see how shuffling the points around under topics will somehow
help us create such consensus. Knowing many of the
I got the vibe that people weren't happy with the RFC, and that's why
the vote was cancelled, so I was suggesting a way forward, but maybe I
misread the situation.
I think that was 2 days and many, many emails ago. The parties that
expressed an opinion on the RFC which led to the vote being
On 22 Jul 2014, at 18:21, Rowan Collins rowan.coll...@gmail.com wrote:
I got the vibe that people weren't happy with the RFC, and that's why the
vote was cancelled, so I was suggesting a way forward, but maybe I misread
the situation.
I cancelled it because Zeev’s edits took me by
Brian Moon wrote (on 22/07/2014):
I got the vibe that people weren't happy with the RFC, and that's why
the vote was cancelled, so I was suggesting a way forward, but maybe I
misread the situation.
I think that was 2 days and many, many emails ago. The parties that
expressed an opinion on the
On Tue, Jul 22, 2014 at 7:47 PM, Rowan Collins rowan.coll...@gmail.com wrote:
Brian Moon wrote (on 22/07/2014):
I got the vibe that people weren't happy with the RFC, and that's why
the vote was cancelled, so I was suggesting a way forward, but maybe I
misread the situation.
I think that
Hi!
According to PHP 5.3 EOL RFC, we've now a month past official EOL date,
but we've planned to make one final release incorporating most important
fixes from upper branches since the last 5.3 release. To help with that,
I've created a pull here:
https://github.com/php/php-src/pull/730
Hi,
On Tue, 2014-07-22 at 11:53 -0700, Stas Malyshev wrote:
Hi!
According to PHP 5.3 EOL RFC, we've now a month past official EOL date,
but we've planned to make one final release incorporating most important
fixes from upper branches since the last 5.3 release. To help with that,
I've
Morning,
I propose deprecating two GD functions: imagettftext and imagettfbbox.
The reasons I would like to deprecate them are:
1. Their functionality is a subset of imagefttext and imageftbbox
2. The imagettf* functions have the same requirements as the imageft* functions
3. The imagettf*
On Tue, Jul 22, 2014 at 8:59 PM, Johannes Schlüter johan...@php.net wrote:
Hi,
On Tue, 2014-07-22 at 11:53 -0700, Stas Malyshev wrote:
Hi!
According to PHP 5.3 EOL RFC, we've now a month past official EOL date,
but we've planned to make one final release incorporating most
important
Hi!
Thanks for the work! The list looks good. Any opinions on #67541? WHich
was requested there? going strict by the rules it won't qualify.
In principle, I don't have anything against it but I'm not familiar with
the code there enough to understand the full set of consequences. I'd
like to
Hi!
not sure, have you seen https://bugs.php.net/bug.php?id=67606 ?
This is worrying. Looks like the patch is not as safe as we've hoped,
and causes BC issues for mod_fastcgi, so maybe we should not get it into
5.3. Once it stabilizes, we can backport it into 5.4, but for 5.3 better
safe than
On Tue, 2014-07-22 at 21:05 +0200, Ferenc Kovacs wrote:
Thanks for the work! The list looks good. Any opinions on
#67541? WHich
was requested there? going strict by the rules it won't
qualify.
johannes
not sure, have
On 22 Jul 2014, at 21:10, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
not sure, have you seen https://bugs.php.net/bug.php?id=67606 ?
This is worrying. Looks like the patch is not as safe as we've hoped,
and causes BC issues for mod_fastcgi, so maybe we should not get it into
5.3.
Just announced something at OSCON that's probably going to get a lot
of folks talking and making assumptions, so before things get out of
hand, I want to provide some context.
We (As in PHP) have been talking about making a spec for the PHP
language for a LONG time. With PHPNG around the corner,
On Tue, 2014-07-22 at 21:41 +0200, David Zuelke wrote:
On 22 Jul 2014, at 21:10, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
not sure, have you seen https://bugs.php.net/bug.php?id=67606 ?
This is worrying. Looks like the patch is not as safe as we've hoped,
and causes BC
Hi all,
I like to create an RFC to add an unsinged integer type for the
following purposes:
- higher max value
- DBs already allow UNSIGNED INT/BIGINT which is a farce to work with
in PHP
- better support pack/unpack unsigned integers from/to PHP using the
un/pack functions
- simplified right
Hi all,
I have a new email address ending @mabe.berlin but I can't confirm
this in the ML :(
Marc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi all,
I like to create an RFC to add an unsinged integer type for the
following purposes:
- higher max value
- DBs already allow UNSIGNED INT/BIGINT which is a farce to work with
in PHP
- better support pack/unpack unsigned integers from/to PHP using the
un/pack functions
- simplified right
Hi all,
I like to create an RFC to add an unsinged integer type for the
following purposes:
- higher max value
- DBs already allow UNSIGNED INT/BIGINT which is a farce to work with
in PHP
- better support pack/unpack unsigned integers from/to PHP using the
un/pack functions
- simplified right
On 22/07/2014 20:55, Marc Bennewitz wrote:
I like to create an RFC to add an unsinged integer type
+1 for not turning the iron up too high when doing your maths!
[https://en.wiktionary.org/wiki/singe]
Sorry, it's a common typo, but it made me chuckle that you used it in
both the subject and
Sara, I can't even begin to thank you and your team enough for this. This
is incredibly huge.
You're right, a spec has become even more important with new engines and
implementations like PHPNG and HHVM in the works. I wondered if this were
to ever happen. It never seemed like anyone in the PHP
On Tue, Jul 22, 2014 at 9:55 PM, Marc Bennewitz p...@marc-bennewitz.de
wrote:
Hi all,
I like to create an RFC to add an unsinged integer type for the
following purposes:
- higher max value
- DBs already allow UNSIGNED INT/BIGINT which is a farce to work with
in PHP
- better support
ups (typo + copy past error)
It's not my day today!
On 22.07.2014 22:21, Rowan Collins wrote:
On 22/07/2014 20:55, Marc Bennewitz wrote:
I like to create an RFC to add an unsinged integer type
+1 for not turning the iron up too high when doing your maths!
I mean a new scalar type here
On 22.07.2014 22:33, Nikita Popov wrote:
On Tue, Jul 22, 2014 at 9:55 PM, Marc Bennewitz p...@marc-bennewitz.de
wrote:
Hi all,
I like to create an RFC to add an unsigned integer type for the
following purposes:
- higher max value
- DBs already allow
On 22 Jul 2014, at 18:50, Marc Bennewitz php@mabe.berlin wrote:
I like to create an RFC to add an unsinged integer type for the
following purposes:
- higher max value
- DBs already allow UNSIGNED INT/BIGINT which is a farce to work with
in PHP
- better support pack/unpack unsigned
On 22 Jul 2014, at 20:50, Sara Golemon poll...@php.net wrote:
To that end, we (as in Facebook), have been putting together a formal
language spec for PHP (using PHP 5.6 as the source of truth) along
with an additional conformance test suite (which compliments
Zend/tests). We've talked to
On 22 Jul 2014, at 21:21, Rowan Collins rowan.coll...@gmail.com wrote:
More seriously, UnsignedInt might go nicely alongside Andrea's BigInts…
Bigints kinda remove the need for unsigned ints as you’d be able to use big
signed integers of any size. I also really don’t want unsigned int because
On Tue, Jul 22, 2014 at 12:50 PM, Sara Golemon poll...@php.net wrote:
This document is meant for PHP, and PHP should be the steward of it
going forward, so we (as in PHP) should start looking at good ways to
keep it up to date and revise it over time.
Some folks in IRC asked for clarification
hi Bob,
I still think that current array usage in constant expressions is not
consistent and dangerous. It smells to me, and I think it may bring
troubles in the future even if the existing known bugs are fixed.
I see few issues:
1) It is possible to declare array class constants however they
On 22 Jul 2014, at 23:22, Sara Golemon poll...@php.net wrote:
We're happy to setup the framework for curating that document
(probably as a github project), but don't want to be all controlling
with it, so if the PHP Group as an organization wants to own it and
manage updates to it over time,
On Tue, Jul 22, 2014 at 3:09 PM, Andrea Faulds a...@ajf.me wrote:
Good luck documenting PHP’s inconsistent semantics, though.
It’ll either be endlessly detailed, or not matching PHP 5.6.
To be honest, I think we should probably clean up PHP’s
semantics so they can be more clearly specified.
On 22 Jul 2014, at 23:32, Sara Golemon poll...@php.net wrote:
As you suppose, some of that bulk is down to the kinds of things that
the Unified Variable Syntax RFC is trying to resolve. On the plus
side, the guy who's been writing the spec is insanely detail oriented
(and has experience
Hi!
To that end, we (as in Facebook), have been putting together a formal
language spec for PHP (using PHP 5.6 as the source of truth) along
with an additional conformance test suite (which compliments
Zend/tests). We've talked to some engine folks along the way to get
feedback and make
On Tue, Jul 22, 2014 at 3:34 PM, Andrea Faulds a...@ajf.me wrote:
On 22 Jul 2014, at 23:32, Sara Golemon poll...@php.net wrote:
As you suppose, some of that bulk is down to the kinds of things that
the Unified Variable Syntax RFC is trying to resolve. On the plus
side, the guy who's been
On 7/22/14, 5:32 PM, Sara Golemon wrote:
On Tue, Jul 22, 2014 at 3:09 PM, Andrea Faulds a...@ajf.me wrote:
Good luck documenting PHP’s inconsistent semantics, though.
It’ll either be endlessly detailed, or not matching PHP 5.6.
To be honest, I think we should probably clean up PHP’s
semantics
On 22 Jul 2014, at 23:37, Larry Garfield la...@garfieldtech.com wrote:
The big question here, though, is whether, going forward, we'll be able to
mentally switch to a spec first mentality. If not, the spec will get out
of date and become less than useful. I hope we're able to make that
Hi Andrea,
very nice RFC!
You have added the new type internally only. Does it make sense or would
it be possible to use one more internal type like ULONG to safe
mem/cpu in such cases because bigint/GMP objects are used only on much
higher numbers?
Marc
On 23.07.2014 00:12, Andrea Faulds
On Jul 22, 2014, at 5:41 PM, Andrea Faulds a...@ajf.me wrote:
On 22 Jul 2014, at 23:37, Larry Garfield la...@garfieldtech.com wrote:
The big question here, though, is whether, going forward, we'll be able to
mentally switch to a spec first mentality. If not, the spec will get out
of date
On 22 Jul 2014, at 23:43, Marc Bennewitz php@mabe.berlin wrote:
You have added the new type internally only. Does it make sense or would
it be possible to use one more internal type like ULONG to safe
mem/cpu in such cases because bigint/GMP objects are used only on much
higher numbers?
You
On Tue, Jul 22, 2014 at 3:41 PM, Andrea Faulds a...@ajf.me wrote:
On 22 Jul 2014, at 23:37, Larry Garfield la...@garfieldtech.com wrote:
The big question here, though, is whether, going forward, we'll be
able to mentally switch to a spec first mentality. If not, the spec will
get out of date
On 22 Jul 2014, at 23:48, Sara Golemon poll...@php.net wrote:
On Tue, Jul 22, 2014 at 3:41 PM, Andrea Faulds a...@ajf.me wrote:
On 22 Jul 2014, at 23:37, Larry Garfield la...@garfieldtech.com wrote:
The big question here, though, is whether, going forward, we'll be
able to mentally switch to
On Tue, Jul 22, 2014 at 3:56 PM, Andrea Faulds a...@ajf.me wrote:
Ah, I think you misunderstand. What I mean is that we
should only propose RFCs which change the spec
when there is already a working implementation first.
Otherwise, we might add things to the spec which won’t
or can’t get
On 23 Jul 2014, at 00:01, Sara Golemon poll...@php.net wrote:
Our RFCs tend to have implementations attached to them (in someone's
personal fork). IMO we should make creating the spec PR part of the
RFC acceptance process, and that they should be landed together. I
agree it doesn't make
Hi Anthony,
On Tue, Jul 22, 2014 at 11:27 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
However, I don't mind at all to write RFC raising E_NOTICE for
password_hash()
with PASSWORD_BCRYPT.
Awesome, thanks!
I'll write it later.
Although cryptgraphic hash functions are supposed work
1 - 100 of 105 matches
Mail list logo
