On Mon, Feb 9, 2015 at 2:48 PM, Jan Ehrhardt wrote:
> Pierre Joye in php.internals (Mon, 9 Feb 2015 09:40:21 +0700):
>>Should we push json_parser.tab.c? Which is generated (re2c), just like
>>what is done in date or other?
>
> Yes, you should. I ran into this problem when I tried to compile PHP7
>
Pierre Joye in php.internals (Mon, 9 Feb 2015 09:40:21 +0700):
>Should we push json_parser.tab.c? Which is generated (re2c), just like
>what is done in date or other?
Yes, you should. I ran into this problem when I tried to compile PHP7
from git head. The Windows builds are currently broken:
http:
Hi Maciej,
On Mon, Feb 9, 2015 at 1:48 PM, Maciej Sobaczewski wrote:
> I'm totally aware that those files are tend to be more up-to-date thanks
> to placing them directly where core developers work. However, we have wiki
> pages for internals stuff, so why not move it to the manual and provide
>
Hi all,
On Mon, Feb 9, 2015 at 3:41 PM, Yasuo Ohgaki wrote:
> On Mon, Feb 9, 2015 at 2:12 PM, Daniel Lowrey wrote:
>
>> First, let me say that I have voted against the current scalar types RFC.
>> Please do not let that color your evaluation of the rest of this message
>> ...
>>
>> I want to go
Hey:
On Mon, Feb 9, 2015 at 5:06 AM, Jan Ehrhardt wrote:
> Rasmus Lerdorf in php.internals (Thu, 05 Feb 2015 17:28:37 -0500):
>>We have had quite a number of changes to the extension API and it
>>worries me a little bit how long it will take everyone to get their
>>extensions ported. We have UPGR
Hi Daniel,
On Mon, Feb 9, 2015 at 2:12 PM, Daniel Lowrey wrote:
> First, let me say that I have voted against the current scalar types RFC.
> Please do not let that color your evaluation of the rest of this message
> ...
>
> I want to go on record (for the n-th time) as being unhappy about any
>
Hey:
On Mon, Feb 9, 2015 at 1:44 PM, Pierre Joye wrote:
> On Mon, Feb 9, 2015 at 11:10 AM, Xinchen Hui wrote:
>> Hey:
>>
>> On Mon, Feb 9, 2015 at 10:40 AM, Pierre Joye wrote:
>>> hi,
>>>
>>> Should we push json_parser.tab.c? Which is generated (re2c), just like
>>> what is done in date or ot
Hi Guilherme,
On Mon, Feb 9, 2015 at 1:44 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Class invariants could be done as this example:
>
> class Foo {
> private function isValidState() {
> // Checks class's state and returns boolean
> }
>
> public functi
On Mon, Feb 9, 2015 at 11:10 AM, Xinchen Hui wrote:
> Hey:
>
> On Mon, Feb 9, 2015 at 10:40 AM, Pierre Joye wrote:
>> hi,
>>
>> Should we push json_parser.tab.c? Which is generated (re2c), just like
>> what is done in date or other?
>>
> I think we should, and also use a better name...(.tab.c?)
First, let me say that I have voted against the current scalar types RFC.
Please do not let that color your evaluation of the rest of this message ...
I want to go on record (for the n-th time) as being unhappy about any
proposal that forces me to use php.ini. IMHO if it doesn't work with `$ php
-
Hello Jan,
An annotated diff would be very welcome! But more or less complete
documentation as well.
Jan
What about placing such informations in the section of PHP manual like
http://php.net/manual/en/internals2.php (for ZE3, of course). I suspect
that writing regular text files in repo or
Hi Yasuo,
Class invariants could be done as this example:
class Foo {
private function isValidState() {
// Checks class's state and returns boolean
}
public function doSomething($args) {
// Some complex operation over Foo instance using $args
// then...
Hi Guilherme,
On Mon, Feb 9, 2015 at 11:58 AM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Design by Contract could be used at the top of Annotation if (and only if)
> it also had support for Interceptors. Since it could potentially be a
> nightmare for PHP, I don't think it's
On Sun, Feb 8, 2015 at 3:22 PM, Zeev Suraski wrote:
> I'm well aware of it as I wrote that policy. The goal of the policy was to
> prevent a situation where a temporary majority can introduce features into
> the language that would later on be impossible to reverse. It's not by any
> stretch a g
Hey:
On Mon, Feb 9, 2015 at 10:40 AM, Pierre Joye wrote:
> hi,
>
> Should we push json_parser.tab.c? Which is generated (re2c), just like
> what is done in date or other?
>
I think we should, and also use a better name...(.tab.c?)
thanks
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd
> On 9 בפבר׳ 2015, at 02:04, Jordi Boggiano wrote:
>
>> On 08/02/2015 23:24, Zeev Suraski wrote:
>> There's zero or virtually zero controversy surrounding the weak typing RFC,
>> the one that was v0.1. The controversy wasn't (and isn't) about what was in
>> v0.1, but rather, about what wasn't i
Hi!
> Should we push json_parser.tab.c? Which is generated (re2c), just like
> what is done in date or other?
I think we should, otherwise building from release package without re2c
would be impossible, and I think before it was possible. In any case, we
should be consistent - if we commit genera
> On 9 בפבר׳ 2015, at 01:45, Andrea Faulds wrote:
>
> Hi Zeev,
>
>> On 8 Feb 2015, at 23:24, Zeev Suraski wrote:
>>
>> It's not stretching the truth or even slightly bending it, considering the
>> RFC currently being voted on is a superset of that RFC.
>
> That has no relevancy.
I'll have t
On Feb 9, 2015 10:29 AM, "Yasuo Ohgaki" wrote:
>
> Hi Matt and all,
>
> On Mon, Feb 9, 2015 at 6:52 AM, Matt Parker
wrote:
>
> > The first question was 'Did you read the RFC' and the second 'Would
> > you like the RFC to
> > pass'. I set it up Friday morning (GMT) and tweeted it around a bit
> >
Hi Matt and all,
On Mon, Feb 9, 2015 at 6:52 AM, Matt Parker wrote:
> The first question was 'Did you read the RFC' and the second 'Would
> you like the RFC to
> pass'. I set it up Friday morning (GMT) and tweeted it around a bit
> (I have a grand total
> of 58 followers on twitter). So this r
Hi Yasuo,
Design by Contract could be used at the top of Annotation if (and only if)
it also had support for Interceptors. Since it could potentially be a
nightmare for PHP, I don't think it's time to propose something at the top
of another thing that is still far from being reality.
It would foll
hi,
Should we push json_parser.tab.c? Which is generated (re2c), just like
what is done in date or other?
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2015-02-09 2:26 GMT+02:00 Rowan Collins :
> On 09/02/2015 00:02, S.A.N wrote:
>>
>> You're right, but there is no threading issues.
>> One worker synchronously execute requests, but may run parallel many
>> workers.
>
>
> I'm not sure what you mean by this. I can see 3 ways of handling incoming
> w
On 09/02/15 00:05, Rowan Collins wrote:
>> Some of the new 'styles' of writing things are
>> going to make things considerably worse for those who are going to have
>> to maintain this code in the future.
>
> If you're writing code that you know will be hard to maintain in the
> future, you're d
Hi Stas,
On Mon, Feb 9, 2015 at 8:11 AM, Stanislav Malyshev
wrote:
> > Following our conversation, I tried to imagine how DbC should look like
> in
> > PHP from user perspective. Finally, I was influenced by the semantic
> > proposed in D, and syntax proposed for Java. So, these are my initial
>
On Mon, Feb 9, 2015 at 7:47 AM, Andrey Andreev wrote:
> Hi,
>
> On Mon, Feb 9, 2015 at 2:10 AM, Pierre Joye wrote:
>> There is a vote, you do not like the RFC or part of
>> it, vote no. But this constant attempt to get exactly what you want
>> and do almost everything possible to get it is gettin
Hi,
On Mon, Feb 9, 2015 at 2:10 AM, Pierre Joye wrote:
> There is a vote, you do not like the RFC or part of
> it, vote no. But this constant attempt to get exactly what you want
> and do almost everything possible to get it is getting very counter
> productive.
I want to note that this should c
On 09/02/2015 00:05, Andrea Faulds wrote:
Secondly, it is less specific than the current proposal - it suggests that PHP has a generic
"strict mode", rather than a "strict type-checking" mode.
It could be renamed to strict_types, but that loses some elegant.
Would more "strict" features be ad
On 09/02/2015 00:02, S.A.N wrote:
You're right, but there is no threading issues.
One worker synchronously execute requests, but may run parallel many workers.
I'm not sure what you mean by this. I can see 3 ways of handling
incoming web requests, as it affects PHP's threading:
A) The curren
On Mon, Feb 9, 2015 at 6:24 AM, Zeev Suraski wrote:
>> So, controversy is where a lot of people disagree - and there were
>> numerous
>> people in the original thread who disagreed with the RFC and preferred
>> strict
>> types. I actually tallied them in a reply to Zeev (which I later quoted in
>>
On Mon, Feb 9, 2015 at 3:33 AM, Zeev Suraski wrote:
> FWIW, while I think strict types - stricter than even strict languages -
> don't belong in PHP, this syntax is clearly a step up from declare(), which
> was definitely not intended for this purpose.
I think we get it, you do not like the grou
Hi,
> On 8 Feb 2015, at 23:22, Rowan Collins wrote:
>
> On 08/02/2015 19:44, Andrea Faulds wrote:
>> Hi,
>>
>> I’m posting this in a new thread since people might (reasonably) be ignoring
>> further responses to the [VOTE] thread.
>
> Incidentally, you still used "reply" to create this messag
On Mon, Feb 9, 2015 at 6:30 AM, Rowan Collins wrote:
> On 08/02/2015 20:33, Zeev Suraski wrote:
>>
>> FWIW, while I think strict types - stricter than even strict languages -
>> don't belong in PHP, this syntax is clearly a step up from declare(),
>> which
>> was definitely not intended for this p
On 08/02/2015 20:53, Lester Caine wrote:
On 08/02/15 19:00, Rowan Collins wrote:
We have a single code base happily running on 5.2, 5.3, 5.4, and I think
even 5.5, so it is definitely possible with some code bases. There were
a few pieces that had to be changed to work right under 5.3 and 5.4, b
On 08/02/2015 23:24, Zeev Suraski wrote:
There's zero or virtually zero controversy surrounding the weak typing RFC,
the one that was v0.1. The controversy wasn't (and isn't) about what was in
v0.1, but rather, about what wasn't in there, namely, strict typing; Not in
the contents of the v0.1 R
hi,
On Mon, Feb 9, 2015 at 2:44 AM, Andrea Faulds wrote:
> Hi,
>
> I’m posting this in a new thread since people might (reasonably) be ignoring
> further responses to the [VOTE] thread.
>
> I’m considering a small change to the Scalar Type Hints RFC, specifically
> about syntax. Quite a few peo
2015-02-09 1:48 GMT+02:00 Rowan Collins :
> On 08/02/2015 22:48, S.A.N wrote:
>>
>> Hi internals.
>>
>> I really hope that in the future PHP 7, there will be new server API.
>> May be you interested to know about them, here is the link, I am not
>> the author of development:
>> https://github.com/u
On 08/02/2015 22:48, S.A.N wrote:
Hi internals.
I really hope that in the future PHP 7, there will be new server API.
May be you interested to know about them, here is the link, I am not
the author of development:
https://github.com/unbit/uwsgi-phpsgi/
But the problem is that in PHP there are n
Hi Zeev,
> On 8 Feb 2015, at 23:24, Zeev Suraski wrote:
>
> It's not stretching the truth or even slightly bending it, considering the
> RFC currently being voted on is a superset of that RFC.
That has no relevancy.
> There's zero or virtually zero controversy surrounding the weak typing RFC,
On 08/02/2015 20:33, Zeev Suraski wrote:
FWIW, while I think strict types - stricter than even strict languages -
don't belong in PHP, this syntax is clearly a step up from declare(), which
was definitely not intended for this purpose.
I'm kind of intrigued what purpose it *was* intended for. I
> So, controversy is where a lot of people disagree - and there were
> numerous
> people in the original thread who disagreed with the RFC and preferred
> strict
> types. I actually tallied them in a reply to Zeev (which I later quoted in
> a reply
> to Andi). There were almost as many people again
Hi!
> On 2/8/15, 11:38 AM, "Derick Rethans" wrote:
>>
>> Btw, I only voted no because I don't think we should just remove it. A
>> reimplementation of its APIs on top of eg. Open SSL makes sense. And that
>> I'd vote yes for.
>
> This idea makes me nervous. It doesn't sound at all easy and will
On 08/02/2015 19:44, Andrea Faulds wrote:
Hi,
I’m posting this in a new thread since people might (reasonably) be ignoring
further responses to the [VOTE] thread.
Incidentally, you still used "reply" to create this message, so mail
readers which base threads on headers (e.g. Thunderbird) rat
Hi!
> Following our conversation, I tried to imagine how DbC should look like in
> PHP from user perspective. Finally, I was influenced by the semantic
> proposed in D, and syntax proposed for Java. So, these are my initial
> thoughts:
>
> For php it may look like the following:
>
> function foo
Hi,
> On 8 Feb 2015, at 23:03, Stanislav Malyshev wrote:
>
>>> Last, voters should take into account that this isn't an 'either this RFC or
>>> nothing' situation. I think it's very unfortunate that the original RFC -
>>> that had zero controversy surrounding it - was never put to a vote.
>>
>
Hi!
>> Last, voters should take into account that this isn't an 'either this RFC or
>> nothing' situation. I think it's very unfortunate that the original RFC -
>> that had zero controversy surrounding it - was never put to a vote.
>
> Please stop repeating this, it is blatantly false and I’ve p
Hi Francois,
On Mon, Feb 9, 2015 at 12:43 AM, François Laupretre
wrote:
> > De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
> Ohgaki
> >
> > Since people's preferences are diverse. It might be a good idea having
> pre-vote
> > for designs, then we may have final vote with s
Hi internals.
I really hope that in the future PHP 7, there will be new server API.
May be you interested to know about them, here is the link, I am not
the author of development:
https://github.com/unbit/uwsgi-phpsgi/
But the problem is that in PHP there are no standards for such interfaces.
Now
Hi Ferenc,
> On 8 Feb 2015, at 22:18, Ferenc Kovacs wrote:
>
> I've voted no for two reasons:
> 1, I don't really like the the proposed declare solution, I know that you put
> much thought and effort with finding a way to make the strict hints opt-in
> for the caller, but I think it is still n
Hi!
> Are you saying performance is not the reason we use persistent handles?
It is, for databases where connection setup is expensive. Even then
persistent handles are not always the best solution. But with DB, you
routinely connect to one service, with one set of credentials, and need
this conn
Does anybody have a working Eclipse setup for building php-src and
extensions? I keep hitting 'phpsrc' when I try using google which just
about sums up how bad google is these days :(
As soon as one tries to drill down all one gets is pages with php in the
url ...
--
Lester Caine - G8HFL
---
On Thu, Feb 5, 2015 at 9:14 PM, Andrea Faulds wrote:
> Good evening,
>
> At long last, I’m going to put the RFC to a vote. It’s been long enough -
> I don’t think there needs to be, or will be, much further discussion.
>
> I’d like to make sure that everyone voting understands the RFC fully.
> Pl
Hi,
> On 8 Feb 2015, at 21:48, Marc Bennewitz wrote:
>
> Wrapping all in objects isn't an option. This would only add unnecessary
> overhead and only move the issue to a different place.
I don’t see why not. Objects are generally exempt from type juggling, except
for conversion to strings.
S
Hello,
First of all, thank you for php. Secondly, I hope this doesn't come
across as impertinent.
I'm an average user of php. I don't know enough about programming
languages to contribute
here; but I do try and keep up with what's going on in the php core.
I was curious what the userland view
Hi Andrea,
Am 08.02.2015 um 22:09 schrieb Andrea Faulds:
Hi,
On 8 Feb 2015, at 20:10, Marc Bennewitz wrote:
Since PHP-5.2.1 we have an artifact of PHP-6 in the engine means we can define
binary strings but such definitions haven't any effect.
Yes. That’s because PHP 6 was going to have Uni
> -Original Message-
> From: Matthew Leverton [mailto:lever...@gmail.com]
> Sent: Sunday, February 08, 2015 11:17 PM
> To: Zeev Suraski
> Cc: Jordi Boggiano; PHP internals
> Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
>
> On Sun, Feb 8, 2015 at 1:48 PM, Zeev Suraski wrote:
> >
> > prop
On Sun, Feb 8, 2015 at 1:48 PM, Zeev Suraski wrote:
>
> proposal everyone can rally behind, it very clearly failed. We didn't have
> to wait for a vote by the way, it was clear from the discussion on
> internals@.
>
Controversial RFCs are precisely the ones that SHOULD be voted on.
Policy states
> De : Jordi Boggiano [mailto:j.boggi...@seld.be]
> Envoyé : dimanche 8 février 2015 19:12
> À : internals@lists.php.net
> Objet : Re: [PHP-DEV] [VOTE] Scalar Type Hints
>
> On 07/02/2015 01:08, Sebastian Bergmann wrote:
> > On 02/06/2015 10:22 PM, Nikita Popov wrote:
> >> After much initial reluc
Hi,
> On 8 Feb 2015, at 20:10, Marc Bennewitz wrote:
>
> Since PHP-5.2.1 we have an artifact of PHP-6 in the engine means we can
> define binary strings but such definitions haven't any effect.
Yes. That’s because PHP 6 was going to have Unicode strings by default,
alongside binary strings (t
Rasmus Lerdorf in php.internals (Thu, 05 Feb 2015 17:28:37 -0500):
>We have had quite a number of changes to the extension API and it
>worries me a little bit how long it will take everyone to get their
>extensions ported. We have UPGRADING.INTERNALS which still needs some
>love, but even if that c
Hi François,
On 8 Feb 2015, at 20:43, François Laupretre wrote:
>> De : Andrea Faulds [mailto:a...@ajf.me]
>> Instead, I’m wondering if the following might be better:
>>
>>>
>> Which would be used like so:
>>
>>>
>>function foobar(): int {
>>return 1.0; // error!
>>}
On 08/02/15 19:00, Rowan Collins wrote:
> We have a single code base happily running on 5.2, 5.3, 5.4, and I think
> even 5.5, so it is definitely possible with some code bases. There were
> a few pieces that had to be changed to work right under 5.3 and 5.4, but
> none for which the new solution d
> De : Andrea Faulds [mailto:a...@ajf.me]
> Instead, I’m wondering if the following might be better:
>
>
> Which would be used like so:
>
>
> function foobar(): int {
> return 1.0; // error!
> }
>
> It’d be a per-file directive, so there’d be zero mixing of modes with
On Sun, Feb 8, 2015 at 2:18 PM, Tom Worster wrote:
>
> On 2/8/15, 12:52 PM, "Daniel Lowrey" wrote:
>
> >On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster wrote:
> >>
> >> Thanks Damien and Daniel for the info.
> >>
> >> I am not concerned about running out of entropy. I am concerned about
> >> usersp
FWIW, while I think strict types - stricter than even strict languages -
don't belong in PHP, this syntax is clearly a step up from declare(), which
was definitely not intended for this purpose.
Zeev
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Sunday, February
Hi all,
Since PHP-5.2.1 we have an artifact of PHP-6 in the engine means we can
define binary strings but such definitions haven't any effect.
So what we can define is the following:
$str = "str";
$bin = b"b\0i\0n";
$str2bin = (binary)$str;
One of the biggest issue is that currently ALL stri
On 08/02/2015 09:03, Yasuo Ohgaki wrote:
If this was a PHP_INI_PERDIR setting, then I wouldn't really mind as much.
>
>But as PHP_INI_USER, I don't like it at all.
How about allow to set the ini only once during execution?
Like open_baedir [1], it should probably be possible to *tighten* the
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Sunday, February 08, 2015 9:50 PM
> To: Zeev Suraski
> Cc: Jordi Boggiano; internals@lists.php.net
> Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
>
> Zeev,
>
> > On 8 Feb 2015, at 19:48, Zeev Suraski wrote:
> >
> >
Zeev,
> On 8 Feb 2015, at 19:48, Zeev Suraski wrote:
>
> Last, voters should take into account that this isn't an 'either this RFC or
> nothing' situation. I think it's very unfortunate that the original RFC -
> that had zero controversy surrounding it - was never put to a vote.
Please stop re
> -Original Message-
> From: Jordi Boggiano [mailto:j.boggi...@seld.be]
> Sent: Sunday, February 08, 2015 8:12 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
>
> On 07/02/2015 01:08, Sebastian Bergmann wrote:
> > On 02/06/2015 10:22 PM, Nikita Popov wrote
Hi,
I’m posting this in a new thread since people might (reasonably) be ignoring
further responses to the [VOTE] thread.
I’m considering a small change to the Scalar Type Hints RFC, specifically about
syntax. Quite a few people have said they don’t like the declare() syntax, and
it’s easy to
On 08/02/2015 09:20, Patrick Schaaf wrote:
Am 08.02.2015 03:39 schrieb "Rasmus Lerdorf" :
Basically declare() does not respect function scope, but it doesn't let
you know that. There is a reason we haven't used declare() for anything
real.
That is absolutely awful. But it's a fault with declare
On 2/8/15, 12:52 PM, "Daniel Lowrey" wrote:
>On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster wrote:
>>
>> Thanks Damien and Daniel for the info.
>>
>> I am not concerned about running out of entropy. I am concerned about
>> userspace RNGs such as OpenSSL
>> http://sockpuppet.org/blog/2014/02/25/saf
On 08/02/2015 12:30, Lester Caine wrote:
Currently it is impossible to run the PHP5.2 code base on PHP5.4. That
is a simple fact. So I can't do between 5.2 and 5.4 what I am currently
doing between 5.4 and 7. The code has to be reworked ... so what ever
anybody says PHP5 .4*IS* PHP6 in terms of
On 08/02/2015 11:45, Matteo Beccati wrote:
On 08/02/2015 11:24, Tony Marston wrote:
Well said. If it is not possible to have a single codebase that runs in
both PHP 5 *AND* PHP 7 then that will be a total disaster.
Of course you can have a single codebase running both on PHP5 and
PHP7, unless
On Thu, Feb 5, 2015 at 10:41 PM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
>
> My biggest concern about all this breakage done for NG could somehow be
> minimized by providing possible alternate implementations that could work
> both backwards compatible and forwards compatible?
On 07/02/2015 01:08, Sebastian Bergmann wrote:
On 02/06/2015 10:22 PM, Nikita Popov wrote:
After much initial reluctance, I've voted in favor of this RFC.
After reading your email, Nikita, I deleted my vote (it was no before).
I will review the RFC again, with your arguments (and others) i
On Sun, Feb 8, 2015 at 12:11 PM, Tom Worster wrote:
>
> Thanks Damien and Daniel for the info.
>
> I am not concerned about running out of entropy. I am concerned about
> userspace RNGs such as OpenSSL
> http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
Just to be clear (as Da
Hi Leigh,
On 2/8/15, 12:33 PM, "Leigh" wrote:
>
>Are we happy to accept that we'll lose access to some of mcrypts
>ciphers if we do this? I'd suspect most real world usage of php-mcrypt
>is to implement AES anyway, so most users would be covered.
I hope your suspicion is right.
I'd be happy to
On 8 February 2015 at 17:03, Pierre Joye wrote:
> I agree with Derick about wrapping ext/mcrypt around OpenSSL or other to
> keep it around for BC. I simply do not have the resources to make that
> happen so someone has to jump on it (Derick?)
>
Are we happy to accept that we'll lose access to so
Thanks Damien and Daniel for the info.
I am not concerned about running out of entropy. I am concerned about
userspace RNGs such as OpenSSL
http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
On 2/8/15, 12:04 PM, "Damien Tournoud" wrote:
>On Sun, Feb 8, 2015 at 5:15 PM, Dani
Hi Derick,
On 2/8/15, 11:38 AM, "Derick Rethans" wrote:
>
>Btw, I only voted no because I don't think we should just remove it. A
>reimplementation of its APIs on top of eg. Open SSL makes sense. And that
>I'd vote yes for.
This idea makes me nervous. It doesn't sound at all easy and will take
On Sun, Feb 8, 2015 at 5:15 PM, Daniel Lowrey wrote:
> Currently PHP's openssl_random_pseudo_bytes() uses the latter function and
> allows users to pass a by-reference $crypto_strong out parameter to
> determine if the result is cryptographically strong. This is fine if you
> know all of the abov
On Feb 8, 2015 10:44 PM, "Tom Worster" wrote:
>
> Hi Yasuo, Pierre,
>
> Thank you both for the updates.
>
> I expect the vote to remove mcrypt can be shifted towards "yes" if some
> campaigning effort is made. I made a start in another thread.
>
> Assuming that mcrypt goes, as it should, we are le
Tom Worster schreef op 8 februari 2015 15:38:15 GMT+00:00:
>mycrypt was abandoned by its developers in 2007. The package in Debian
>is
>from 2009. It has been removed from RHEL.
>
>This is already unacceptable. But it would be an insult to the idea of
>"security" to include mcrypt in PHP 7.
>
>The
On Sun, Feb 8, 2015 at 4:24 AM, Tom Worster wrote:
> 3. Will the OpenSSL ext remain as it currently stands?
There has been talk of replacing it with a more generic implementation that
can swap out the underlying components so we aren't dependent upon a single
library. The crypto extension in pe
> On 8 Feb 2015, at 15:48, Andrea Faulds wrote:
>
> If this RFC would somehow pass, yes. However, you’re introducing a competing
> proposal at the “eleventh hour”, so to speak, which is terribly nice. Unless
> there’s a radical shift in how people vote on the Scalar Type Hints RFC, it
> won’t
Hi,
> On 8 Feb 2015, at 13:32, Timm Friebe wrote:
>
>>> I personally see the benefits this could have but also the BC break this
>>> would
>>> introduce.
> [...]
>> I don't see the point of this: the Scalar Type Hints RFC already has a voting
>> option on reserving the type names, and it is set
Hi Yasuo, Pierre,
Thank you both for the updates.
I expect the vote to remove mcrypt can be shifted towards "yes" if some
campaigning effort is made. I made a start in another thread.
Assuming that mcrypt goes, as it should, we are left with a problem. The
PHP user doesn't have a platform-indepe
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki
>
> Since people's preferences are diverse. It might be a good idea having
> pre-vote
> for designs, then we may have final vote with single design.
>
> We need some consensuses even for pre-vote.
>
> What do you think?
mycrypt was abandoned by its developers in 2007. The package in Debian is
from 2009. It has been removed from RHEL.
This is already unacceptable. But it would be an insult to the idea of
"security" to include mcrypt in PHP 7.
The vote to remove mcrypt is at present tied roughly 13:13. If you have
Hi Timm
2015-02-08 13:04 GMT+01:00 Timm Friebe :
> Hello everyone,
>
> I've been following the "Static type hints" discussion for a while now. Aside
> from its content, which there are some strong sentiments about, there's also
> another recurring pattern - the wish for voting options instead of j
Hi,
> > I personally see the benefits this could have but also the BC break this
> > would
> > introduce.
[...]
> I don't see the point of this: the Scalar Type Hints RFC already has a voting
> option on reserving the type names, and it is set to pass, so by the time your
> RFC could go to a vote,
Hi Timm,
> On 8 Feb 2015, at 12:04, Timm Friebe wrote:
>
> Hello everyone,
>
> I've been following the "Static type hints" discussion for a while now.
Presumably you mean "scalar" not "static".
> Aside
> from its content, which there are some strong sentiments about, there's also
> another
On 08/02/15 11:43, Ralf Lang wrote:
> A lot of sites sticked with PHP5.3 because they were driven by
> enterprise platforms which by definition won't upgrade during the life
> cycle. That had its own costs and aches which are entirely not PHP's fault.
>
>> > PHP7 is proposing a LOT of shiny new fe
Hello everyone,
I've been following the "Static type hints" discussion for a while now. Aside
from its content, which there are some strong sentiments about, there's also
another recurring pattern - the wish for voting options instead of just
"yes/no".
Along these lines I've created an RFC on one
On 08/02/2015 11:24, Tony Marston wrote:
Well said. If it is not possible to have a single codebase that runs in
both PHP 5 *AND* PHP 7 then that will be a total disaster.
Of course you can have a single codebase running both on PHP5 and PHP7,
unless you want to use PHP7-only features.
But t
Hi Lester,
On 07.02.2015 13:36, Lester Caine wrote:
> My personal experience of PHP4 is simply one of having been developing
> all my code in PHP5.0 to 5.2 but ensuring that the code also still run
> clean on the PHP4 host.
Actually, PHP 4 changed a lot of things from PHP3. PHP 5.0.0 on the
othe
> -Ursprüngliche Nachricht-
> Von: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Gesendet: Sonntag, 8. Februar 2015 04:53
> An: Andrea Faulds
> Cc: Pavel Kouřil; PHP Internals
> Betreff: Re: [PHP-DEV] [VOTE] Scalar Type Hints
>
> On 02/07/2015 09:51 PM, Andrea Faulds wrote:
> >> tan(1);
>
"Lester Caine" wrote in message news:54d73248.9030...@lsces.co.uk...
On 08/02/15 06:37, Yasuo Ohgaki wrote:
Hi Lester,
PHP7 is proposing a LOT of shiny new features which will break much
legacy code. So the question has to be just what is the plan
regarding
cross version support.
1 - 100 of 109 matches
Mail list logo
