Hey:
On Thu, Feb 12, 2015 at 1:35 PM, Yasuo Ohgaki wrote:
> Hi Xinchen,
>
> On Thu, Feb 12, 2015 at 12:37 PM, Xinchen Hui wrote:
>>
>> > lazy_write=On: Requests per second:2218.55 [#/sec] (mean)
>> > lazy_write=Off: Requests per second:24.58 [#/sec] (mean)
>> I feel...that might be s
Hi,
On 12 February 2015 at 15:30, Dmitry Stogov wrote:
> We don't use macros with variable number of arguments in PHP.
> this is not portable.
>
We could don't have to use variadic macros, we could try something like:
*+PHPAPI void php_error_doc0(int type, const char *format, ...)*
*+{*
*+
Hi,
On Wed, Feb 11, 2015 at 10:05 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > That one actually looks better to me, but: I'm not sure how
> annotation
> > syntax is supposed to support expressions or closures,
> >
> >
> > keep AST.
>
> So we'd have a zval type that is the raw AST? Would it
We don't use macros with variable number of arguments in PHP.
this is not portable.
Thanks. Dmitry.
On Wed, Feb 11, 2015 at 6:01 PM, reeze wrote:
> Hi,
>
> On 11 February 2015 at 19:15, Dmitry Stogov wrote:
>
>> Hi,
>>
>> I don't think it'll improve something, and may complicate merging from
>
On Thu, Feb 12, 2015 at 1:13 AM, Andrea Faulds wrote:
>
> A number (or numeric, or num, or some other name) type hint is something I
> plan to propose in a future, follow-up RFC.
>
Hello,
wouldn't polymorphism (via method overloading) solve the use cases and
be much more useful in the long run
> -Original Message-
> From: Sebastian B.-Hagensen [mailto:sbj.ml.r...@gmail.com]
> Sent: Thursday, February 12, 2015 2:11 AM
> To: Zeev Suraski
> Cc: guilhermebla...@gmail.com; Rasmus Lerdorf; PHP Internals
> Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
>
> Hi,
>
> 2015-02-12 0:08 GMT+0
Hi Xinchen,
On Thu, Feb 12, 2015 at 12:37 PM, Xinchen Hui wrote:
> > lazy_write=On: Requests per second:2218.55 [#/sec] (mean)
> > lazy_write=Off: Requests per second:24.58 [#/sec] (mean)
> I feel...that might be something wrong :<
I do think so. It's Core i7 with 32GB memory and S
On Thu, Feb 12, 2015 at 10:05 AM, Yasuo Ohgaki wrote:
> Hi all,
>
> On Wed, Feb 11, 2015 at 3:51 PM, Yasuo Ohgaki wrote:
>>
>> On Wed, Feb 11, 2015 at 3:27 PM, Xinchen Hui wrote:
>>>
>>> The fails must be know... relates to key name checking
>>>
>>> the leaks needs to be take care, I will look i
Hi Yasuo,
Yasuo Ohgaki wrote:
> Hi Christoph,
>
> On Wed, Feb 11, 2015 at 10:45 AM, Christoph Becker
> wrote:
>
>>> We have been tried to educate users already and introduced some
>>> mitigations e.g. allow_url_include, open_basedir.
>>>
>>> However, enough time is passed to prove that wasn't
Hi Stas,
On Thu, Feb 12, 2015 at 3:21 AM, Stanislav Malyshev
wrote:
> > I'm not trying to be perfect, but I would like to make PHP as secure as
> > other
> > languages from script inclusion attacks. It's too easy currently...
>
> PHP is already as secure as the other languages. If you have code
Hi all,
On Wed, Feb 11, 2015 at 3:51 PM, Yasuo Ohgaki wrote:
> On Wed, Feb 11, 2015 at 3:27 PM, Xinchen Hui wrote:
>
>> The fails must be know... relates to key name checking
>>
>> the leaks needs to be take care, I will look into it.
>>
>> anyway, these should not affects your work,
>>
>
> I t
Hi Peter,
> I like the idea (reducing the repeated namespace parts), but am not too
keen on the syntax.
> If I may offer a hastily thought out, and probably terrible, idea... how
about something like "from prefix use ..." ? [...]
> That's my two cents.
Some people suggested the *"from* ... *use *
Hey Guilherme,
> On 11 Feb 2015, at 22:46, guilhermebla...@gmail.com wrote:
>
> @Andrea: I spent around 2-3 hours speaking with Anthony and the other half
> talking to Jordi (Composer, Symfony).
> I still think a few things are required to be fully usable.
> 1- Exceptions RFC (outside of your sc
Hi,
2015-02-12 0:08 GMT+01:00 Zeev Suraski :
> It gives the exact same
> value from an API author’s point of view.
But not from an api-consumers point of view. Without either
introducing a new set of casting/conversion rules or changing existing
behavior (**exclusively**) 'weak' typehints may b
Forarding again, was rejected by the list because of spammy links :(
-- Forwarded message --
From: Benjamin Eberlei
Date: Thu, Feb 12, 2015 at 12:59 AM
Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
To: Andrea Faulds
Cc: Zeev Suraski , Rasmus Lerdorf , PHP
Internals
On Wed,
Hi Marcio,
On 11 February 2015 at 20:50, Marcio Almada wrote:
> Hi internals!
>
> Since no new discussion topics appeared, the voting on the Group Use
> Declarations RFC for PHP7 is now open:
>
> RFC: https://wiki.php.net/rfc/group_use_declarations#votes
> Patch: https://github.com/php/php-src/p
On Wed, Feb 11, 2015 at 5:16 PM, Michael Wallner wrote:
>
> On 06/02/15 17:44, Daniel Lowrey wrote:
> > If you doubt that this is a solved problem in userland consider the
> > performance of my own 100% userland HTTP client demonstrated here
> > without the use of curl or any other extensions:
> >
On 11 February 2015 22:41:21 GMT, Lester Caine wrote:
>On 11/02/15 21:46, Andrea Faulds wrote:
>> Anthony Ferrara also had his own analysis which showed some of the
>problems with weak type hinting, and where strict types can be
>beneficial: http://blog.ircmaxell.com/2015/02/scalar-types-and-php.h
I said numerous times that I think that v0.1 of Andrea’s RFC was right on
the mark. I’d vote in its favor in a heartbeat. It gives the exact same
value from an API author’s point of view. It gives the exact same value in
terms of potential performance improvements/JITting/compilation insight.
Bu
On 11/02/15 21:46, Andrea Faulds wrote:
> Anthony Ferrara also had his own analysis which showed some of the problems
> with weak type hinting, and where strict types can be beneficial:
> http://blog.ircmaxell.com/2015/02/scalar-types-and-php.html
What is the point of using a 'Better static anal
On 06/02/15 17:44, Daniel Lowrey wrote:
> If you doubt that this is a solved problem in userland consider the
> performance of my own 100% userland HTTP client demonstrated here
> without the use of curl or any other extensions:
>
> https://gist.github.com/rdlowrey/54171625334670ccb9f5
I can repl
> On 11 Feb 2015, at 21:30, Zeev Suraski wrote:
>
>> -Original Message-
>> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
>> Sent: Wednesday, February 11, 2015 8:37 AM
>> To: Xinchen Hui; Andrea Faulds
>> Cc: PHP Internals
>> Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
>>
>> On 02
Le 05/02/2015 09:49, Dmitry Stogov a écrit :
The RFC is turned into voting
https://wiki.php.net/rfc/php7_foreach#proposed_voting_choices
Hi,
After discussing this RFC with other people at AFUP, it seems we are the
+1 side, on both propositions.
Thanks
--
Pascal MARTIN, AFUP - French UG
htt
Renamed to NEWS-cvs2svn
Kaplan
On Feb 11, 2015 5:11 PM, "Andrea Faulds" wrote:
> Hi,
>
> > On 11 Feb 2015, at 09:52, Lior Kaplan wrote:
> >
> > Hi,
> >
> > I've been doing some editing to the NEWS files, and keep getting this
> > problem
> >
> > $ git diff NEWS
> > fatal: ambiguous argument 'NE
> -Original Message-
> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Sent: Wednesday, February 11, 2015 8:37 AM
> To: Xinchen Hui; Andrea Faulds
> Cc: PHP Internals
> Subject: Re: [PHP-DEV] [VOTE] Scalar Type Hints
>
> On 02/10/2015 07:57 PM, Xinchen Hui wrote:
> >> am I wrong?!
> > se
On 11 February 2015 06:36:52 GMT, Rasmus Lerdorf wrote:
> And in Drupal8 *without turning on strict*:
>
> use Drupal\Component\Utility\String;
>
> it dies with: "Fatal error: "string" cannot be used as a class name in
>/var/www/drupal/core/includes/bootstrap.inc on line 11"
>
> That String clas
Hi internals!
Since no new discussion topics appeared, the voting on the Group Use
Declarations RFC for PHP7 is now open:
RFC: https://wiki.php.net/rfc/group_use_declarations#votes
Patch: https://github.com/php/php-src/pull/1005
As requested I've split the vote into two slightly different syntax
Hi!
> That one actually looks better to me, but: I'm not sure how annotation
> syntax is supposed to support expressions or closures,
>
>
> keep AST.
So we'd have a zval type that is the raw AST? Would it also be available
to user functions or internal functions/classes? It's an intrigu
Hi Pavel,
> On 11 Feb 2015, at 07:41, Pavel Kouřil wrote:
>
> Also, I realized one thing why I think the strict version is a bad
> idea for PHP (in the state PHP is now - in an ideal world I would love
> to have nothing but strongly typed PHP, but that's offtopic) - PHP has
> many functions tha
Hi Rasmus,
> On 11 Feb 2015, at 06:36, Rasmus Lerdorf wrote:
>
> And in Drupal8 *without turning on strict*:
>
> use Drupal\Component\Utility\String;
>
> it dies with: "Fatal error: "string" cannot be used as a class name in
> /var/www/drupal/core/includes/bootstrap.inc on line 11"
>
> Th
Hi,
another one of my weird ideas: what about a script signing mode?
- ini setting containing a HMAC key
- first
Hi all,
On Wed, Feb 11, 2015 at 8:15 PM, Dmitry Stogov wrote:
> I don't think it'll improve something, and may complicate merging from
> PHP5 (this is not a big issue, because merging is already not simple).
>
> In any case, the names should be swapped, to be used as:
>
> php_error_docref(E_
Hi!
> I'm not trying to be perfect, but I would like to make PHP as secure as
> other
> languages from script inclusion attacks. It's too easy currently...
PHP is already as secure as the other languages. If you have code in
Python that loads arbitrary file and executes it, you could upload
Pytho
Hi Stas,
On Wed, Feb 11, 2015 at 4:32 PM, Stanislav Malyshev
wrote:
> > Some of you are tired with this topic, but please take a look the RFC
> >
> > [RFC] Script only includes - this is 3rd version.
> > https://wiki.php.net/rfc/script_only_include
> >
> > Please let me know what you like or dis
Hi all,
On Tue, Feb 10, 2015 at 9:52 AM, Yasuo Ohgaki wrote:
> Some of you are tired with this topic, but please take a look the RFC
>
> [RFC] Script only includes - this is 3rd version.
> https://wiki.php.net/rfc/script_only_include
>
> Please let me know what you like or dislike.
>
This propo
Why not leave it as it is? I mean, really, those five strokes?
Wherever it's going, I'm -1 on changing the meaning of the existing macro.
On 11 Feb 2015 16:01, "reeze" wrote:
> Hi,
>
> On 11 February 2015 at 19:15, Dmitry Stogov wrote:
>
> > Hi,
> >
> > I don't think it'll improve something, a
Hi,
> On 11 Feb 2015, at 09:52, Lior Kaplan wrote:
>
> Hi,
>
> I've been doing some editing to the NEWS files, and keep getting this
> problem
>
> $ git diff NEWS
> fatal: ambiguous argument 'NEWS': both revision and filename
> Use '--' to separate filenames from revisions
>
> Although I can
Hi,
On 11 February 2015 at 19:15, Dmitry Stogov wrote:
> Hi,
>
> I don't think it'll improve something, and may complicate merging from
> PHP5 (this is not a big issue, because merging is already not simple).
>
>
Yes it just makes code looks a little better and cleaner.
I didn't realized the me
On 11/02/15 14:14, François Laupretre wrote:
>> All of the current demands ... and I think they are demands! ... stamp
>> > on past history and load even more work on everybody to have to support
>> > all these new features. Even if dbc is wrapped in comment blocks to hide
>> > it it's potential pr
On 02/11/2015 10:52 AM, Lior Kaplan wrote:
> Hi,
>
> I've been doing some editing to the NEWS files, and keep getting this
> problem
>
> $ git diff NEWS
> fatal: ambiguous argument 'NEWS': both revision and filename
> Use '--' to separate filenames from revisions
>
> Although I can do as it sugg
Hi Lester,
> All of the current demands ... and I think they are demands! ... stamp
> on past history and load even more work on everybody to have to support
> all these new features. Even if dbc is wrapped in comment blocks to hide
> it it's potential presence in third party parts of a project me
> De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo
> Ohgaki
>
> Both D and Eiffel evaluates all contracts defined in parents/interfaces.
That's not what I understand about pre-condition inheritance in D (check
http://ddili.org/ders/d.en/invariant.html#ix_invariant.contract%20
> De : Dmitry Stogov [mailto:dmi...@zend.com]
>
> I think we should just repeat the related D semantic.
> It must be defined in contracts inheritance rules.
>
> What if we have contracts for prototype method in parent class and
> interface?
> Should we still validate contracts of parent and inter
2015-02-11 13:25 GMT+02:00 Dmitry Stogov :
>
> yes. some special attributes. requires/ensures/invariant
>
>
>> Oh, and <<>> syntax is *ugly* ;)
>>
>
> It's from HHVM. I don't like it as well, please, propose the better one.
>
I like syntax, like a switch:
function add(int $a, int $b) : int
ca
On 10/02/15 14:31, Lester Caine wrote:
> in interbase/ibase_blobs.c
>
>> zval *blob_arg, *string_arg;
>> ibase_blob *ib_blob;
>>
>> RESET_ERRMSG;
>>
>> if (ZEND_NUM_ARGS() != 2 || zend_get_parameters_ex(2, &blob_arg,
>> &string_arg) == FAILURE) {
>> WRONG_PARAM_CO
I don't think there is time to get something finalised for 7.0, I
certainly wouldn't want anything cryptography related to be rushed, so
this is a pre-RFC discussion to gather ideas and opinions for
something we can work towards in PHP 7.1 and that can live as a PECL
extension between now and then.
Hi Anatol,
On Tue, Feb 10, 2015 at 3:35 PM, Anatol Belski
wrote:
>
> Maybe it'd be worth it to move one step after another, see what features
> can be implemented and how do they improve? Maybe they'll be so crucial to
> even make a special case that one can say - yeah, don't care about
> flexibi
Jordi Boggiano wrote on 11/02/2015 10:40:
On 09/02/2015 22:29, Anatol Belski wrote:
ext/imap
ext/mcrypt
ext/pdo_dblib
Sorry if this was suggested already but if those are not maintained
much and should not be used further ideally, shouldn't we add
E_DEPRECATED to them at least?
I understan
On Wed, Feb 11, 2015 at 10:58 AM, Stanislav Malyshev
wrote:
> Hi!
>
> > 1) contracts in doc-commetns https://wiki.php.net/rfc/dbc
> >
> > /**
> > * @requires ($a >= 0)
> > */
> > function foo($a) {
> > }
>
> We've spent several years rejecting annotations because no information
> can be in comm
Hi,
On Wed, Feb 11, 2015 at 12:40 PM, Jordi Boggiano wrote:
> On 09/02/2015 22:29, Anatol Belski wrote:
>>
>> ext/imap
>> ext/mcrypt
>> ext/pdo_dblib
>
>
> Sorry if this was suggested already but if those are not maintained much and
> should not be used further ideally, shouldn't we add E_DEPRECA
Hi,
I don't think it'll improve something, and may complicate merging from PHP5
(this is not a big issue, because merging is already not simple).
In any case, the names should be swapped, to be used as:
php_error_docref(E_WARNING, "recursion detected");
or
php_error_docref_ex(NULL, E_W
On 09/02/2015 22:29, Anatol Belski wrote:
ext/imap
ext/mcrypt
ext/pdo_dblib
Sorry if this was suggested already but if those are not maintained much
and should not be used further ideally, shouldn't we add E_DEPRECATED to
them at least?
I understand that they are kept to avoid making the up
On 11/02/15 09:34, Derick Rethans wrote:
>> Some of you are tired with this topic, but please take a look the RFC
>> >
>> > [RFC] Script only includes - this is 3rd version.
>> > https://wiki.php.net/rfc/script_only_include
>> >
>> > Please let me know what you like or dislike.
> Con:
> - It intr
On 11/02/15 07:58, Stanislav Malyshev wrote:
> We've spent several years rejecting annotations because no information
> can be in comments, not even a little bit, not even a tiny.
I find that a strange comment, since I've been using annotation in PHP
from day one. The phpdoc material helped me get
Hi,
I've been doing some editing to the NEWS files, and keep getting this
problem
$ git diff NEWS
fatal: ambiguous argument 'NEWS': both revision and filename
Use '--' to separate filenames from revisions
Although I can do as it suggests, I would prefer to remove the NEWS tag we
have since 2008
"Stanislav Malyshev" wrote in message news:54dafd32.3000...@gmail.com...
Hi!
Please steer clear of using the assert API, and in so doing avoid BC
concerns with the current assert API.
The operator can be called something other than "assert", I'm sure the
thesaurus has a lot of possibilities
On Wed, 11 Feb 2015, Yasuo Ohgaki wrote:
> Hi Markus,
>
> On Tue, Feb 10, 2015 at 5:59 PM, Markus Fischer wrote:
>
> > What constitutes "first token" in this context?
> >
> > Would this be detected as a PHP file?
> >
> > -8<
> > root:x:0:0:root:/root:/bin/bash
> > daemon:x:1:1:daemon:/u
On Tue, 10 Feb 2015, Yasuo Ohgaki wrote:
> Hi all,
>
> Some of you are tired with this topic, but please take a look the RFC
>
> [RFC] Script only includes - this is 3rd version.
> https://wiki.php.net/rfc/script_only_include
>
> Please let me know what you like or dislike.
Con:
- It introduce
Hey:
On Wed, Feb 11, 2015 at 4:35 PM, Yasuo Ohgaki wrote:
> Hi all,
>
> On Wed, Feb 11, 2015 at 5:21 PM, reeze wrote:
>>
>> I think it is a cleanup, it works but there are too many duplication. it
>> is the time to make the code clean and easier to understand.
>
>
> I've never used other than NU
Hi all,
On Wed, Feb 11, 2015 at 5:21 PM, reeze wrote:
> I think it is a cleanup, it works but there are too many duplication. it
> is the time to make the code clean and easier to understand.
I've never used other than NULL also.
Everyone is going to remove TSRM macros, it's right time to clea
> http://dlang.org/deprecate.html#invariant as an alias for immutable
It's not an alias, the most recent compiler emits an error if you try to
use invariant contracts, and immutable isn't a kind of contract.
immutable is a property modifier:
immutable: http://dpaste.dzfl.pl/7e724b599640
invarian
Hi Joe,
On Wed, Feb 11, 2015 at 5:12 PM, Joe Watkins wrote:
> > Just a thought - what about something like __pre/__post? We own __*, so
> no BC problems.
>
> I'm not married to the words being used, at all.
>
> I think this is a good idea, we would need __pre, __post , and
> __invariant, or some
I think it is a cleanup, it works but there are too many duplication. it is
the time to make the code clean and easier to understand.
I myself don't know why should I need the first NULL when I am a newcomer
of writing extensions, it just seems everyone do that,
before PHP7 there is a strange TSRM
On 11 Feb 2015 09:38, "Rasmus Lerdorf" wrote:
>
> On 02/10/2015 07:57 PM, Xinchen Hui wrote:
> >> am I wrong?!
> > seems I am wrong with this, it's a false alarm... it can restore
automatically.
>
> Yeah, declare() doesn't span files so that isn't a problem.
>
> My worry is still the lack of type
Hi Joe,
On Wed, Feb 11, 2015 at 5:02 PM, Yasuo Ohgaki wrote:
> On Wed, Feb 11, 2015 at 4:54 PM, Joe Watkins
> wrote:
>
>> So it turns out that invariant is already deprecated in D, they have
>> dropped it in favour of immutable properties.
>>
>> I guess I'll have to install an old version, or t
PS:
Github search result:
https://github.com/search?l=c&q=php_error_docref&ref=searchresults&type=Code&utf8=%E2%9C%93
It seems that no one need the docref at all.
On 11 February 2015 at 16:07, reeze wrote:
> Hi all,
> There are a lot of code use php_error_docref() macro, the first
> pa
On Wed, Feb 11, 2015 at 4:07 PM, reeze wrote:
> Hi all,
> There are a lot of code use php_error_docref() macro, the first
> parameter
> mostly is NULL, before PHP7, it looks like:
>
> php_error_docref(NULL TSRML, E_WARNING, "recursion detected");
> in PHP7
> php_error_docref(NULL, E_WARNING
> OTOH, don't our new parsing improvements allow us to handle syntax like
this without introducing a keyword that would be forbidden as
class/function name
Not that I am aware of, the AST stuff didn't touch the parser like that, it
has the same limitations it had before AFAIK.
Cheers
Joe
On Wed,
> Just a thought - what about something like __pre/__post? We own __*, so
no BC problems.
I'm not married to the words being used, at all.
I think this is a good idea, we would need __pre, __post , and __invariant,
or some combination of three.
Any objection to using __ prefixed names, and any o
Hi!
>> function foo($a)
>> require($a >= 0)
>> {
>> }
>
> This is a step better but still we have the similar issues with
> readability, to which reuse of 'require' is added.
Just a thought - what about something like __pre/__post? We own __*, so
no BC problems.
OTOH, don't our new parsing i
Hi all,
There are a lot of code use php_error_docref() macro, the first
parameter
mostly is NULL, before PHP7, it looks like:
*php_error_docref(NULL TSRML, E_WARNING, "recursion detected");*
in PHP7
*php_error_docref(NULL, E_WARNING, "recursion detected");*
looks better, but the first param
Hi Joe,
On Wed, Feb 11, 2015 at 4:54 PM, Joe Watkins wrote:
> So it turns out that invariant is already deprecated in D, they have
> dropped it in favour of immutable properties.
>
> I guess I'll have to install an old version, or try to extract everything
> we need from their obviously outdated
72 matches
Mail list logo
