Re: [PHP-DEV] [RFC] UString

[Ivan Enderlin@Hoa]

I fear it will be a reserved keyword.

On 02/07/15 15:46, Andreas Heigl wrote:

Hi.

Am 02.07.15 um 15:43 schrieb Ivan Enderlin@Hoa:

Hello :-),

Just a small detail. Please, choose another name. The `Hoa\String`
https://packagist.org/packages/hoa/string library has been renamed to
`Hoa\Ustring` because of PHP7. So, please, don't force us to rename the
library again ;-).

What's the issue with the name?

As far as I see it, There's no problem at all, as there's UString and
then there's Hoa\UString. Different namespace, no issue.

Or am I missing something?

Cheers

Andreas


Moreover, this library provides an API that is useful for daily use and
can be inspiring. Please, see
http://hoa-project.net/Literature/Hack/Ustring.html.

Regards.

On 01/07/15 01:30, Sara Golemon wrote:

On Mon, Mar 2, 2015 at 12:48 AM, Nikita Popov nikita@gmail.com
wrote:

On Tue, Oct 21, 2014 at 9:06 AM, Joe Watkins pthre...@pthreads.org
wrote:

  https://wiki.php.net/rfc/ustring

  This is the result of work done by a few of us, we won't be
opening any
vote in a fortnight. We have a long time before 7, there is no rush
whatever.

  Now seems like a good time to start the conversation so we can
hash out
the details, or get on with other things ;)


Curious what the current state of the UString RFC is.  I've got a
functionality request for HHVM to wrap icu::UnicodeString and was
hoping to match PHP behavior if any plans had been made, and lo...
here's a plan!


I'm not totally convinced by this proposal. We already have quite a
number
of extensions that deal with unicode text in one way or another (at
least
intl, mbstring and iconv). This adds yet another way of dealing with
this
issue - a way that will have to be combined with at least two other
extensions (mbstring or iconv for input handling and conversion) and
intl
for any non-trivial operations. There's nothing wrong with adding
another
approach for unicode handling per se, but I'd like to have more
empahsis on
how this integrates with existing functionality and why it is
implemented
separately from it (especially intl), etc.


I think (hope) that Joe's intention was to make it as an extension for
proof of concept, but make it part of the intl extension when it comes
to full adoption by the runtime.  If not, let's talk about making that
the intent, because intl is where this belongs.

For my bikeshedding part, I'd recommend against the u() function
helper as it pollutes the global function namespace and takes a very
fundamental name.  intl\u() might be worth considering, but we'll need
to have a discussion about namespacing for the intl extension as a
whole (separate topic).

I'd also recommend IntlString rather than UString as nearly all
the Intl classes follow this convention.  The one notable exception
being UConverter (which yes, I added, and I regret the departure in
naming).

Otherwise, while there's room to quibble about specific API names and
arguments, the general concept seems a no-brainer.

-Sara








--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] UString

[Ivan Enderlin@Hoa]

Hello :-),

Just a small detail. Please, choose another name. The `Hoa\String` 
https://packagist.org/packages/hoa/string library has been renamed to 
`Hoa\Ustring` because of PHP7. So, please, don't force us to rename the 
library again ;-).


Moreover, this library provides an API that is useful for daily use and 
can be inspiring. Please, see 
http://hoa-project.net/Literature/Hack/Ustring.html.


Regards.

On 01/07/15 01:30, Sara Golemon wrote:

On Mon, Mar 2, 2015 at 12:48 AM, Nikita Popov nikita@gmail.com wrote:

On Tue, Oct 21, 2014 at 9:06 AM, Joe Watkins pthre...@pthreads.org wrote:

 https://wiki.php.net/rfc/ustring

 This is the result of work done by a few of us, we won't be
opening any
vote in a fortnight. We have a long time before 7, there is no rush
whatever.

 Now seems like a good time to start the conversation so we can
hash out
the details, or get on with other things ;)


Curious what the current state of the UString RFC is.  I've got a
functionality request for HHVM to wrap icu::UnicodeString and was
hoping to match PHP behavior if any plans had been made, and lo...
here's a plan!


I'm not totally convinced by this proposal. We already have quite a number
of extensions that deal with unicode text in one way or another (at least
intl, mbstring and iconv). This adds yet another way of dealing with this
issue - a way that will have to be combined with at least two other
extensions (mbstring or iconv for input handling and conversion) and intl
for any non-trivial operations. There's nothing wrong with adding another
approach for unicode handling per se, but I'd like to have more empahsis on
how this integrates with existing functionality and why it is implemented
separately from it (especially intl), etc.


I think (hope) that Joe's intention was to make it as an extension for
proof of concept, but make it part of the intl extension when it comes
to full adoption by the runtime.  If not, let's talk about making that
the intent, because intl is where this belongs.

For my bikeshedding part, I'd recommend against the u() function
helper as it pollutes the global function namespace and takes a very
fundamental name.  intl\u() might be worth considering, but we'll need
to have a discussion about namespacing for the intl extension as a
whole (separate topic).

I'd also recommend IntlString rather than UString as nearly all
the Intl classes follow this convention.  The one notable exception
being UConverter (which yes, I added, and I regret the departure in
naming).

Otherwise, while there's room to quibble about specific API names and
arguments, the general concept seems a no-brainer.

-Sara




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Throwable Interface

[Ivan Enderlin @ Hoa]

Hello :-),

At Hoa, we are totally in favor or this RFC. We tried to make our 
exception hierarchy compatible with PHP7 with success but it was very 
difficult to make it backward compatible. With this proposal, all our 
problems are going to be solved, so +1 for us!


On 23/05/15 22:12, Aaron Piotrowski wrote:

Hello,

I’ve created an RFC for modifying the exception hierarchy for PHP 7, adding 
Throwable interface and renaming the exceptions thrown from fatal errors. The 
RFC is now ready for discussion.

RFC: https://wiki.php.net/rfc/throwable-interface 
https://wiki.php.net/rfc/throwable-interface
Pull Request: https://github.com/php/php-src/pull/1284 
https://github.com/php/php-src/pull/1284

Aaron Piotrowski



--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. computer scientist
Hacker
http://mnt.io/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

[Ivan Enderlin @ Hoa]

Hi Marcio,

Thanks for the RFC!
We discussed a little bit with the Hoa [1]'s and fruux [2]'s community 
and we have a question. Why not pretending we have an array of symbols, 
something like:


use Foo\Bar\[Baz, Qux];

instead of

use Foo\Bar\{Baz, Qux};

This is a list vs. block debate. While I personally would go for `{` and 
`}`, here we declare a list, so we guess the array syntax would be more 
tailored.


Thoughts?


[1] http://hoa-project.net/
[2] https://fruux.com/ and http://sabre.io/

On 11/02/15 21: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/pull/1005

As requested I've split the vote into two slightly different syntax
choices, so be sure to pick the right choice if you are going to vote yes.
The voting will close in exactly 14 days counting from now.

PS: Aknowledgements to Daniel Ackroyd for reviewing this RFC.

Márcio Almada
https://github.com/marcioAlmada



--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. computer scientist
Hacker
http://mnt.io/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV][RFC][VOTE] Group Use Declarations

[Ivan Enderlin @ Hoa]

On 12/02/15 14:21, Marcio Almada wrote:

Thanks for the RFC!
We discussed a little bit with the Hoa [1]'s and fruux [2]'s community

and we have a question.

Why not pretending we have an array of symbols, something like:
use Foo\Bar\[Baz, Qux];
instead of
use Foo\Bar\{Baz, Qux};
This is a list vs. block debate. While I personally would go for `{` and

`}`, here we declare a list, so we guess the array syntax

would be more tailored.
Thoughts?

Hi,

Hi :-),



This is an interesting one. During research, the `[` and `]` syntax was
considered for a while but it quickly felt apart for the following reasons:

1. Most people considered on PHP the array construct is a very important
building block and therefore we should avoid to multiplex or reuse its
syntax in multiple contexts. This becomes more clear in cases involving
conflict resolutions:

use Foo\Bar\[Baz *as* Buz, Qux\Quaz *as* Quiz];

+1.



2. Block syntax seemed more versatile and prone to reuse because we already
have the traits conflict resolution syntax:

http://php.net/manual/en/language.oop5.traits.php#language.oop5.traits.conflict

The reasoning for using commas to delimit imported entities and not `;` is
that current use declaration syntax is a comma separated list:

use function foo\math\sin, foo\math\cos, foo\math\cosh;

Hence the `{..., ...}` syntax seemed the most tailored to feel similar and
obvious for most of the current PHP userbase, based on all experiments:

use function foo\math\{ sin, cos, cosh };
use function Foo\Bar\{ A, B as Baz, C };

I hope that the given information is useful to your decision process. Good
voting!

Yup sure. We are going to vote yes (behind my nickname).
However, while I agree with all your arguments, we have more syntax and 
more semantics, it's kind of confusing :-/. But it's a small one, so +1 
for us.


--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. computer scientist
Hacker
http://mnt.io/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Ivan Enderlin @ Hoa]

On 06/02/15 09:44, Yasuo Ohgaki wrote:

Hi Ivan,

Hi Yasuo :-),


On Fri, Feb 6, 2015 at 4:44 PM, Ivan Enderlin @ Hoa 
ivan.ender...@hoa-project.net mailto:ivan.ender...@hoa-project.net 
wrote:






On Thu, Feb 5, 2015 at 11:25 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net
mailto:ivan.ender...@hoa-project.net wrote:

I just would like to point out some stuff.


tl;dr: Contracts can be used to validate code
(Design-by-Contract) or generate test data to validate code
(Contract-based Testing). There are plenty of contract
languages in the wild, each one addresses a specific problem
(object, structured type, temporal logic, scenario etc.). If
we try to develop a contract language, **IT WILL FAIL**, I
guarantee it. The solution is to give tools to developers to
ease the use of contracts, for example with Aspect Oriented
Programming.


There is a whole research PhD thesis about Contract-based
Testing in PHP, which includes Design-by-Contract, automatic
generation of complex test data and automatic generation of
test suites:
https://dl.dropboxusercontent.com/u/26317193/PhdThesis.pdf.
Unfortunately, the thesis is in French but research articles
are in English. You can found them here
(http://hoa-project.net/En/Literature.html#Research):
  * Praspel: A Specification Language for Contract-Driven
Testing in PHP (article:
http://hoa-project.net/En/Literature/Research/Ictss11.pdf,
keynote: http://keynote.hoa-project.net/Ictss11/EDGB11.pdf),
  * Grammar-Based Testing using Realistic Domains in PHP
(article:
http://hoa-project.net/En/Literature/Research/Amost12.pdf,
keynote: http://keynote.hoa-project.net/Amost12/EDGB12.pdf),
  * A Constraint Solver for PHP Arrays (article:
http://hoa-project.net/En/Literature/Research/Cstva13.pdf,
keynote: http://keynote.hoa-project.net/Cstva13/EGB13.pdf).

Concepts behind contracts are twofold:
  1. Design-by-Contract (DbC), validate code at compile time
or at runtime (in the case of PHP, it will be at runtime),
  2. Contract-based Testing (CbT), generate test data based
on contracts. Preconditions are used to generate inputs, and
postconditions validate outputs. Invariants must hold before
and after the execution of the SUT (System Under Test, here
methods and functions).

So there are two goals with contracts. We can only address
validation (DbC) or both (DbC and CbT).

From my own experience and study in this field (I am a PhD in
the test domain), I suggest you to NOT introduce DbC and CbT
in PHP. Why? Because the language used to express contracts
(even if we use PHP) will be too much poor or too much
inappropriate for test data validation or test data
generation (resp. DbC or CbT).

The articles listed above, in addition to the PhD thesis,
present Praspel, a specification language for PHP, based on
contracts. Praspel is used to validate and generate (test)
data and test suites. This language is inspired from JML
(Java Modeling Language) and ACSL (ANSI/C Specification
Language) while addressing PHP features (weakly type for
instance). But there is a lot more languages in the wild.
Inventing another language will lead to a fail at a
particular time, believe me. Each contract language has a
specificity: Handling structured data, handling events,
handling scenario (see Dwyer patterns for temporal linear
logic) etc. We CANNOT address all these needs.

However, there is a hope :-). DbC and CbT can be easily
implemented with an Aspect Oriented Programming (AOP)
paradigm. Before each “method execution”, we interpret or
execute the invariants and the preconditions expressed in the
contract, the method runs and after “method execution”, we
interpret or execute the invariants and the postconditions
expressed in the contract. No need to have a specific
implementation in PHP's core for contracts.
Moreover, we can enable or disable AOP in development or
production environment, which ensures performances.


It sounds you are looking for way beyond what we discuss.
If there are contracts, program correctness may be proven by
contracts, but
this kind of validation is not in scope.

Proven? I don't dare to speak about proof here. If you would like
to execute pre-, postconditions and invariants at runtime, you
need a super language to define behaviors efficiently… and the
problem is: What behaviors? Only the data type? The order of
execution of methods? The time of execution of methods? A lot of
constraints

Re: [PHP-DEV] [VOTE] Scalar Type Hints

[Ivan Enderlin @ Hoa]

Hello internal,

Thank you Andrea for this RFC.
I voted today. However, I would like to stress that my vote represents 
the opinion of Hoa's community [1] and fruux [2] (the company behind 
sabre/dav [3]).


I talked to Pierre Joye today and I was mentioning this is something we 
do since few months already and I had to spread the word here. So yes, 
my vote does not represent only 1 person but tens.


This is something we will continue since we believe that a vote must not 
represent the opinion of one person. We consider this is an opportunity 
to fill the gap between internal and PHP's community. And finally, we 
would like to encourage people with a vote to talk to anybody around 
them, at their work, at their open-source project, on IRC etc. to 
reflect the most valuable opinion.


Cheers :-).


[1] http://hoa-project.net/
[2] https://fruux.com/
[3] http://sabre.io/


On 05/02/15 21:14, 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. Please 
read the RFC in full: the details are important. And if  anyone has any 
questions or uncertainties, please ask them before voting. I am very happy to 
answer them.

I would urge everyone who wants type hints to vote for this RFC. It is not a 
perfect solution, but there can be no perfect solution to this issue. However, 
I think it is better than most of the alternatives suggested thus far - see the 
rationale section, and previous discussions. Crucially, this RFC would keep PHP 
a weakly-typed language, and not force either strict typing, nor weak typing, 
on anyone who does not want it. It would allow the addition of type hints to 
existing codebases. It would not create a situation where userland functions 
are strict yet internal functions are not, because the strict mode affects 
both. I’ve tested the implementation myself on my own code, and it worked well, 
providing benefits other proposals would not have given (see my previous post 
about my experiences).

Voting starts today (2015-02-05) and ends in two weeks’ time (2015-02-19). In 
addition to the vote on the main RFC, there is also a vote on the type aliases 
issue, and a vote to reserve the type names for future RFCs’ sake if this RFC 
fails.

The RFC can be found here, and it contains a voting widget: 
https://wiki.php.net/rfc/scalar_type_hints

Thank you for your time.

--
Andrea Faulds
http://ajf.me/








--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Ivan Enderlin @ Hoa]

On 06/02/15 05:00, Pierre Joye wrote:

On Thu, Feb 5, 2015 at 11:36 PM, Dmitry Stogov dmi...@zend.com wrote:

phpdoc is annotation as well, but to split it into specific attributes we
have to write specialized parsers.
Other languages support annotation or attributes that may be used more
easily.

http://docs.hhvm.com/manual/en/hack.attributes.php

Exactly, phpdoc is used as annotation (or comments with some similar
syntax) but is definitively not aimed to be annotations.
Exact. Annotations !== comments. Because PHP has no annotation system, 
we used to use comments for this purpose, but it's a workaround.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Design by Contract

[Ivan Enderlin @ Hoa]

On 05/02/15 17:09, Yasuo Ohgaki wrote:

Hi Ivan,

Hi Yasuo :-),


On Thu, Feb 5, 2015 at 11:25 PM, Ivan Enderlin @ Hoa 
ivan.ender...@hoa-project.net mailto:ivan.ender...@hoa-project.net 
wrote:


I just would like to point out some stuff.


tl;dr: Contracts can be used to validate code (Design-by-Contract)
or generate test data to validate code (Contract-based Testing).
There are plenty of contract languages in the wild, each one
addresses a specific problem (object, structured type, temporal
logic, scenario etc.). If we try to develop a contract language,
**IT WILL FAIL**, I guarantee it. The solution is to give tools to
developers to ease the use of contracts, for example with Aspect
Oriented Programming.


There is a whole research PhD thesis about Contract-based Testing
in PHP, which includes Design-by-Contract, automatic generation of
complex test data and automatic generation of test suites:
https://dl.dropboxusercontent.com/u/26317193/PhdThesis.pdf.
Unfortunately, the thesis is in French but research articles are
in English. You can found them here
(http://hoa-project.net/En/Literature.html#Research):
  * Praspel: A Specification Language for Contract-Driven Testing
in PHP (article:
http://hoa-project.net/En/Literature/Research/Ictss11.pdf,
keynote: http://keynote.hoa-project.net/Ictss11/EDGB11.pdf),
  * Grammar-Based Testing using Realistic Domains in PHP (article:
http://hoa-project.net/En/Literature/Research/Amost12.pdf,
keynote: http://keynote.hoa-project.net/Amost12/EDGB12.pdf),
  * A Constraint Solver for PHP Arrays (article:
http://hoa-project.net/En/Literature/Research/Cstva13.pdf,
keynote: http://keynote.hoa-project.net/Cstva13/EGB13.pdf).

Concepts behind contracts are twofold:
  1. Design-by-Contract (DbC), validate code at compile time or at
runtime (in the case of PHP, it will be at runtime),
  2. Contract-based Testing (CbT), generate test data based on
contracts. Preconditions are used to generate inputs, and
postconditions validate outputs. Invariants must hold before and
after the execution of the SUT (System Under Test, here methods
and functions).

So there are two goals with contracts. We can only address
validation (DbC) or both (DbC and CbT).

From my own experience and study in this field (I am a PhD in the
test domain), I suggest you to NOT introduce DbC and CbT in PHP.
Why? Because the language used to express contracts (even if we
use PHP) will be too much poor or too much inappropriate for test
data validation or test data generation (resp. DbC or CbT).

The articles listed above, in addition to the PhD thesis, present
Praspel, a specification language for PHP, based on contracts.
Praspel is used to validate and generate (test) data and test
suites. This language is inspired from JML (Java Modeling
Language) and ACSL (ANSI/C Specification Language) while
addressing PHP features (weakly type for instance). But there is a
lot more languages in the wild.
Inventing another language will lead to a fail at a particular
time, believe me. Each contract language has a specificity:
Handling structured data, handling events, handling scenario (see
Dwyer patterns for temporal linear logic) etc. We CANNOT address
all these needs.

However, there is a hope :-). DbC and CbT can be easily
implemented with an Aspect Oriented Programming (AOP) paradigm.
Before each “method execution”, we interpret or execute the
invariants and the preconditions expressed in the contract, the
method runs and after “method execution”, we interpret or execute
the invariants and the postconditions expressed in the contract.
No need to have a specific implementation in PHP's core for contracts.
Moreover, we can enable or disable AOP in development or
production environment, which ensures performances.


It sounds you are looking for way beyond what we discuss.
If there are contracts, program correctness may be proven by 
contracts, but

this kind of validation is not in scope.
Proven? I don't dare to speak about proof here. If you would like to 
execute pre-, postconditions and invariants at runtime, you need a super 
language to define behaviors efficiently… and the problem is: What 
behaviors? Only the data type? The order of execution of methods? The 
time of execution of methods? A lot of constraints might be expressed in 
contracts.


There are a lot of researches in this field. PHP has a great opportunity 
to not close the doors by forcing a language. I suggest you to offer an 
API to hook on the runtime and “control” it, like AOP does. It will open 
the doors to so many interesting contributions!



If you think D like DbC support in language is wrong, could you list 
the reason why it is?

I don't understand the question :-).

Cheers!

Re: [PHP-DEV] Design by Contract

[Ivan Enderlin @ Hoa]

Hi Internal :-),

I just would like to point out some stuff.


tl;dr: Contracts can be used to validate code (Design-by-Contract) or 
generate test data to validate code (Contract-based Testing). There are 
plenty of contract languages in the wild, each one addresses a specific 
problem (object, structured type, temporal logic, scenario etc.). If we 
try to develop a contract language, **IT WILL FAIL**, I guarantee it. 
The solution is to give tools to developers to ease the use of 
contracts, for example with Aspect Oriented Programming.



There is a whole research PhD thesis about Contract-based Testing in 
PHP, which includes Design-by-Contract, automatic generation of complex 
test data and automatic generation of test suites: 
https://dl.dropboxusercontent.com/u/26317193/PhdThesis.pdf. 
Unfortunately, the thesis is in French but research articles are in 
English. You can found them here 
(http://hoa-project.net/En/Literature.html#Research):
  * Praspel: A Specification Language for Contract-Driven Testing in 
PHP (article: http://hoa-project.net/En/Literature/Research/Ictss11.pdf, 
keynote: http://keynote.hoa-project.net/Ictss11/EDGB11.pdf),
  * Grammar-Based Testing using Realistic Domains in PHP (article: 
http://hoa-project.net/En/Literature/Research/Amost12.pdf, keynote: 
http://keynote.hoa-project.net/Amost12/EDGB12.pdf),
  * A Constraint Solver for PHP Arrays (article: 
http://hoa-project.net/En/Literature/Research/Cstva13.pdf, keynote: 
http://keynote.hoa-project.net/Cstva13/EGB13.pdf).


Concepts behind contracts are twofold:
  1. Design-by-Contract (DbC), validate code at compile time or at 
runtime (in the case of PHP, it will be at runtime),
  2. Contract-based Testing (CbT), generate test data based on 
contracts. Preconditions are used to generate inputs, and postconditions 
validate outputs. Invariants must hold before and after the execution of 
the SUT (System Under Test, here methods and functions).


So there are two goals with contracts. We can only address validation 
(DbC) or both (DbC and CbT).


From my own experience and study in this field (I am a PhD in the test 
domain), I suggest you to NOT introduce DbC and CbT in PHP. Why? Because 
the language used to express contracts (even if we use PHP) will be too 
much poor or too much inappropriate for test data validation or test 
data generation (resp. DbC or CbT).


The articles listed above, in addition to the PhD thesis, present 
Praspel, a specification language for PHP, based on contracts. Praspel 
is used to validate and generate (test) data and test suites. This 
language is inspired from JML (Java Modeling Language) and ACSL (ANSI/C 
Specification Language) while addressing PHP features (weakly type for 
instance). But there is a lot more languages in the wild.
Inventing another language will lead to a fail at a particular time, 
believe me. Each contract language has a specificity: Handling 
structured data, handling events, handling scenario (see Dwyer patterns 
for temporal linear logic) etc. We CANNOT address all these needs.


However, there is a hope :-). DbC and CbT can be easily implemented with 
an Aspect Oriented Programming (AOP) paradigm. Before each “method 
execution”, we interpret or execute the invariants and the preconditions 
expressed in the contract, the method runs and after “method execution”, 
we interpret or execute the invariants and the postconditions expressed 
in the contract. No need to have a specific implementation in PHP's core 
for contracts.
Moreover, we can enable or disable AOP in development or production 
environment, which ensures performances.


Thoughts?


On 05/02/15 12:14, Dmitry Stogov wrote:

Hi Yasuo,

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()
 requre(input-assert-expression)
 ensure(output-assert-expression)
{
   ...
}

It would require only one new reserved word ensure.

The assert expressions may be checked or not depending on ini directive.
It should be also possible to prevent code generation for assertions (zero
cost asserts). It was already implemented for
https://wiki.php.net/rfc/expectations

For inherited methods, only the self input-assert-expression should be
checked, and all parent output-asser-expression. This is borrowed from D
but not necessary to be repeated exactly.

I think we shouldn't introduce invariant constraints for classes now. May
be later.

Implementation is going to generate code for input constraint after all
RECV opcodes and before code for function body, and code for output
constraint before RETURN opcode (may be reusing implementation of
finally).

See:
http://dlang.org/contracts.html
http://jan.newmarch.name/java/contracts/paper-long.html

Thanks. Dmitry.

Re: [PHP-DEV] [RFC] Unicode Escape Syntax

[Ivan Enderlin @ Hoa]

Le 24/11/2014 23:09, Andrea Faulds a écrit :

Good evening,

Here’s a new RFC: https://wiki.php.net/rfc/unicode_escape

It has a rationale section explaining why certain decisions were made, that I’d 
recommend you read in full.

Excellent RFC, thank you for this proposal.
I would suggest this talk 
https://speakerdeck.com/mathiasbynens/hacking-with-unicode (you might 
already know) but interesting concepts and limitations of current 
Unicode implementations are mentioned.
The usage of `\u{…}` fixes most limitations and I could not be more 
agree with that notation!


Cheers.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Default constructors

[Ivan Enderlin @ Hoa]

Hello :-),

Is it not simpler to create a super-object whom all objects are children 
of? Something similar to the Java `Object`?


Cheers :-).


Le 18/11/2014 10:20, Stanislav Malyshev a écrit :

Hi!

I'd like to propose the following RFC, which in short would allow any
method to call parent ctor (and some other methods) even if such is not
explicitly defined:

https://wiki.php.net/rfc/default_ctor

The reasons are outlined in detail in the RFC and here:
http://php100.wordpress.com/2014/11/04/default-constructors/

The patch is not finished yet but seems to be working fine, I'll add it
to the RFC this week as soon as I finish it. I'd like to put idea out
there in the meantime and hear what everybody thinks about it.

Thanks,
Stas



--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Return Types

[Ivan Enderlin @ Hoa]

Le 04/11/2014 03:01, Levi Morrison a écrit :

Dear Internals,

I am pleased to announce that the return type RFC is now open for
voting[1]. Note that the implementation needs a bit of cleaning up
before merging should the RFC be accepted; Dmitry has already
volunteered to help with that, but more eyes are welcome.

A couple of things have changed in reflection[2] since the last
iteration, but is otherwise the same.

The implementation is slightly out of date with the RFC, but soon it
will be updated to match.

   [1]: https://wiki.php.net/rfc/returntypehinting#vote
   [2]: https://wiki.php.net/rfc/returntypehinting#reflection
Excellent RFC, thank you. However, there is no mention about using 
`static`, `self` or `parent` as a type (it is possible for an argument). 
Something like:

```php
class Singleton {

public function getInstance ( $x, $y): static { … }
}
```
Maybe I miss it in the discussion?
Thoughts?

Regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Return Types

[Ivan Enderlin @ Hoa]

Le 04/11/2014 09:37, Christoph Becker a écrit :

Ivan Enderlin @ Hoa wrote:


Excellent RFC, thank you. However, there is no mention about using
`static`, `self` or `parent` as a type (it is possible for an argument).
Something like:
```php
class Singleton {

 public function getInstance ( $x, $y): static { … }
}
```
Maybe I miss it in the discussion?
Thoughts?

The possible usage of self and parent is already documented:
https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs.

Regarding static, see http://news.php.net/php.internals/78116.

Thanks :-).

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Regression in RecursiveRegexIterator

[Ivan Enderlin @ Hoa]

Hello :-),

Does anyone know something about this bug: 
https://bugs.php.net/bug.php?id=68128 ?


Thanks!

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Ivan Enderlin @ Hoa]

On 24/07/2014 15:40, Rowan Collins wrote:

Ivan Enderlin @ Hoa wrote (on 24/07/2014):
Taking the example of XML, CSS, HTML, ECMAScript or other languages 
(maybe the JVM, I don't know exactly), there is version numbers for 
the specification, that are different of the version numbers of the 
implementations. Even more, the version of the implementations is 
most of the time unknown (what is the version of SpiderMonkey or V8 
for ECMAScript x? We don't really know). 


I think this only really matters if it's likely that the Zend 
implementation diverges from the specification, such as by a feature 
being implemented in HHVM and agreed to be standard, but no release of 
Zend produced supporting that feature. And that in turn implies a 
separate stewardship and decision-making process for the 
implementation and the specification, which would be a major change in 
process.
Or if an implementation has a bug, which will be the most common usecase 
I think, no?


--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Using stada...@lists.php.net for spec work

[Ivan Enderlin @ Hoa]

On 25/07/2014 10:52, Sebastian Bergmann wrote:

On 07/24/2014 09:13 PM, Sara Golemon wrote:

Speaking of, I did just successfully subscribe myself to standards@
(without any trouble) using the direct ezmlm interface.  Maybe they
were using the web form on php.net? I dunno.  Maybe it's just PEBKAC


 I just tried to subscribe to standards@ using the web interface and got
 We were unable to subscribe you due to some technical problems.
 Please try again later.

It worked for me with standards-subscr...@lists.php.net.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Language Specification

[Ivan Enderlin @ Hoa]

On 23/07/2014 22:59, Ben Ramsey wrote:

This got me thinking about the whole version number debate. With a language 
specification, to what does the version number refer? The state of the language 
specification, or the state of a given implementation of the specification? 
Right now, the number refers to the state of the PHP Group implementation, and 
implementations like HippyVM and HHVM say that they are compatible with Zend 
PHP 5.x. Will we version the language specification separately, and individual 
releases of various implementations (including the PHP Group implementation) 
will state that they are compatible with version X of the specification?
This is exactly what I said in “a lot of questions remain open” in my 
previous mail [1]. Taking the example of XML, CSS, HTML, ECMAScript or 
other languages (maybe the JVM, I don't know exactly), there is version 
numbers for the specification, that are different of the version numbers 
of the implementations. Even more, the version of the implementations is 
most of the time unknown (what is the version of SpiderMonkey or V8 for 
ECMAScript x? We don't really know).


In the case of PHP, this is different because the word “PHP” was 
previously (yes, it's done) representing the language **and** the 
implementation. Consequently, we can't start with PHP1.


1. A solution would be to start with PHP6 (and 7, I don't know…) for the 
specification, and then, the version of the implementations will have no 
importance (HHVM1.3, ZendEngine3.0, whatever you want).
2. Another solution is to refer to the PHP version with a “new name”, 
something like “PHPx” or “PHPv”, so we will have PHPx1”, “PHPx2” etc.
3. A final solution I see is to refer to PHP with “PHP1” which will be 
equivalent to “PHP6.1”, exactly as Java7 which is in reality Java1.7, 
but when they will introduce Java2.x, they will encounter a problem…


My favorite solution is the 2nd one.

Moreover, what about (let's say with PHPx) PHPx1.2.3? Does it make sense 
to have x.y.z for a language specification? We don't see it very often. 
Actually, x.y is enough I would say (XML1.1, Java1.7 etc.), I don't know 
any x.y.z language specification.


Another problem to solve: what about the `php_version` function, the 
`PHP_VERSION_ID` constant etc. If an implementation (a VM) respects the 
specification, testing the version of the specification does not make 
sense anymore, except in edge-cases, so we will really test the version 
of language. Do we keep these functions and constants? Do we introduce 
new ones? The specification might define the format of some  functions 
or constants to get the versions of the implementation, for example: 
`PHP_VM_VERSION_ID` along with `PHP_VM_NAME` (something similar to what 
PHP does with SAPI).


Thoughts?


[1] http://marc.info/?l=php-internalsm=140612071919140w=2

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Using stada...@lists.php.net for spec work

[Ivan Enderlin @ Hoa]

On 24/07/2014 20:25, Andrea Faulds wrote:

On 24 Jul 2014, at 19:24, Stas Malyshev smalys...@sugarcrm.com wrote:


Hi!

I would like to propose to use list stada...@lists.php.net (which has
been dormant since 2009) for PHP spec work. What do you think?

Did you typo both your subject and body, or is the list actually called 
stadards, not standards? :)

Damn copy/paste :-p.
+1 for me, good idea.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP Language Specification

[Ivan Enderlin @ Hoa]

Hello Sara,

First, thank you for the hard work. I have started to work on it few 
days ago as suggested in [1]. You have been faster than me ;-). Good job!



On 23/07/2014 00:22, Sara Golemon wrote:

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 of this point.

FB isn't looking to just throw this over wall saying HERE'S THE FINAL
DOCUMENT, HAVE A NICE DAY, GOOD BYE!.  What we're planning to release
next week is more like a pre-1.0 draft which will probably need a lot
of work before anyone is willing to call it final, and of course the
document will need to be updated over time to reflect changes in the
language's syntax (e.g. return typehint rfc).
This is a good news. The approach of Facebook is sane as I can see and 
this is comforting.


You said your target was PHP5.6. With Pierre Joye, when we talked about 
the PHP Specification, we have mentionned to target PHP6 since (i) it 
will solve several PHP inconsistencies and (ii) PHP6 requires 2 years to 
be released, just like the PHP Specification (approximately).




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, all the better.  If that means FB sets
it up then hands it over, that's an option too.  This is the
discussion I'd like to start now, so that we can work out a strategy
for what that looks like.
My idea was to constitute a **PHP Consortium** (yes, the name is classy 
but it reflects the reality), responsible to maintain and edit the PHP 
Specification. With what members? Members from the PHP Group 
(maintainers of php-src), from Facebook (maintainers of HHVM), from 
HippyVM, from JPHP etc. and from others important projects (e.g. 
Symfony, Zend etc.), just like the PHP Group does with the RFC votes. 
What will be the size of the PHP Consortium? I don't know. Having more 
than 100 persons, even qualified, would not be a good idea. A process 
must be sketch to propose, discuss and accept RFC, features etc. The 
group responsible to validate RFC will be the PHP Consortium. This is 
not a technical position, but a “language-semantics” position, in order 
to avoid conflicts between different vendors (VM mainteners).


I am wondering whether it is possible to adopt an approach similar to 
the W3C: several people working “punctually” on a feature. On one side 
we have authors, and on the other side, we have “commenters”. The 
workflow is pretty efficient also:

  * writing a proposal,
  * discussing,
  * trying different implementations,
  * collecting feedbacks from the users, and finally,
  * validating it.
We should not met the issues encountered by the W3C and HTML vendors 
because the rate of releases is not the same (fortunately!). Another 
source of inspiration can be the process of the ECMAScript language.





If folks have comments on the one chapter I uploaded, I'd say start
with emails to the list or me directly and I'll pass them on.
Please, send me the first chapter :-). I have written specifications for 
two languages, my skills can be interesting (this is why I have started 
[1]).




That
should be considered a short-term solution though.  Ideally we'll have
something in a collaborative format next week that folks with existing
karma can contribute to more directly.
Several people have proposed Github, markdown etc. From my point of view 
and experience, this will be insane to manage. If everyone can make a 
proposal, this will lead to a lot of noise. PHP allows *some* users to 
write RFC. If someone would like to see a new feature, it has to 
approach someone with a higher karma/rights or to join the ML 
(mailing-list) of the PHP Consortium. Also, about the format, we should 
use an advanced one (so it excludes markdown, sorry guys :-)).



Finally, a lot of questions remain open, like:
  * What version numbers for the specification? Will they follow the 
versions of php-src (the “historical implementation”, haha/trolling)
  * Will the PHP Consortium be splitted into several groups according 
to the specification's chapters (for example: the stream part, the 
runtime part, the security part etc.)
  * Will a test suite to check the conformance of an implementation to 
the PHP Specification be provided?
  * What are the goals of the PHP Specification? I mean: What are the 
subjects? Will it include the extensions, or the definition of extensions?


Maybe I have missed this information but why Facebook is keeping the 
sources of the PHP Specification private for now? I'm not judging, just 
asking :-).


Again, really great work. Thank you!
Best regards.



[1] 

Re: [PHP-DEV] Implemented fallocate() syscall in streams

[Ivan Enderlin @ Hoa]

On 10/07/2014 11:13, Julien Pauli wrote:

The difference between ftruncate and fallocate is meaningless in userland.

If `fallocate` is proposed in the user-land, then it will be logical to have
it in the stream wrapper API. That's it :-).

I admit that it would be nice for consistency, however I wonder how
users will interpret the difference between ftruncate and fallocate.
Users will interpret exactly what the documentation says ;-). Since PHP 
is a scripting language, it is just a collection of cross-platform 
bindings (on the top of C APIs in the case of php-src). Some bindings 
are just more advanced ones than others. That's all. Someone will be 
likely to use `fallocate` some day, for sure.


Cheers.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] VCS Account Request: hywan

[Ivan Enderlin @ Hoa]

On 10/07/2014 11:27, Ferenc Kovacs wrote:

On Thu, Jul 10, 2014 at 9:26 AM, Ivan Enderlin 
ivan.ender...@hoa-project.net wrote:


Developing the PHP runtime
Maintaining the documentation
Translating the documentation
Wiki access
Wiki votes



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Hi,

Hi Ferenc :-),



I know that you are a reguler on internals (and that you already have wiki
access and voting rights), but usually we require a couple of patches
before handing out karma.

I already have rights on the wiki?

Some patches:
* https://github.com/php/php-src/commits?author=Hywan
* https://bugs.php.net/bug.php?id=55212 (patches applied by dsp)

Some bugs:
* 
https://bugs.php.net/search.php?search_for=boolean=0limit=30order_by=direction=DESCcmd=displaystatus=Allbug_type=Allproject=Allphp_os=phpver=cve_id=assign=author_email=ivan.enderlin%40hoa-project.netbug_age=0bug_updated=0


I don't know how to list my contributions on the documentation (around 20).

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] VCS Account Request: hywan

[Ivan Enderlin @ Hoa]

On 10/07/2014 12:57, Ferenc Kovacs wrote:




On Thu, Jul 10, 2014 at 12:01 PM, Ivan Enderlin @ Hoa 
ivan.ender...@hoa-project.net mailto:ivan.ender...@hoa-project.net 
wrote:



On 10/07/2014 11:27, Ferenc Kovacs wrote:

On Thu, Jul 10, 2014 at 9:26 AM, Ivan Enderlin 
ivan.ender...@hoa-project.net
mailto:ivan.ender...@hoa-project.net wrote:

Developing the PHP runtime
Maintaining the documentation
Translating the documentation
Wiki access
Wiki votes



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Hi,

Hi Ferenc :-),



I know that you are a reguler on internals (and that you
already have wiki
access and voting rights), but usually we require a couple of
patches
before handing out karma.

I already have rights on the wiki?


yeah, you have voting right already:
http://marc.info/?l=php-internalsm=133463696632604
you also used that to vote on previous rfcs:
https://wiki.php.net/todo/php54/vote
https://wiki.php.net/rfc/dvcs/vote


Some patches:
* https://github.com/php/php-src/commits?author=Hywan
* https://bugs.php.net/bug.php?id=55212 (patches applied by dsp)

Some bugs:
*

https://bugs.php.net/search.php?search_for=boolean=0limit=30order_by=direction=DESCcmd=displaystatus=Allbug_type=Allproject=Allphp_os=phpver=cve_id=assign=author_email=ivan.enderlin%40hoa-project.netbug_age=0bug_updated=0


thanks!



I don't know how to list my contributions on the documentation
(around 20).


I suppose those are for the english documentation, right?

English and french.
I have made them anonymously since I didn't have an official account :-p.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

Re: [PHP-DEV] Implemented fallocate() syscall in streams

[Ivan Enderlin @ Hoa]

On 13/06/2014 16:20, Julien Pauli wrote:

Hi,

Hello :-),



I just wrote a patch to add fallocate() syscall support for streams.
It relies on posix_fallocate(), so that it should support many Unixes.
Linux's got a specification with a fallocate() function, more powerful
than the posix call.

fallocate() does write blocks to the underlying filesystem (not so
many are supported, but the ones not supported should proxy to
ftruncate()) and prevents sparse file creation whereas ftruncate()
just updates inode information, leading to possible future out of
space errors.

I got a POC showing the diffs between both calls here :
https://gist.github.com/jpauli/8afec7c4fc2b38f8ff27

I propose two APIs for PHP :
- One that adds a function : fallocate()
https://github.com/jpauli/php-src/tree/fallocate

I prefer this one.



- One that relies on ftruncate() , and adds a bool$use_fallocate
flag https://github.com/jpauli/php-src/tree/fallocate_flag

Please, note that the latest proposal requires patches in different
extensions, as I changed a PHP_API function signature.

I don't know if Windows can support that. Pierre, Anatol ? :-)

Tests are beeing written at the moment.

I didn't implement this is user stream handlers, as this really is a
low level implementation design that is kind of useless for usage in
user streams.

Thoughts ?
If the first one is used, please, consider exposing it on the user-land 
of stream wrappers (exemple: `stream_allocate`) if possible.


Cheers.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Implemented fallocate() syscall in streams

[Ivan Enderlin @ Hoa]

On 08/07/2014 11:08, Julien Pauli wrote:

On Tue, Jul 8, 2014 at 9:37 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:

On 13/06/2014 16:20, Julien Pauli wrote:

- One that relies on ftruncate() , and adds a bool$use_fallocate
flag https://github.com/jpauli/php-src/tree/fallocate_flag

Please, note that the latest proposal requires patches in different
extensions, as I changed a PHP_API function signature.

I don't know if Windows can support that. Pierre, Anatol ? :-)

Tests are beeing written at the moment.

I didn't implement this is user stream handlers, as this really is a
low level implementation design that is kind of useless for usage in
user streams.

Thoughts ?

If the first one is used, please, consider exposing it on the user-land of
stream wrappers (exemple: `stream_allocate`) if possible.

I find it very useless as user stream already have the ftruncate
exposed to them.
Hum no, this is very useful actually. A stream wrapper can be used to 
represent a file somewhere else, imagine `ntfs://`, `smb://`, `aws://`, 
`ftp://`, `afp://` etc.




The difference between ftruncate and fallocate is meaningless in userland.
If `fallocate` is proposed in the user-land, then it will be logical to 
have it in the stream wrapper API. That's it :-).


--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Uniform Variable Syntax

[Ivan Enderlin @ Hoa]

On 07/07/2014 16:54, Laruence wrote:

On Mon, Jul 7, 2014 at 10:46 PM, Andrea Faulds a...@ajf.me wrote:

On 7 Jul 2014, at 15:42, Laruence larue...@php.net wrote:


1. The current patch introduces a new “write context” issue. Namely
($foo)['bar'] = 'baz' will not behave this same was as $foo['bar'] =
'baz'. In the former case an undefined variable notice will be thrown
if $foo does not exist, whereas the latter does not throw a notice.

2. As these changes only apply to some very rarely used syntax, the
breakage seems acceptable for PHP 6.


I don't think we should introduce a new thing which is not perfect or
confused.. it looks like we fixed a mess with a new mess.

it make me think we should : don't fix it until it is broken”

We are fixing what is broken here; the variable syntax is counter-intuitive at 
the moment, and they make the syntax more consistent overall.

Also, parentheses in PHP are always a source of issues. I don’t think they’ll 
ever quite work properly unless we switch to using an AST-based parser someday.

then we won't need to temporarily fix it..

anyway, it's just my 2 cents
While I deeply agree with you (introducing something we will need to fix 
later is not a good idea), this RFC fixes a lot of real, concrete and 
immediate issues that are blocking for the emergence of new tools (for 
example, a grammar of PHP that can be used by AST-compliant tools). 
Moreover, it defines a clear base for the semantics of variables. Known 
issues are well-spotted and define the very next steps of the work. 
Parentheses are interpreted in various ways according to the language 
and the area. Thus, a lot of (smart and calm) discussions will be 
required. However, this RFC is targeting PHP6 (and not 7… just kidding… 
or not… o_O), so we have time to fix the next spotted issues before the 
final release. Let's cut the giant task into small ones. I think this is 
the approach of Nikita since he has honestly exposed the known issues.


Cheers :-).

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Syntax for variadic functions

[Ivan Enderlin @ Hoa]

On 28/08/13 17:47, Nikita Popov wrote:

Hi internals!

Hi Nikita :-),



I'd like to propose an RFC, which adds dedicated syntax for variadic
functions:

 https://wiki.php.net/rfc/variadics

Basically this allows declaring variadics directly in the function
signature, rather than fetching the arguments using func_get_args().
Example:

 public function query($query, ...$params) { /* ... */ }

What are your thoughts on this?

Huge +1!
So if we call query('foo'), $params is set to an empty array, right? 
Could it be possible to change this behavior? Would it be interesting? 
For example: public function query($query, ...$params = null).


Cheers.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 5.5.1 released

[Ivan Enderlin @ Hoa]

Congrats :-).


On 19/07/13 10:26, Julien Pauli wrote:

Hi internals,

We just released PHP 5.5.1. This release includes bug fixes as well as a
security fix.
For changes in PHP 5.5.1, please consult the PHP 5 ChangeLog.

Release Announcement:
http://www.php.net/release_5_5_1.phphttp://www.php.net/release_5_5_0.php
Downloads:http://www.php.net/downloads.php#v5.5
Changelog:
http://www.php.net/ChangeLog-5.php#5.5.http://www.php.net/ChangeLog-5.php#5.5.0
1

regards,

Julien Pauli  David Soria Parra



--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] UNKNOW:0, what is it?

[Ivan Enderlin @ Hoa]

On 27/06/13 06:40, Laruence wrote:


thanks for the report, fixed in
https://github.com/php/php-src/commit/fa8611c81ee72839cdff3e72b18cc586feb4aa29

thanks

Thank you!
But it seems that it is a regression because I didn't have this bug before.
How can I fix this in my code? Any idea?

Cheers.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] UNKNOW:0, what is it?

[Ivan Enderlin @ Hoa]

Hello,

Again, I have a segfault with RecursiveDirectoryIterator when I extend 
it. This time, I have a very strange value on my SplFileInfo extension 
(subclass). When I var_dump the value, I have UNKNOWN:0. This is not a 
string, not null, not false, just UNKNOW:0, without type. Any idea of 
what is it?


Thanks :-).

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] UNKNOW:0, what is it?

[Ivan Enderlin @ Hoa]

On 26/06/13 18:19, Johannes Schlüter wrote:

On Wed, 2013-06-26 at 18:05 +0200, Ivan Enderlin @ Hoa wrote:

Hello,

Again, I have a segfault with RecursiveDirectoryIterator when I extend
it. This time, I have a very strange value on my SplFileInfo extension
(subclass). When I var_dump the value, I have UNKNOWN:0. This is not a
string, not null, not false, just UNKNOW:0, without type. Any idea of
what is it?

Thanks :-).

Unknown is an unknown value in a structure when a zval is not properly
set. Most likely you didn't call the parent's constructor.

To bad, the constructor has been called :-(.
The error is here: 
https://github.com/hoaproject/Iterator/blob/master/Recursive/Directory.php#L125. 
This is a line that causes the segfault. And at line 109, 
$this-getRelativePath() returns UNKNOWN:0. But if I var_dump 
$this-_relativePath directly (without using the method), I have a real 
value. I can't explain this.


--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] UNKNOW:0, what is it?

[Ivan Enderlin @ Hoa]

On 26/06/13 18:30, Johannes Schlüter wrote:

On Wed, 2013-06-26 at 18:21 +0200, Ivan Enderlin @ Hoa wrote:

On 26/06/13 18:19, Johannes Schlüter wrote:

On Wed, 2013-06-26 at 18:05 +0200, Ivan Enderlin @ Hoa wrote:

Hello,

Again, I have a segfault with RecursiveDirectoryIterator when I extend
it. This time, I have a very strange value on my SplFileInfo extension
(subclass). When I var_dump the value, I have UNKNOWN:0. This is not a
string, not null, not false, just UNKNOW:0, without type. Any idea of
what is it?

Thanks :-).

Unknown is an unknown value in a structure when a zval is not properly
set. Most likely you didn't call the parent's constructor.

To bad, the constructor has been called :-(.
The error is here:
https://github.com/hoaproject/Iterator/blob/master/Recursive/Directory.php#L125.
This is a line that causes the segfault. And at line 109,
$this-getRelativePath() returns UNKNOWN:0. But if I var_dump
$this-_relativePath directly (without using the method), I have a real
value. I can't explain this.

Try calling the parent ctor before doing anything with properties (i.e.
setting _splFileInfoClass)

If it doesn't fit please provide a complete reproduce script (and report
a bug in any case)

https://bugs.php.net/65136 here we are :-).

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Internal object orientation documentation available!

[Ivan Enderlin @ Hoa]

Hi Nikita,

Thank you (and Julien and Anthony) for this book. Really appreciated!


On 10/06/13 20:33, Nikita Popov wrote:

Hi internals!

We just published some rather extensive documentation on internal object
orientation:

 http://www.phpinternalsbook.com/classes_objects.html

This is part of a larger project aimed at documenting the engine and making
it accessible to new contributors.

Any feedback is appreciated!

Thanks,
Nikita



--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.NEXT Integer and String type modifications

[Ivan Enderlin @ Hoa]

Hey :-),

On 02/06/13 08:52, Johannes Schlüter wrote:

It would be a *gigantic* patch, but the userland effects should be
minimal (the only changes would be supporting longer strings, and consistent 64
bit int support). The performance considerations should be minimal for
non-legacy code (as both would still be using native data types)...

History shows that such gigantic patches are often not finished and done as 
people underestimate the size of PHP and the fact that all etensions have to be 
checked which for this case means checking each external lib for their correct 
type for all their functions etc ... but I don't wan to stop you, I'm happy if 
you do this :-) (while I'm also happy about everybody spending time on fixing 
bugs instead of adding such high-risk changes  ;-))
Is it possible to use a static C analyzer here? It could help a lot. I 
think about Frama-C [1], Pork [2] (now included in Oink [3]) or Clang 
Static Analyser [4] to name a few. A more complete list can be found in [5].


The idea is excellent by the way :-).
Cheers.


[1] http://frama-c.com/
[2] https://developer.mozilla.org/en/docs/Pork
[3] http://daniel-wilkerson.appspot.com/oink/index.html
[4] http://clang-analyzer.llvm.org/
[5] 
http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#C.2FC.2B.2B


--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.NEXT Integer and String type modifications

[Ivan Enderlin @ Hoa]

On 04/06/13 12:08, Pierre Joye wrote:

On Tue, Jun 4, 2013 at 10:41 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:

Hey :-),


On 02/06/13 08:52, Johannes Schlüter wrote:

It would be a *gigantic* patch, but the userland effects should be
minimal (the only changes would be supporting longer strings, and
consistent 64
bit int support). The performance considerations should be minimal for
non-legacy code (as both would still be using native data types)...

History shows that such gigantic patches are often not finished and done
as people underestimate the size of PHP and the fact that all etensions have
to be checked which for this case means checking each external lib for their
correct type for all their functions etc ... but I don't wan to stop you,
I'm happy if you do this :-) (while I'm also happy about everybody spending
time on fixing bugs instead of adding such high-risk changes  ;-))

Is it possible to use a static C analyzer here? It could help a lot. I think
about Frama-C [1], Pork [2] (now included in Oink [3]) or Clang Static
Analyser [4] to name a few. A more complete list can be found in [5].

We do it using Visual C++ static analyzer, which is an excellent tool
for this kind of issue, almost on all commits. As soon as we have a
fork for these changes I will add it so we can get regular updates.

Excellent!

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] php-fpm and systemd integration

[Ivan Enderlin @ Hoa]

On 17/05/13 18:44, Remi Collet wrote:

Hi,

Hi,



I plan to allow php-fpm to be aware of systemd and so, use the
type=notify mode.

I'd like to apply to attached patch to 5.4 and 5.5, as this change have
no impact on standard build (need new --with-fpm-systemd build option).

Any feedback before I process ?
I can't give technical feedbacks about FPM but the feature is welcome! 
Nice idea.


--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] MultipleIterator, add a default value

[Ivan Enderlin @ Hoa]

Hi internals,

I propose to ameliorate the MultipleIterator class.

When a MultipleIterator instance has the MIT_NEED_ANY flag, and when one 
of the attached iterators has reached its end, the returned value is 
NULL. I propose to change this behavior by allowing a different default 
value.


Example with no default value:

$it = new \MultipleIterator(
\MultipleIterator::MIT_NEED_ANY
  | \MultipleIterator::MIT_KEYS_ASSOC
);
$it-attachIterator(new \ArrayIterator(['a', 'b', 'c']), 'foo');
$it-attachIterator(new \ArrayIterator(['x']),   'bar');

foreach($it as $value)
echo $value['foo'], ' = ', $value['bar'], \n;

/**
 * Will output:
 * a = x
 * b =
 * c =
 */

Example with 42 as a default value (given as a third parameter of the 
MultipleIterator::attachIterator method):


$it-attachIterator(new \ArrayIterator(['a', 'b', 'c']), 'foo', 42);
$it-attachIterator(new \ArrayIterator(['x']),   'bar', 42);

foreach($it as $value)
echo $value['foo'], ' = ', $value['bar'], \n;

/**
 * Will output:
 * a = x
 * b = 42
 * c = 42
 */

It is clearly useful when one of the iterators returns an array, used 
directly in a loop. To avoid a NULL pointer exception, we can specify 
an empty array as a default value.


A PHP implementation is pretty easy to do. Naively, we are able to write 
https://github.com/hoaproject/Iterator/commit/59dcff7f331a7338644cf9a8965d2a934a38661e.


If you think it can be useful, I propose to write a RFC with a patch.

Thoughts?

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

Re: [PHP-DEV] Proposed changes to PHP language

[Ivan Enderlin @ Hoa]

On 06/03/13 13:48, Max Romanovsky wrote:

Dear PHP Community,

Hi,


I'd like to propose several changes to PHP core:

1. Allow re-throwing exceptions without losing original stack trace,
like in other technologies:
try {/*...*/} catch(Exception $e) { throw; }

throw $e will do the job.


2. Introduce base class for all PHP classes. E.g. Object. It would help
in type hinting and allow to add new common methods without any magic.
Introduce a type-hint “object” would be better I think. It would replace 
is_object call.




3. Parse body of PUT request in the same manner as it's done for POST
request. I guess it should be stored in $_POST array to maintain backward
compatibility. Otherwise $_REQUEST handling should be aware of new array
with PUT data.

var_dump(file_get_contents('php://input'));
Why is it complicated? And place PUT request body in $_POST sounds a bad 
idea :-).




4. Add handling of DateTime objects to SoapServer and SoapClient. It
will help in using this build-in datatype without typemap.

I tried to google for these proposals, but didn't find any previous
discussions.


Cheers :-).

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] File system watcher/monitoring

[Ivan Enderlin @ Hoa]

Hi Victor,

On 15/02/13 12:43, Victor Berchet wrote:


On 02/14/2013 03:03 PM, Ivan Enderlin @ Hoa wrote:

Hi internal,

A missing feature in PHP is a file system watcher/monitoring 
available for almost all platforms. On Linux, we have inotify 
(available in PHP through pecl/inotify), on Mac OS X, we have 
/dev/fsevents (not available in PHP, since we need ioctl to do that 
in pure PHP —and sudo—, no C extension needed), on FreeBSD, we have 
FAM, and on Windows, we have FileSystemWatcher in .NET. All major 
platforms have a solution ready to use.


By now, if we didn't use these solutions, we should use a finder 
(thanks to RecursiveIteratorIterator and DirectoryIterator in SPL) 
that runs every n seconds and compute a diff with the previous run. 
This solution works fine for a small set of files but it can slow for 
a big one. This is just a tricky solution, not a proper one.


Possible domains where it is needed: test, CI, log, file transfering, 
security etc.


Is it possible to have such a feature landing in PHP (core if karma 
allows it)? or do you want such a feature?


Best regards :-).


Ivan,

Everzet has started to build a client side solution[1]

Hopefuly he will have time to update the PR with what is remaining to 
do soon[2]
I have read your conversation on Twitter. Everzet uses inotify or a 
recursiveiterator as a fallback, as suggested in my first mail, but this 
cannot be extended to FSEvents, FAM etc. A solution in pure PHP is not 
possible for technical reasons (we need ioctl to read from 
/dev/fsevents, or we need a low-level C program for Windows, BSD etc.). 
That's my point here :-).
Of course, “tricky” solutions exist on the Web, like the one proposed by 
Everzet. I did one and you can find many others, but they are 
“incomplete” or “unefficient” most of the times (note the quotes here, 
it depends of the context of use).


Cheers.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] File system watcher/monitoring

[Ivan Enderlin @ Hoa]

On 14/02/13 18:02, Paul Dragoonis wrote:

On Thu, Feb 14, 2013 at 5:00 PM, Patrick ALLAERT patrickalla...@php.netwrote:


2013/2/14 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net:

I have written: “On Linux, we have inotify (available in PHP through
pecl/inotify)”, so yup, I know for inotify :-). I propose to gather all
these API and give a proper one to the end-user.

If you are doing so, I would suggest you to create this as a C
library, that way you could bring that feature to any
applications/languages and you would only have to create a bridge as a
PECL extension.


and to carry on from Patrick's point, it would probably be cleaner to do it
this way so your library wouldn't need to work around PHP stuff.
Actually, I have already considered this approach, but to make a clean 
and portable C version, it might be better to use external existing 
libraries (e.g. for events). This might create hard dependencies and 
could be embarassing for a PECL extension, no?


Thoughts?

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] File system watcher/monitoring

[Ivan Enderlin @ Hoa]

On 15/02/13 14:20, Sebastian Krebs wrote:

2013/2/15 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net


Hi Stas,


On 14/02/13 22:37, Stas Malyshev wrote:


Hi!

  A missing feature in PHP is a file system watcher/monitoring available

for almost all platforms. On Linux, we have inotify (available in PHP
through pecl/inotify), on Mac OS X, we have /dev/fsevents (not available
in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C
extension needed), on FreeBSD, we have FAM, and on Windows, we have
FileSystemWatcher in .NET. All major platforms have a solution ready to
use.


I think it'd be great to have a library with unified interface and an
extension that uses it. However, I'm not sure if these libraries are
useful in common php use case - short-lived requests. Could I get the
changes since the last request? Or is it useful only for long-running
persistent processes?


It is only useful for long-running processes.

For example when you are writting tests: at each modifications, you would
like to re-run or re-generate tests. In this case, you have a daemon that
watches files changes and executes a command when needed.


Why do you need PHP for this?
http://stackoverflow.com/questions/3283228/bash-execute-script-on-file-save#answer-3283390

I don't understand your point.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] File system watcher/monitoring

[Ivan Enderlin @ Hoa]

On 15/02/13 14:29, Sebastian Krebs wrote:

2013/2/15 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net


On 15/02/13 14:20, Sebastian Krebs wrote:


2013/2/15 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net**

  Hi Stas,


On 14/02/13 22:37, Stas Malyshev wrote:

  Hi!

   A missing feature in PHP is a file system watcher/monitoring available


for almost all platforms. On Linux, we have inotify (available in PHP
through pecl/inotify), on Mac OS X, we have /dev/fsevents (not
available
in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C
extension needed), on FreeBSD, we have FAM, and on Windows, we have
FileSystemWatcher in .NET. All major platforms have a solution ready to
use.

  I think it'd be great to have a library with unified interface and an

extension that uses it. However, I'm not sure if these libraries are
useful in common php use case - short-lived requests. Could I get the
changes since the last request? Or is it useful only for long-running
persistent processes?

  It is only useful for long-running processes.

For example when you are writting tests: at each modifications, you would
like to re-run or re-generate tests. In this case, you have a daemon that
watches files changes and executes a command when needed.

  Why do you need PHP for this?

http://stackoverflow.com/**questions/3283228/bash-**
execute-script-on-file-save#**answer-3283390http://stackoverflow.com/questions/3283228/bash-execute-script-on-file-save#answer-3283390


I don't understand your point.


For the use-case you described here a PHP-implementation is not required,
because you can use the system-tools to invoke PHPUnit. In fact you don't
need a daemon at all ;)
It is an example :-). I could reply: why do you need need PHPUnit, there 
is so much other tools ;-).


Well, you get the point. These is a lot of applications.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] File system watcher/monitoring

[Ivan Enderlin @ Hoa]

Hi internal,

A missing feature in PHP is a file system watcher/monitoring available 
for almost all platforms. On Linux, we have inotify (available in PHP 
through pecl/inotify), on Mac OS X, we have /dev/fsevents (not available 
in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C 
extension needed), on FreeBSD, we have FAM, and on Windows, we have 
FileSystemWatcher in .NET. All major platforms have a solution ready to use.


By now, if we didn't use these solutions, we should use a finder (thanks 
to RecursiveIteratorIterator and DirectoryIterator in SPL) that runs 
every n seconds and compute a diff with the previous run. This solution 
works fine for a small set of files but it can slow for a big one. This 
is just a tricky solution, not a proper one.


Possible domains where it is needed: test, CI, log, file transfering, 
security etc.


Is it possible to have such a feature landing in PHP (core if karma 
allows it)? or do you want such a feature?


Best regards :-).

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] File system watcher/monitoring

[Ivan Enderlin @ Hoa]

Hi Mike,

On 14/02/13 15:18, Mike Ho wrote:

Just a quick note, FileSystemWatcher in .NET is actually not recommended for 
use by Microsoft.

It does not guarantee that an event will be raised on every new file or file 
mod in a given folder… and it's even less determinstic when trying to deal with 
network share drives.

Microsoft's own developer blogs usually recommend that people roll their own 
polling-based solution instead of depending on FileSystemWatcher (googling 
FileSystemWatcher will yield many many results regarding this).

I'm not necessarily saying that the overall idea is without merit… but it's 
just that if someone does want to try and implement something like this on 
Windows, they should try and avoid whatever Win32 API calls that 
FileSystemWatcher uses.
Ok, thank you for the note. I didn't look deeply in Windows API, just 
Mac OS X and Linux for the moment… Thank you again.





--Mike

On Feb 14, 2013, at 6:03 AM, Ivan Enderlin @ Hoa 
ivan.ender...@hoa-project.net wrote:


Hi internal,

A missing feature in PHP is a file system watcher/monitoring available for 
almost all platforms. On Linux, we have inotify (available in PHP through 
pecl/inotify), on Mac OS X, we have /dev/fsevents (not available in PHP, since 
we need ioctl to do that in pure PHP —and sudo—, no C extension needed), on 
FreeBSD, we have FAM, and on Windows, we have FileSystemWatcher in .NET. All 
major platforms have a solution ready to use.

By now, if we didn't use these solutions, we should use a finder (thanks to 
RecursiveIteratorIterator and DirectoryIterator in SPL) that runs every n 
seconds and compute a diff with the previous run. This solution works fine for 
a small set of files but it can slow for a big one. This is just a tricky 
solution, not a proper one.

Possible domains where it is needed: test, CI, log, file transfering, security 
etc.

Is it possible to have such a feature landing in PHP (core if karma allows it)? 
or do you want such a feature?

Best regards :-).

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php





--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] File system watcher/monitoring

[Ivan Enderlin @ Hoa]

Hello Julien,

On 14/02/13 15:29, Julien Pauli wrote:

On Thu, Feb 14, 2013 at 3:03 PM, Ivan Enderlin @ Hoa 
ivan.ender...@hoa-project.net wrote:


Hi internal,

A missing feature in PHP is a file system watcher/monitoring available for
almost all platforms. On Linux, we have inotify (available in PHP through
pecl/inotify), on Mac OS X, we have /dev/fsevents (not available in PHP,
since we need ioctl to do that in pure PHP —and sudo—, no C extension
needed), on FreeBSD, we have FAM, and on Windows, we have FileSystemWatcher
in .NET. All major platforms have a solution ready to use.

By now, if we didn't use these solutions, we should use a finder (thanks
to RecursiveIteratorIterator and DirectoryIterator in SPL) that runs every
n seconds and compute a diff with the previous run. This solution works
fine for a small set of files but it can slow for a big one. This is just a
tricky solution, not a proper one.

Possible domains where it is needed: test, CI, log, file transfering,
security etc.

Is it possible to have such a feature landing in PHP (core if karma allows
it)? or do you want such a feature?

Best regards :-).


Hello :-)

I don't see why we would have such a thing into PHP Core.
We are already smooth about the file system accesses with a realpath cache,
and users may use different pecl ext if they want to take hand on a lib
such as inotify.

Well ok, forget PHP core, but an extension would be great.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] File system watcher/monitoring

[Ivan Enderlin @ Hoa]

Hi Sebastian,


On 14/02/13 15:40, Sebastian Krebs wrote:

2013/2/14 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net


Hello Julien,


On 14/02/13 15:29, Julien Pauli wrote:


On Thu, Feb 14, 2013 at 3:03 PM, Ivan Enderlin @ Hoa 
ivan.ender...@hoa-project.net wrote:

  Hi internal,

A missing feature in PHP is a file system watcher/monitoring available
for
almost all platforms. On Linux, we have inotify (available in PHP through
pecl/inotify), on Mac OS X, we have /dev/fsevents (not available in PHP,
since we need ioctl to do that in pure PHP —and sudo—, no C extension
needed), on FreeBSD, we have FAM, and on Windows, we have
FileSystemWatcher
in .NET. All major platforms have a solution ready to use.

By now, if we didn't use these solutions, we should use a finder (thanks
to RecursiveIteratorIterator and DirectoryIterator in SPL) that runs
every
n seconds and compute a diff with the previous run. This solution works
fine for a small set of files but it can slow for a big one. This is
just a
tricky solution, not a proper one.

Possible domains where it is needed: test, CI, log, file transfering,
security etc.

Is it possible to have such a feature landing in PHP (core if karma
allows
it)? or do you want such a feature?

Best regards :-).


Hello :-)

I don't see why we would have such a thing into PHP Core.
We are already smooth about the file system accesses with a realpath
cache,
and users may use different pecl ext if they want to take hand on a lib
such as inotify.


Well ok, forget PHP core, but an extension would be great.


At least for inotify there is an extension, which works quite fine. Never
searched something similar for other OSs.
I have written: “On Linux, we have inotify (available in PHP through 
pecl/inotify)”, so yup, I know for inotify :-). I propose to gather all 
these API and give a proper one to the end-user.


--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Improved Linux process title support in the CLI SAPI

[Ivan Enderlin @ Hoa]

Hi Keyur,


On 07/02/13 06:40, Keyur Govande wrote:

Hello,

I've created a new RFC to improve support for setting a CLI process' title
on Linux. It is based off of the PostgreSQL implementation and is more
robust than the proctitle extension.

More details and patch here: https://wiki.php.net/rfc/cli_process_title

Very nice patch. It could be very useful for me.
Could you precise what extensions PHP needs to use these new functions, 
because in your test [1], you skip when pcntl or posix are not loaded. I 
am sure that there is no dependency between them and *ps_title*() 
functions, but it has to be precised in your RFC or you need to write a 
simpler test.


[1] https://gist.github.com/keyurdg/4728770#file-php_ps-patch-L737-L740

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] About PTY

[Ivan Enderlin @ Hoa]

On 30/01/13 12:53, Ferenc Kovacs wrote:

wez turned that off 9 years ago:

https://github.com/php/php-**src/commit/**bd818c0118ba406d82f901d4f97a13*
*4727440df4https://github.com/php/php-src/commit/bd818c0118ba406d82f901d4f97a134727440df4


But why? Are arguments always valid today?

Thanks.



from the previous commits it seems that we had some kind of proc_open build
issue and didn't managed to solve it without removing that:
http://git.php.net/?p=php-src.git;a=history;f=ext/standard/proc_open.c;h=2041d3481ff389e9b2f17d3073176bfdffb0494a;hb=bd818c0118ba406d82f901d4f97a134727440df4
But is it possible to have PTY support today in PHP? These commits are 
from 2004, we are in 2013 now. Maybe new solutions are conceivable.


Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

Re: [PHP-DEV] About PTY

[Ivan Enderlin @ Hoa]

On 04/02/13 16:22, Ferenc Kovacs wrote:

But is it possible to have PTY support today in PHP? These commits are
from 2004, we are in 2013 now. Maybe new solutions are conceivable.

Sure, I was just saying that we didn't had a working and mature solution
back then which we removed later, but added something which was broken,
tried to fix it, but give up and removed.

Great. Do I open a bug?

Regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] About PTY

[Ivan Enderlin @ Hoa]

On 04/02/13 19:37, Ferenc Kovacs wrote:

On Mon, Feb 4, 2013 at 7:32 PM, Ivan Enderlin @ Hoa 
ivan.ender...@hoa-project.net wrote:


On 04/02/13 16:22, Ferenc Kovacs wrote:


But is it possible to have PTY support today in PHP? These commits are

from 2004, we are in 2013 now. Maybe new solutions are conceivable.


Sure, I was just saying that we didn't had a working and mature solution

back then which we removed later, but added something which was broken,
tried to fix it, but give up and removed.


Great. Do I open a bug?



sure, albeit I think that it would infinitely increase the chances to have
this implemented if we could find somebody to actually cook up a patch.
Certainly. I am coming on IRC to look for someone because I don't have 
enough skills to do such a contribution.


Regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Proposal: php://memory/id ( ://temp/id)

[Ivan Enderlin @ Hoa]

Hi internals,

The php://memory, and its respectful sibling php://temp, appear very 
useful when we need to compute streams on-the-fly. They offer a lot of 
services, like avoiding HDD accesses, increasing speed... and through a 
straightforward API /à la/ PHP, e.g. fopen('php://memory', 'r+'). 
However, we always work on the same bucket/space of data (per 
runtime), which prevent us to use two different streams at a time. My 
proposal is to allow access to many buckets/spaces to php://memory and 
its sibling.


I propose the following syntax:

php://memory/id
php://temp/id/maxmemory:size

We append /id to the existing syntax. Thus, it would be possible to 
work on php://memory/foo and php://memory/bar without collisions between 
them. They would represent two distinct buckets/spaces.


The implementation does not seem to require a ton of work, and the use 
cases are numerous regarding the services offered by these wrappers.


Thoughts?
Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

Re: [PHP-DEV] Proposal: php://memory/id ( ://temp/id)

[Ivan Enderlin @ Hoa]

On 31/01/13 11:00, Attila Bukor wrote:

Hi Ivan,

Hi Attila,



I've never actually worked with them, but it seems nice. However, we should
make redirect php://memory and php://temp to php://memory/default and
php://temp/default respectively to avoid break stuff imho.
Obviously yes! Sorry, I miss to precise this point. Thank you for the 
comment.


Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [lists.php] [PHP-DEV] Proposal: php://memory/id ( ://temp/id)

[Ivan Enderlin @ Hoa]

On 31/01/13 11:12, ALeX wrote:

Hi Ivan,


 php://memory/id
 php://temp/id/maxmemory:size

It's not that hard to write such an function in php.
(http://www.php.net/manual/en/function.stream-wrapper-register.php).
Did I say it was hard? This is quite obvious to write such a wrapper, 
but PHP has php://memory. My proposal will save future work to users 
(and offer better performance because we stay in the PHP land).




I even once wrote an handler like string://data-right-here which
allows to read (only) the data-right-here as a file. (I used it for
a function which required a file and does not support strings
directly, and instead of php://memory all data is freed when no longer
used)
Yes. I also have Hoa\Stringbuffer or some stuff like that. But, again, 
it will save future work to users.


Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal: php://memory/id ( ://temp/id)

[Ivan Enderlin @ Hoa]

On 31/01/13 12:00, Sebastian Krebs wrote:

2013/1/31 Chris Wright chr...@aquacool.ltd.uk


I propose the following syntax:

 php://memory/id
 php://temp/id/maxmemory:size

I would very much like to see this as well.

Would this also allow you to open multiple pointers to the same bucket?

For example would this work?

?php

   $fp = fopen('php://memory/foo', 'w+');

   file_put_contents('php://memory/foo', 'data');

   rewind($fp); // would this be necessary?

   echo stream_get_contents($fp); // outputs 'data'



Everything else wouldn't make much sense, because why else should you need
to define an id for it?

Bu whats about


   file_put_contents('php://memory/foo', 'data');
   $fp = fopen('php://memory/foo', 'w+');

'file_put_contents()' closes the stream after writing. I would expect, that
the engine will cleanup the memory (at least sooner or later), but then I
open it again.
Yup, I also expect the engine to clean memory when closing php://memory 
or php://temp, but this is another proposal I think, no?




Additional why don't you just pass the open stream around, if you need to
access it at multiple places?
Is this question for me or Chris? If it is for me, I don't want multiple 
accesses to the same “bucket”/space, I want multiple “buckets”/spaces.


Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal: php://memory/id ( ://temp/id)

[Ivan Enderlin @ Hoa]

On 31/01/13 12:18, Gustavo Lopes wrote:
On Thu, 31 Jan 2013 10:37:53 +0100, Ivan Enderlin @ Hoa 
ivan.ender...@hoa-project.net wrote:



The php://memory, and its respectful sibling php://temp, appear very
useful when we need to compute streams on-the-fly. They offer a lot of
services, like avoiding HDD accesses, increasing speed... and through a
straightforward API /à la/ PHP, e.g. fopen('php://memory', 'r+').
However, we always work on the same bucket/space of data (per
runtime), which prevent us to use two different streams at a time. My
proposal is to allow access to many buckets/spaces to php://memory and
its sibling.



I'm not sure what you mean here. Each time you open a php://memory 
stream, you're working on a new bucket, right?
Yes exact. My bad. But my proposal still persist. Identifying 
php://memory buckets would be nice to retrieve them. For example:


$f1 = fopen('php://memory/foo', 'r+');
fwrite($f1, 'foobar');
unset($f1);

$f1prime = fopen('php://memory/foo', 'r+');
rewind($f1);
var_dump(stream_get_contents($f1)); // string(6) foobar

Is it interesting? In this way, we have a similar behavior than 
php://fd/i, file://, http:// etc.


Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposal: php://memory/id ( ://temp/id)

[Ivan Enderlin @ Hoa]

On 31/01/13 15:35, Gustavo Lopes wrote:
On Thu, 31 Jan 2013 14:55:26 +0100, Ivan Enderlin @ Hoa 
ivan.ender...@hoa-project.net wrote:


I'm not sure what you mean here. Each time you open a php://memory 
stream, you're working on a new bucket, right?
Yes exact. My bad. But my proposal still persist. Identifying 
php://memory buckets would be nice to retrieve them. For example:


 $f1 = fopen('php://memory/foo', 'r+');
 fwrite($f1, 'foobar');
 unset($f1);

 $f1prime = fopen('php://memory/foo', 'r+');
 rewind($f1);
 var_dump(stream_get_contents($f1)); // string(6) foobar

Is it interesting? In this way, we have a similar behavior than 
php://fd/i, file://, http:// etc.




No. When you do unset($f1), you're closing the file and the memory is 
reclaimed. That's how it's supposed to be.

Ok.


Just pass the stream along. If you really need to use operations on 
the URLs themselves, you can easily write a user wrapper that 
delegates to static php://memory streams kept statically.

That's what I did.

Thank you for the clarification.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] About PTY

[Ivan Enderlin @ Hoa]

Hi,

I wonder if PHP supports PTY? I see old codes (from 2004 to 2010) using 
proc_open with $descriptors = [[0 = 'pty']] for example. When I try, I 
have an error because PTY seems to not be supported. ./configure does 
not propose me to --enable-pty as I have seen  in some related posts.


Thanks for the help,
Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] About PTY

[Ivan Enderlin @ Hoa]

On 30/01/13 11:58, Ferenc Kovacs wrote:

On Wed, Jan 30, 2013 at 11:51 AM, Ivan Enderlin @ Hoa 
ivan.ender...@hoa-project.net wrote:


Hi,

I wonder if PHP supports PTY? I see old codes (from 2004 to 2010) using
proc_open with $descriptors = [[0 = 'pty']] for example. When I try, I
have an error because PTY seems to not be supported. ./configure does not
propose me to --enable-pty as I have seen  in some related posts.




Hi,

Hi,


based on http://lxr.php.net/xref/PHP_TRUNK/ext/standard/proc_open.c#653 and
http://lxr.php.net/xref/PHP_TRUNK/ext/standard/proc_open.c#64  (notice the
0 ) I would say it isn't supported anymore.

Yup, I have seen this condition after sending the email.



wez turned that off 9 years ago:
https://github.com/php/php-src/commit/bd818c0118ba406d82f901d4f97a134727440df4

But why? Are arguments always valid today?

Thanks.

--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution

[Ivan Enderlin @ Hoa]

On 29/01/13 09:30, Zeev Suraski wrote:

[snip]

(My guess is that it will show WP being slower and with a more dramatic
improvement.)

By the way, I just realized the % gain wasn't all that self-explanatory -
it's vs. APC, not vs. plain PHP.  I improved the doc to reflect both gains
vs. plain PHP and vs. APC.

It's better now ;-).

Thank you for the contribution. It's a great news! Can APC and 
Optimizer+ work in duo or share some features?


--
Ivan Enderlin
Developer of Hoa
http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Reflection annotations reader

[Ivan Enderlin @ Hoa]

Hi,

My answer below.

On 09/01/13 20:57, guilhermebla...@gmail.com wrote:

Pierrick, before update v3 of patch, let's first clarify things that need
to be discussed.
Rasmus, you have no idea how happy you made me for a gentle comment
pointing something we should think before propose a patch instead of on
(sorry for the wording) bitching about the idea.

There're tons of elements that need to be addressed before working on a
patch.

Oh yeah.


The latest annotations RFC is a small subset of what other languages
support.

Oh yeah.



To a more complete feature-wise, it is required to go to a
previous revision: https://wiki.php.net/rfc/annotations?rev=1302087566

[snip]


Let's discuss? Thanks.
What do you think about my proposal: 
http://news.php.net/php.internals/64727 ?


Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] - True Annotations

[Ivan Enderlin @ Hoa]

Hi internals,

I would like to give you my thoughts about annotations.

An annotation *must not change* the code *behavior* but add a useful 
*information* for the users or *tools*.


The syntax used most of the time is very restrictive (such as 
Foo('Bar'), DateType('datetime'), MinLength(42) etc.). We cannot express 
any logic formula, disjunction, conjunction or anything else. There are 
other *annotation* and *specification* languages, that exist for PHP and 
that are much more complete. So, the referenced RFC is very very 
restrictive. The purpose of annotations could be larger than weakly 
type some data, because it can contain informations of very different 
natures.


Fortunately, there is a common syntax between all existing ones. In Java 
or PHP, we use the @ symbol to introduce a keyword, followed by a 
description. The set of keywords with their descriptions is an 
annotation. For instance: @param, @return, @requires, @ensures, 
@throwable etc. The @ symbol can be different but it is not the purpose 
for now. So, if PHP would propose an API, it would be a way to get the 
description of a keyword. Something like: 
$reflectionAnnotation-getValue('requires') for example, or 
$reflectionAnnotation['requires']. Then, *it is part* to the user or the 
tool to *analyse* (maybe to parse) the description of the keyword to 
give it a *semantics*. It would be a compromise between all existing 
implementations and languages, but it will not close the door to more 
sophisticated annotation or specification languages.
The fact that it is part to the user or the tool to analyse the 
description is not a bad thing. Analyzing annotations should be static, 
not dynamic (i.e. during the runtime). Maybe there are different points 
of view but as annotations must not change the code behavior, runtime 
use cases are very rare.


Then, there is also a confusion between *API documentation* (not just 
simple documentation) and annotations. API documentation is an 
annotation. It does not change the code behavior, it is a useful 
information for users and tools, so *it is an annotation*. There is 
different API documentation syntaxes (or languages), but most of them 
also introduce descriptions by the @ symbol combined with a keyword, so 
it respects my previous words.


As an example of what kind of annotations we are able to have: 
contracts. This is a more complex example of a specification. It does 
not change the code behavior, it is a very important information for the 
user and some tools that automate the test process (by making 
contract-based testing or the design-by-contract paradigm).


So, to summarize myself, I propose that PHP has a native parser for the 
following annotation grammar (not in a formal syntax):


@keyword description;

Maybe, a description can be a block, thus we have:

@keyword { description }

And in the description, we could have other keywords:

@keyword {
@key description;
@word description;
}

It also could be useful to label/index the keyword, maybe by using the 
following syntax:


@keyword[label] description;

It could fit the most existing use cases around without closing the door 
to exotic (i.e. not common) ones, such as contracts or alike 
specifications.


Best regards.



On 09/01/13 11:53, Clint Priest wrote:
Just starting a new thread here to discuss true annotations vs a 
DocBlock Parser:


RFC Referenced:

https://wiki.php.net/rfc/annotations


On 1/9/2013 2:09 AM, Peter Cowburn wrote:

On 9 January 2013 01:08, Rasmus Schultz ras...@mindplay.dk wrote:

I've started working on a new proposal, but I'm getting hung up on the
syntax - if we can't use angle brackets anymore, what can we use? 
Virtually

every symbol on a standard US keyword is an operator of some sort, does
that mean those are all out of the question?

e.g. thinking of concrete possible basic syntax, neither of the 
following

delimiters would work:

[Foo('bar')]

Why would this not work? I'm struggling to think of a place where one
would want to use an annotation where it could be misinterpreted as an
array literal.  If anything, the visual conflict or association with
the array syntax is a good thing in my book: my brain parses it as an
array of one or more annotations.
I agree here, I think the above, if possible would be best.  In my 
mind annotations should proabably be limited in scope to class 
declarations and thus only before a class keyword, before a property 
or method declaration.


In none of those scopes would [ ] be a parsing issue I believe...

The one case would be at the beginning of a class, but if simply added 
something such as:

[:SomeAttribute(xyz,abc),SomeAttribute2]

It could never be confused with short array syntax and is still brief.



--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and 

Re: [PHP-DEV] Ruby's symbols

[Ivan Enderlin @ Hoa]

Hi :-),

Nice proposal but I have few questions and remarks.

My first question is how to delete symbols? I don't know if it is useful 
or not. We should discuss about that. Is `unset(:foo)` enough? How are 
they handled by the GC?


Another question is: where are we able to use symbols? Is it allowed to 
write `const FOO = :bar` for example? Or in a default argument value: 
`public function f ( $x = :foo ) { … }`?


What kind of (arithmetical) operations are allowed on symbols?

You proposed to represent symbols as integers. Could it create 
conflicts? For example: `$foo = [0 = 'bar', :baz = 'qux']`. What 
happens if `:baz` is set to 0?


Finally, if my memory is good, a few months ago, some patches were 
updating “constant strings” performances by representing them as 
“buffers”/“constants” internally, no? Maybe I'm wrong, but it could be a 
middle-way solution if it is not yet implemented (especially since we 
have strings dereferencing, implementation could be ease).


My two cents :-).
Best regards.




On 05/01/13 15:07, Nikita Nefedov wrote:
I know I shouldn't write Ruby in the subject of a letter for 
php-internals ML, but... Just wanted to ask, is anybody interested in 
this feature in PHP?
You can read about it here: 
http://www.randomhacks.net/articles/2007/01/20/13-ways-of-looking-at-a-ruby-symbol


It can be implemented in PHP as a HashTable where key would be strings 
and values would be unique identifiers (just incrementing long, can be 
tracked with nNextFreeElement).


How it would work in userland?

If it would be proposal, I would divide it on two different 
(competitive) proposals:


First, we could implement it so symbol expression would return an 
associated integer.
(note that symbols are most often used as hash keys in ruby so my 
examples are relying on it)

Example:
$foo = array();
$foo[:bar] = qwerty;

var_dump($foo);
// array(1) {
//  [0] =
//  string(6) qwerty
//}

var_dump(:bar); // int(0)

var_dump(:some_new_symbol); // int(1)

This is the easiest way, and I can implement it. But, it would be hard 
to debug.


The second way - we can implement it as a new variable type, and the 
main thing is that arrays will be able to take variables of symbol 
type as keys, I know it sounds scary but it's not so hard actually.
I will drop the part about new variable type, the main thing is how 
HashTables could work with symbols as keys.
We could change the type of nKeyLength (in Bucket) to signed integer 
(now it's unsigned, I don't think we will miss something from that) 
and use it as a flag: if it's -1 (less than zero) - then we know the 
symbol was used as a key, there will be filled bucket.h member with a 
symbol identifier.

That way the above code will evaluate so:
$foo = array();
$foo[:bar] = qwerty;

var_dump($foo);
// array(1) {
//  [:bar] =
//  string(6) qwerty
//}

var_dump(:bar); // symbol(:bar)

var_dump(:some_new_symbol); // symbol(:some_new_symbol)

To make it clear, when retrieving an element by symbol from array, 
these steps will be needed:

1. Get symbol identifier (ulong)
2. Get elements from array where bucket.h equals to this identifier
3. Iterate over those elements and find the one that has nKeyLength == -1
(actually we will iterate over pNext/pLast elements)


What symbols can give:
1. More convenient way to use it almost everywhere as a replacement 
for strings and sometimes for constants. There's a lot of code that 
uses arrays as a parameter-stores. For example, here's how you usually 
define a form in Symfony2:

$builder
-add('title', 'text', array(
'label' = 'Album title'
))
-add('title_alias', 'text', array(
'label' = 'Album alias',
'required' = false,
'property_path' = 'properties.titleAlias'
))
-add('comment', 'text', array(
'label' = 'Comment',
'required' = false,
'property_path' = 'properties.comment'
))
-add('labels', 'text', array(
'label' = 'Musical labels',
'required' = false,
'property_path' = 'properties.labels'
))
-add('language', 'text', array(
'required' = false,
'property_path' = 'properties.language'
))
It could be improved this way:
$builder
-add('title', :text, array(
:label = 'Album title'
))
-add('title_alias', :text, array(
:label = 'Album alias',
:required = false,
:property_path = 'properties.titleAlias'
))
-add('comment', :text, array(
:label = 'Comment',
:required = false,
:property_path = 'properties.comment'
))
-add('labels', :text, array(
:label = 'Musical labels',
:required = false,
 

Re: [PHP-DEV] Ruby's symbols

[Ivan Enderlin @ Hoa]

On 05/01/13 13:21, Nikita Popov wrote:

[snip]
If this is about memory savings, then I don't
think it will help at all. PHP uses interned strings, so all those label
etc strings in your above example actually use the same string value. The
hash for those strings is also precomputed, so symbol don't have a
performance advantage either.
That's what I refered in my previous mail. Thanks Nikita (Popov) for the 
clarification.


Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Generators Revisited

[Ivan Enderlin @ Hoa]

Hi Dmitry,

s/ informatin/information
in the UPGRADING file.

Best regards.

On 28/11/12 11:57, Dmitry Stogov wrote:

Hi

I've tried to review the generators related changes made in PHP-5.5 and
improve them from both consistency and performance points of view.
The patch also makes a small performance improvement to PHP-5.5 in general,
however, it changes some ZE internals that can be used by
some extension (e.g. XDebug).

You can find the list of changes in the UPGRADING file.

http://pastebin.com/AT0SQhAH

Please, review the patch and test it with your custom extensions.

I would like to commit it on Friday morning. Objections?

I also have some additional proposals:

1) EX(Ts) access optimization. With this patch it must be possible to
access temporary variables using execute_data as the base pointer.
execute_data.Ts might be removed at all. In general the same optimization
might be done for EX(CVs) as well.

2) May be it makes sense to forbid return/yield usage in finally blocks
using compile time error. Their behaviour is really unclear.

Any thoughts?

Thanks. Dmitry.



--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

Re: [PHP-DEV] Generators Revisited

[Ivan Enderlin @ Hoa]

Oh, and also :

s/ calcualated/calculated/
s/extended_vallue/extended_value/

(always in the UPGRADING file).

:-)



On 28/11/12 11:57, Dmitry Stogov wrote:

Hi

I've tried to review the generators related changes made in PHP-5.5 and
improve them from both consistency and performance points of view.
The patch also makes a small performance improvement to PHP-5.5 in general,
however, it changes some ZE internals that can be used by
some extension (e.g. XDebug).

You can find the list of changes in the UPGRADING file.

http://pastebin.com/AT0SQhAH

Please, review the patch and test it with your custom extensions.

I would like to commit it on Friday morning. Objections?

I also have some additional proposals:

1) EX(Ts) access optimization. With this patch it must be possible to
access temporary variables using execute_data as the base pointer.
execute_data.Ts might be removed at all. In general the same optimization
might be done for EX(CVs) as well.

2) May be it makes sense to forbid return/yield usage in finally blocks
using compile time error. Their behaviour is really unclear.

Any thoughts?

Thanks. Dmitry.



--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

[PHP-DEV] DateTime::modify('now') is ignored, why?

[Ivan Enderlin @ Hoa]

Hi internals,

I would to modify a \DateTime object to the current time, thus I wrote this:

$d = new \DateTime('+1 hour');
$d-modify('now');

It did not work. Why? Because the documentation 
(http://php.net/datetime.formats.relative) says: “Now - this is simply 
ignored”. Really? But the behavior is pretty straightforward isn't? 
“modify to now” means “set to the current date and time and let the 
timezone unchanged”.


Thoughts?
Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] DateTime::modify('now') is ignored, why?

[Ivan Enderlin @ Hoa]

Hi Chris,

You didn't understand. I have a \DateTime object, and I would like to 
change the date and time to the current date and time = now.
Imagine you have a \DateTime object that was serialized and you would 
like to “refresh” it, you need to $d-modify('now'). This is strictly 
equivalent to $d-setTimestamp(time()) but in a more elegant way. But 
the documentation says that “now” is ignored, and I would like to know 
why because it is useful.


Thanks.

On 26/11/12 12:23, Chris van Dam wrote:

Hi Ivan,

$d = new \DateTime('+1 hour', new \DateTimeZone('Europe/Amsterdam'));

Is exactly the same as:

// Current timestamp with timezone

$d = new \DateTime(null, new \DateTimeZone('Europe/Amsterdam'));
// Add 1 hour to the timestamp with timezone
$d-modify('+1 hour');


This is what you would like to do right? As modifying the timestamp with
another timestamp would make no sense to me.

Kind regards,

Chris van Dam

Op 26-11-12 12:06 schreef Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net:


Hi internals,

I would to modify a \DateTime object to the current time, thus I wrote
this:

$d = new \DateTime('+1 hour');
$d-modify('now');

It did not work. Why? Because the documentation
(http://php.net/datetime.formats.relative) says: ³Now - this is simply
ignored². Really? But the behavior is pretty straightforward isn't?
³modify to now² means ³set to the current date and time and let the
timezone unchanged².

Thoughts?
Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



E-mail disclaimer Nederlands
De informatie verzonden met dit e-mailbericht is vertrouwelijk en kan wettelijk 
voorbehouden zijn. Het is uitsluitend bestemd voor de geadresseerde. Gebruik 
van deze informatie door anderen dan de geadresseerde en zij die gerechtigd 
zijn daarvan kennis te nemen is verboden. Trace staat niet in voor de juiste en 
volledige overbrenging van de inhoud van een verzonden e-mail, noch voor 
tijdige ontvangst daarvan.
E-mail disclaimer English
The information contained in this communication is confidential and may be 
legally privileged. It is intended solely for the use of the individual or 
entity to whom it is addressed and others authorized to receive it. The use of 
it by others is prohibited. Trace is neither liable for the proper and complete 
transmission of the information contained in this communication nor for any 
delay in its receipt.




--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] DateTime::modify('now') is ignored, why?

[Ivan Enderlin @ Hoa]

Hi Sebastien,

On 26/11/12 12:25, Sebastian Krebs wrote:

2012/11/26 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net


Hi internals,

I would to modify a \DateTime object to the current time, thus I wrote
this:

$d = new \DateTime('+1 hour');
$d-modify('now');

It did not work. Why? Because the documentation (http://php.net/datetime.*
*formats.relative http://php.net/datetime.formats.relative) says: “Now
- this is simply ignored”. Really? But the behavior is pretty
straightforward isn't? “modify to now” means “set to the current date and
time and let the timezone unchanged”.


It's not like modify to something, but modify _with_ something. With
your point of view modifiy('+7 days') will _always_ point to next week,
but it should (and it's intuitive right), that it will point to 7 days
after the previous date. So what should modify with now mean?
I understand the different, but then, why “now” is declared in the 
documentation :-) ?




Other way round: You are looking for the set*()-methods :) Because you
want to _set_ a date, not modify one.

Exactly, setTimestamp(time()) resolved by problem.

Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] DateTime::modify('now') is ignored, why?

[Ivan Enderlin @ Hoa]

On 26/11/12 13:02, Derick Rethans wrote:

On Mon, 26 Nov 2012, Ivan Enderlin @ Hoa wrote:


On 26/11/12 12:25, Sebastian Krebs wrote:

2012/11/26 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net


I would to modify a \DateTime object to the current time, thus I wrote
this:

$d = new \DateTime('+1 hour');
$d-modify('now');

It did not work. Why? Because the documentation (http://php.net/datetime.*
*formats.relative http://php.net/datetime.formats.relative) says: Now
- this is simply ignored. Really? But the behavior is pretty
straightforward isn't? modify to now means set to the current date and
time and let the timezone unchanged.


It's not like modify to something, but modify _with_ something. With
your point of view modifiy('+7 days') will _always_ point to next week,
but it should (and it's intuitive right), that it will point to 7 days
after the previous date. So what should modify with now mean?

I understand the different, but then, why now is declared in the
documentation :-) ?

Because people (like you) have tried it before and found it to not do as
they thought :-)

It would have been better never write this keyword ;-).

Thanks.
Have a good day.

PS: In the french version of the documentation, the it is ignored was 
missing. I have submitted a patch.


--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

Re: [PHP-DEV] [RFC] ICU UConverter implementation for ext/intl

[Ivan Enderlin @ Hoa]

Very nice work.
Bravo!


On 30/10/12 02:57, Sara Golemon wrote:

http://wiki.php.net/rfc/uconverter

Discuss!



--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] POST, content-type: application/json and json_decode

[Ivan Enderlin @ Hoa]

On 24/09/12 20:09, Andrew Faulds wrote:

On 21/09/12 12:05, Ivan Enderlin @ Hoa wrote:

Hello,

If PHP receives a HTTP request with the method POST and with the 
header Content-Type: application/x-www-form-encoded, then, it 
automatically parses the request body to populate an array in $_POST. 
If the Content-Type is different (e.g. text/plain or 
application/json), the request body is reachable by reading 
php://input. Well, it is ok.


But is there any plans to consider application/json by parsing the 
request body and populate the result in $_POST (with the help of 
json_decode() maybe)?
I think perhaps that's the wrong approach. It's valid JSON to have a 
list literal at the top level as well, I think. Perhaps we should 
introduce a new $_JSON variable or some such thing? $_BODY?

$_BODY === php://input.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring, a proposition of additional functions

[Ivan Enderlin @ Hoa]

On 24/09/12 20:04, Andrew Faulds wrote:

On 24/09/12 15:41, Ivan Enderlin @ Hoa wrote:
Recently, I crafted a String object that support most of the 
propositions written here. Please, see 
https://github.com/hoaproject/String (file String.php). The code is 
very simple (it implies that it do not need a lot of work to 
implement it in PHP I hope). Some interesting methods:

• append;
• prepend;
• pad;
• getIterator (equivalent of str_split);
• \ArrayAccess methods (with support of out-of-bound indexes);
• getByteAt (with support of out-of-bound indexes);
• getCharDirection;
• fromCode;
• toCode.

I would love such a library to be built into PHP. A more consistent 
approach to scalar operations would be great. hello, 
world-replace('world', 'php'); would be so much nicer than 
str_replace and forgetting the argument order. This is a little 
off-topic, though.
Yup, it is off-topic. We can add new functions in one hand and 
“autoboxing” scalars into OOP style in another hand.


--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] POST, content-type: application/json and json_decode

[Ivan Enderlin @ Hoa]

On 21/09/12 16:16, jpauli wrote:

On Fri, Sep 21, 2012 at 1:05 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:

Hello,

If PHP receives a HTTP request with the method POST and with the header
Content-Type: application/x-www-form-encoded, then, it automatically parses
the request body to populate an array in $_POST. If the Content-Type is
different (e.g. text/plain or application/json), the request body is
reachable by reading php://input. Well, it is ok.

But is there any plans to consider application/json by parsing the request
body and populate the result in $_POST (with the help of json_decode()
maybe)?

If so, I would like to propose a patch but I don't find in the source code
where request body is caugth and parsed (for POST). Any ideas?
Maybe a RFC would also be welcome to complete my suggestion?

Thanks.

Hi !

Reading and parsing post data function is defined as a SAPI struct
function pointer.
You should look at sapi_module_struct definition
(http://lxr.php.net/xref/PHP_5_4/main/SAPI.h#251).

When a request comes in, sapi_activate() is called. It then calls
sapi_read_post_data() http://lxr.php.net/xref/PHP_5_4/main/SAPI.c#459
that itself invokes handlers.
Default handlers are defined here :
http://lxr.php.net/xref/PHP_5_4/main/php_content_types.c#29 and for
POST, by default, sapi_read_standard_form_data() is called (defined
here http://lxr.php.net/xref/PHP_5_4/main/SAPI.c#253)
This function is in fact just a bridge, it tells PHP to call
sapi.read_post() which is a function pointer defined by each SAPI.
Finally, later on, sapi.default_post_reader() is called (again, a
function pointer defined by each SAPI)
I have some questions. Julien told me in private that he didn't know, 
hope other could reply.


By reading the code, I understand that each SAPI is responsible of 
parsing the body of a POST request if it is 
application/x-www-form-urlencoded. Am I right? In SAPI.c, I read that it 
delegates this task to sapi_module.read_post by giving 
SG(request_info).post_data (please, see main/SAPI.c#266).


It implies that if we would like to add the support of application/json, 
then we have to do it for each SAPI? Not very nice :-/.


When I will locate the code to edit, I'm planning to use 
php_json_decode_ex  co.  (please, see ext/json/json.c#633), but the 
hash collision risk is always present. In every case, json_decode() must 
be protected again hash collision (please, see https://bugs.php.net/60655).


Thank you for your help,
Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring, a proposition of additional functions

[Ivan Enderlin @ Hoa]

Hi,

I sent this email during this summer and nobody replied. I would like to 
know your opinion.



On 06/08/12 21:54, Ivan Enderlin @ Hoa wrote:

Hello,

ext/mbstring is very useful, but from my point of view, some functions 
are missing.

I would like to propose the addition of the following functions.

mb_append($str, $piece) and mb_prepend($str, $piece):
To add a $piece to, respectively, the end and the start of $string. It 
should consider the text direction, e.g. if $str is Right-to-Left, 
mb_append() will add $piece to the end, so the left, of $string.


mb_concat($str, $piece):
If mb_append() and mb_prepend() are too hard to understand by users, 
mb_concat() would be pretty much simpler and will act in the same way.

I would insert:
mb_replace($str, $search, $replace):
Complementary to str_replace and less simpler than preg_replace or 
preg_filter (and with better performance because it does not need to 
compile regex to automata etc.).



mb_pad($length, $piece, $end):
Pretty much like strpad but with multi-bytes considering.
Note that, like mb_append and mb_prepend, we do not speak about left 
and right, but start and end.


mb_get_direction($str):
Return LTR or RTL. For one char, it is “easy”. For a string, it is 
more complex because we can have embedding directions (a string with 
many directions).


mb_get_char($code) or mb_chr($code):
Get Unicode character from a code-point/decimal value representation.

mb_get_code($char) or mb_ord($char):
Get code-point/decimal value representation from of Unicode character.

Finally, it would be great if mb_substr() could consider text 
direction (or create a new dedicated function?). For example, 
mb_substr($str, 0, 1) will return the first char from the start (and 
not the left as it is implemented now).


I think it could help developers to create nice libraries without 
requiring a lot of skills in Unicode.

Thoughts?

Best regards :-).


Recently, I crafted a String object that support most of the 
propositions written here. Please, see 
https://github.com/hoaproject/String (file String.php). The code is very 
simple (it implies that it do not need a lot of work to implement it in 
PHP I hope). Some interesting methods:

• append;
• prepend;
• pad;
• getIterator (equivalent of str_split);
• \ArrayAccess methods (with support of out-of-bound indexes);
• getByteAt (with support of out-of-bound indexes);
• getCharDirection;
• fromCode;
• toCode.

Hope this helps :-),
Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] POST, content-type: application/json and json_decode

[Ivan Enderlin @ Hoa]

On 24/09/12 16:48, jpauli wrote:

On Mon, Sep 24, 2012 at 4:21 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:

On 21/09/12 16:16, jpauli wrote:

On Fri, Sep 21, 2012 at 1:05 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:

Hello,

If PHP receives a HTTP request with the method POST and with the header
Content-Type: application/x-www-form-encoded, then, it automatically
parses
the request body to populate an array in $_POST. If the Content-Type is
different (e.g. text/plain or application/json), the request body is
reachable by reading php://input. Well, it is ok.

But is there any plans to consider application/json by parsing the
request
body and populate the result in $_POST (with the help of json_decode()
maybe)?

If so, I would like to propose a patch but I don't find in the source
code
where request body is caugth and parsed (for POST). Any ideas?
Maybe a RFC would also be welcome to complete my suggestion?

Thanks.

Hi !

Reading and parsing post data function is defined as a SAPI struct
function pointer.
You should look at sapi_module_struct definition
(http://lxr.php.net/xref/PHP_5_4/main/SAPI.h#251).

When a request comes in, sapi_activate() is called. It then calls
sapi_read_post_data() http://lxr.php.net/xref/PHP_5_4/main/SAPI.c#459
that itself invokes handlers.
Default handlers are defined here :
http://lxr.php.net/xref/PHP_5_4/main/php_content_types.c#29 and for
POST, by default, sapi_read_standard_form_data() is called (defined
here http://lxr.php.net/xref/PHP_5_4/main/SAPI.c#253)
This function is in fact just a bridge, it tells PHP to call
sapi.read_post() which is a function pointer defined by each SAPI.
Finally, later on, sapi.default_post_reader() is called (again, a
function pointer defined by each SAPI)

I have some questions. Julien told me in private that he didn't know, hope
other could reply.

By reading the code, I understand that each SAPI is responsible of parsing
the body of a POST request if it is application/x-www-form-urlencoded. Am I
right? In SAPI.c, I read that it delegates this task to
sapi_module.read_post by giving SG(request_info).post_data (please, see
main/SAPI.c#266).

It implies that if we would like to add the support of application/json,
then we have to do it for each SAPI? Not very nice :-/.

When I will locate the code to edit, I'm planning to use php_json_decode_ex
 co.  (please, see ext/json/json.c#633), but the hash collision risk is
always present. In every case, json_decode() must be protected again hash
collision (please, see https://bugs.php.net/60655).

The hash collision is a behavior our HashTable implementation carries anyway.
Removing it can only be done safely by changing the hash algorithm,
which is not such an easy task in case of PHP.

I suggest you start your POC writting the json handler without
worrying about hash collisions :)

It was my goal, yup.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] POST, content-type: application/json and json_decode

[Ivan Enderlin @ Hoa]

Hello,

If PHP receives a HTTP request with the method POST and with the header 
Content-Type: application/x-www-form-encoded, then, it automatically 
parses the request body to populate an array in $_POST. If the 
Content-Type is different (e.g. text/plain or application/json), the 
request body is reachable by reading php://input. Well, it is ok.


But is there any plans to consider application/json by parsing the 
request body and populate the result in $_POST (with the help of 
json_decode() maybe)?


If so, I would like to propose a patch but I don't find in the source 
code where request body is caugth and parsed (for POST). Any ideas?

Maybe a RFC would also be welcome to complete my suggestion?

Thanks.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] POST, content-type: application/json and json_decode

[Ivan Enderlin @ Hoa]

On 21/09/12 13:31, Starry Sky wrote:

Hi,

Hi,


This may lead to a BC break.
If the post body contains a variable with the same name in the JSON,  the
$_POST will be confusing.

Can you give me an example please?

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] POST, content-type: application/json and json_decode

[Ivan Enderlin @ Hoa]

On 21/09/12 13:44, Ferenc Kovacs wrote:

On Fri, Sep 21, 2012 at 1:05 PM, Ivan Enderlin @ Hoa 
ivan.ender...@hoa-project.net wrote:


Hello,

If PHP receives a HTTP request with the method POST and with the header
Content-Type: application/x-www-form-encoded, then, it automatically
parses the request body to populate an array in $_POST. If the Content-Type
is different (e.g. text/plain or application/json), the request body is
reachable by reading php://input. Well, it is ok.

But is there any plans to consider application/json by parsing the request
body and populate the result in $_POST (with the help of json_decode()
maybe)?

If so, I would like to propose a patch but I don't find in the source code
where request body is caugth and parsed (for POST). Any ideas?
Maybe a RFC would also be welcome to complete my suggestion?

Thanks.



please watch out to not reintroduce CVE-2011-4885, afair we discussed about
that json_decode also vulnerable to the hash collision, but I don't
remember seeing any fix committed to json_decode.
depending on how would you extract the json encoded variables, this would
make possible to bypass the protection of max_input_vars limits.
Laruence has opened a bug with some patches: 
https://bugs.php.net/bug.php?id=60655. What is the state of this bug?


I don't understand very well the hash collision problem. Any links?

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] POST, content-type: application/json and json_decode

[Ivan Enderlin @ Hoa]

On 21/09/12 14:08, Ferenc Kovacs wrote:

On Fri, Sep 21, 2012 at 1:57 PM, Ivan Enderlin @ Hoa 
ivan.ender...@hoa-project.net wrote:


On 21/09/12 13:44, Ferenc Kovacs wrote:


On Fri, Sep 21, 2012 at 1:05 PM, Ivan Enderlin @ Hoa 
ivan.ender...@hoa-project.net wrote:

  Hello,

If PHP receives a HTTP request with the method POST and with the header
Content-Type: application/x-www-form-**encoded, then, it automatically
parses the request body to populate an array in $_POST. If the
Content-Type
is different (e.g. text/plain or application/json), the request body is
reachable by reading php://input. Well, it is ok.

But is there any plans to consider application/json by parsing the
request
body and populate the result in $_POST (with the help of json_decode()
maybe)?

If so, I would like to propose a patch but I don't find in the source
code
where request body is caugth and parsed (for POST). Any ideas?
Maybe a RFC would also be welcome to complete my suggestion?

Thanks.


  please watch out to not reintroduce CVE-2011-4885, afair we discussed

about
that json_decode also vulnerable to the hash collision, but I don't
remember seeing any fix committed to json_decode.
depending on how would you extract the json encoded variables, this would
make possible to bypass the protection of max_input_vars limits.


Laruence has opened a bug with some patches: https://bugs.php.net/bug.php?
**id=60655 https://bugs.php.net/bug.php?id=60655. What is the state of
this bug?

I don't understand very well the hash collision problem. Any links?



you should find everything googling for the CVE id(CVE-2011-4885).
basically it was an inefficient handling of the colliding haskeys, which
doesn't happen frequently by accident, but a malicious attacker with a
small crafted request was able to send a bunch of input variables which
will all collide, and triggering that slow codepath, which results in a DOS.
see https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4885 and for the
theory of the attack here
http://www.cs.rice.edu/~scrosby/hash/CrosbyWallach_UsenixSec2003.pdf

Ok thanks, got it.

Well, Laruence? :-)

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] POST, content-type: application/json and json_decode

[Ivan Enderlin @ Hoa]

On 21/09/12 16:16, jpauli wrote:

On Fri, Sep 21, 2012 at 1:05 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:

Hello,

If PHP receives a HTTP request with the method POST and with the header
Content-Type: application/x-www-form-encoded, then, it automatically parses
the request body to populate an array in $_POST. If the Content-Type is
different (e.g. text/plain or application/json), the request body is
reachable by reading php://input. Well, it is ok.

But is there any plans to consider application/json by parsing the request
body and populate the result in $_POST (with the help of json_decode()
maybe)?

If so, I would like to propose a patch but I don't find in the source code
where request body is caugth and parsed (for POST). Any ideas?
Maybe a RFC would also be welcome to complete my suggestion?

Thanks.

Hi !

Reading and parsing post data function is defined as a SAPI struct
function pointer.
You should look at sapi_module_struct definition
(http://lxr.php.net/xref/PHP_5_4/main/SAPI.h#251).

When a request comes in, sapi_activate() is called. It then calls
sapi_read_post_data() http://lxr.php.net/xref/PHP_5_4/main/SAPI.c#459
that itself invokes handlers.
Default handlers are defined here :
http://lxr.php.net/xref/PHP_5_4/main/php_content_types.c#29 and for
POST, by default, sapi_read_standard_form_data() is called (defined
here http://lxr.php.net/xref/PHP_5_4/main/SAPI.c#253)
This function is in fact just a bridge, it tells PHP to call
sapi.read_post() which is a function pointer defined by each SAPI.
Finally, later on, sapi.default_post_reader() is called (again, a
function pointer defined by each SAPI)

I agree it's not a very trivial part though :p

No it's clear.
Thanks for clarifying this!

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: alternative callback syntax

[Ivan Enderlin @ Hoa]

On 19/09/12 19:41, Steve Clay wrote:

On 9/19/12 9:26 AM, Ivan Enderlin @ Hoa wrote:

callable is already a reserved word (T_CALLABLE).


Oh, good. It's not listed here http://php.net/manual/en/tokens.php

Exactly. Who is responsible to update the documentation? Julien?

Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: alternative callback syntax

[Ivan Enderlin @ Hoa]

On 19/09/12 20:21, Steve Clay wrote:

On 9/19/12 2:01 PM, Andrew Faulds wrote:

Some other ideas:

$cb = (callable) $obj-bar;
Ah, but (callable) that won't work for global functions, since 
(callable) is a cast, and


(callable) is not usable as a cast (at least in 5.4.7):

$a = (callable)'str'; // Parse error: syntax error, unexpected 
'callable' (T_CALLABLE)


This could work, and it makes sense to me at least.



$cb = {mysql_real_escape_string};
$cb = {mysql_real_escape_string};

These notations are just horrible.

PHP has recently introduced ::class to resolve a classname (namespace 
Foo; A::class // Foo\A). The “::” was originally a resolution operator 
for calls, but now, it is also used for names (which sounds good for 
me). Here, you propose the new notation ::function, which can be 
understood as: “resolve this function or method as a callable”. We stay 
in a resolution context. It is consistent regarding to the evolution of 
this operator.


Another consistent notation is the cast: (callable) $obj-bar;.

However, having { } around with  is absolutely horrible. It is an awful 
blend between references and dynamic variables, it is not consistent and 
error-prone when reading.


Cheers :-).

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: alternative callback syntax

[Ivan Enderlin @ Hoa]

On 20/09/12 10:17, Pierre Joye wrote:

hi,

On Thu, Sep 20, 2012 at 10:09 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:

On 19/09/12 19:41, Steve Clay wrote:

On 9/19/12 9:26 AM, Ivan Enderlin @ Hoa wrote:

callable is already a reserved word (T_CALLABLE).


Oh, good. It's not listed here http://php.net/manual/en/tokens.php

Exactly. Who is responsible to update the documentation? Julien?

Open a bug at bugs.php.net or http://edit.php.net/ or post on the
php-doc mailing list :)

Patch has been proposed through http://edit.php.net.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: alternative callback syntax

[Ivan Enderlin @ Hoa]

On 19/09/12 15:15, Steve Clay wrote:

On 9/19/12 2:37 AM, Sebastian Krebs wrote:

2012/9/19 Steve Clay st...@mrclay.org mailto:st...@mrclay.org

https://wiki.php.net/rfc/__alternative_callback_syntax


reason I like 'Classname::class' for classes) I don't like, that 
functions will look like

classes with a static property function then ...


FWIW, here are the syntaxes I've considered:

func_name; // parser can't distinguish from constant

callablefor func_name; // adds reserved word, token

func_name::callable; // adds reserved word

callable is already a reserved word (T_CALLABLE).



func_name::function; // in RFC

Steve


--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP build-in HTTP server and the HEAD method

[Ivan Enderlin @ Hoa]

Hello,

It is probably me but it seems like the build-in HTTP server does not 
well support the HEAD method. Here is my following test case. First, the 
foo.php file:


   ?php

   var_dump($_SERVER['REQUEST_METHOD']);


And then:

   $ # Run the server.
   $ php -S 127.0.0.1: -t . foo.php  /dev/null 21 

   $ # Test with POST.
   $ curl -v -X POST 127.0.0.1:
   * About to connect() to 127.0.0.1 port  (#0)
   *   Trying 127.0.0.1...
   * connected
   * Connected to 127.0.0.1 (127.0.0.1) port  (#0)
 POST / HTTP/1.1
 User-Agent: curl/7.24.0 (...) libcurl/7.24.0 OpenSSL/0.9.8r
   zlib/1.2.5
 Host: 127.0.0.1:
 Accept: */*

HTTP/1.1 200 OK
Host: 127.0.0.1:
Connection: close
X-Powered-By: PHP/5.5.0-dev
Content-type: text/html
   
   string(4) POST
   * Closing connection #0
   $ # It works, cool.

   $ # Now, test with HEAD.
   $ curl -v -X HEAD 127.0.0.1:
   * About to connect() to 127.0.0.1 port  (#0)
   *   Trying 127.0.0.1...
   * connected
   * Connected to 127.0.0.1 (127.0.0.1) port  (#0)
 HEAD / HTTP/1.1
 User-Agent: curl/7.24.0 (...) libcurl/7.24.0 OpenSSL/0.9.8r
   zlib/1.2.5
 Host: 127.0.0.1:
 Accept: */*

HTTP/1.1 200 OK
Host: 127.0.0.1:
Connection: close
X-Powered-By: PHP/5.5.0-dev
Content-type: text/html
   
   * Closing connection #0


I have to admit that I don't understand, even by looking at the source code.

Thoughts?
Thanks.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

Re: [PHP-DEV] PHP build-in HTTP server and the HEAD method

[Ivan Enderlin @ Hoa]

On 12/09/12 11:15, Damien Tournoud wrote:

On Wed, Sep 12, 2012 at 10:54 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:

Hello,

It is probably me but it seems like the build-in HTTP server does not well
support the HEAD method. Here is my following test case. First, the foo.php
file:

?php

var_dump($_SERVER['REQUEST_METHOD']);

By definition, a HEAD request MUST NOT return a message-body.

Oh grrr, I feel stupid now ;-). I forget this.


This works as expected:

?php
header(X-Request-Method:  . $_SERVER[REQUEST_METHOD]);
?

Here is how it works: main/SAPI.c has code that set
SG(request_info).headers_only = 1 for HEAD requests, and as a
consequence php_request_shutdown() does not flush the output buffer
(if any) to the client.

Ok.


You can force a body to be sent (but that's
likely not going to work with every SAPI) by not having an output
buffer or by calling ob_end_flush() yourself.

Yes but that was not my goal.

Thank you for your reply :-).

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP build-in HTTP server and the HEAD method

[Ivan Enderlin @ Hoa]

On 12/09/12 11:20, Sebastian Krebs wrote:

Hi,

Hi,



As far as I can see everything works as expected: Because HEAD-requests
should not send any content, you don't get any.

Yup, as Damien said.

Thank you.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Moving to an AST-based parsing/compilation process

[Ivan Enderlin @ Hoa]

On 05/09/12 18:59, Andrew Faulds wrote:

On 05/09/12 13:48, Morgan L. Owens wrote:
I'm not a core dev, but I would like to add to the notes above that 
third parties, such as myself, who want to do things with PHP 
source other than run it through a PHP interpreter would also 
appreciate such a separation of concerns.


To date, I've been basing work, which exposes syntactic structure, on 
phc's maketea grammar (Phalanger's is more up to date, but also more 
complicated what with its provenance and the Linq and generics and 
all), but it's reverse-engineered and certainly wrong (oh, that 
reminds me...); the existing grammar is unsuitable because no-one 
wants to see _that_.


Something authoritative that _by definition_ tracks the current 
version would be more reassuring as regards accuracy and 
compatibility (and be more likely to result in something that 
deserves to be let out into the world with confidence).




To add to your point:

If we make it produce an AST, I wonder if we could possibly expose 
this through PHP, perhaps with some sort of extension. Then parsers 
and such for PHP could simply ask PHP to do the parsing for them, and 
then do analysis - no more duplicating official PHP grammar.


I'm just speculating here, but this would be pretty cool if we could 
do it.
+1. It will be very useful for static analysis, test, control flow graph 
etc.


--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Moving to an AST-based parsing/compilation process

[Ivan Enderlin @ Hoa]

Hi Dmitry,

On 06/09/12 07:37, Dmitry Stogov wrote:

Hi Nikita,

Personally, I don't see any reason to build AST. As you mentioned 
yourself, it will be slower and will require more memory. On the other 
hand AST itself would allow to perform only very basic optimizations. 
Most of them can be easily done on VM opcode level as well.
The lexing and parsing processes will not be slower than actual, and the 
construction of an AST is a new process. Well, as usual, new process 
requires new resources. But if we look further, it will certainly be a 
nice tool to perform better opcode caching, it will remove a lot of 
hacks, it will allow third-part tools working on safeness, security, 
quality etc. to go deeper at low-costs which is very important for PHP 
community, it will facilitate future works (implementations, features 
etc.) for PHP… Moreover, it may be possible that compiler compilers have 
a better lexing and parsing processes than actual?


Someone said that AST is more “academical”, yes it is and that is why we 
can benefit from already done researches in this area to avoid memory 
overhead (one among others). We are not the first ones facing this 
problem. It requires some researches before starting to develop this. 
Let's try as a POC and we will quickly see if this is a wrong way or not.


Cheers.




Also, as it's not an easy task, the old ugly hacks will be replaced 
with new mistakes, which would require new hacks in the future :)


The only real advantage could be an ability to expose AST to PHP 
scripts, but only few people may need it.


Thanks. Dmitry.

On 09/04/2012 11:57 PM, Nikita Popov wrote:

Hey folks!

Some people asked me what the advantages of using an AST-based
parsing/compilation process are, so I put together a few quick notes
in an RFC:

https://wiki.php.net/rfc/ast_based_parsing_compilation_process

It would be nice to get a few comments from other core devs on this.

Nikita






--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Moving to an AST-based parsing/compilation process

[Ivan Enderlin @ Hoa]

On 06/09/12 10:11, Stas Malyshev wrote:

Hi!


The lexing and parsing processes will not be slower than actual, and the

construction of an AST is a new process. Well, as usual, new process
requires new resources. But if we look further, it will certainly be a nice
tool to perform better opcode caching, it will remove a lot of hacks, it
will allow third-part tools working on safeness, security, quality etc. to
go deeper at low-costs which is very important for PHP community, it will
facilitate future works

I don't see how it would lead to better opcode caching.
JIT, lazy-parsing, lazy-opcode generation, caching heuristics, 
optimisation of opcode generation…
PHP is interpreted and this is why it is able to offer high dynamic 
constructions and executions. PHP incredibly scales. But we can do 
better, maybe by mixing cache + interpretation in a better way. I don't 
know. I said we are certainly not the first ones facing this “problem”. 
We have to search in the literature if such solutions exist.



As for
third-party tools, I do not see why third-party tools need PHP to change
the parser. If PHP's parser is not good enough for those tools, they can
have their own parser.
Not if we expose the AST directly into the PHP user-land (maybe through 
a specific configuration: --enable-user-ast or something like that).



Maybe the upfront cost of a parse goes up, but once it is parsed and the
opcodes are cached, you won't have this cost again until you change the
script. Then you have all of the benefits for every subsequent request.

So far we have not seen not only any of these benefits, but any
explanation of what exactly these benefits would be and any proof they
would actually benefit anybody.

Because it is a very hard topic and so, it is hard to explain quickly.


I seriously would propose people
interested in this project just take up this project and see if it's
beneficial or not. Just talking about what might happen on the list
would achieve nothing.
Exactly what I have proposed: “Let's try as a POC and we will quickly 
see if this is a wrong way or not”.


Cheers.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Moving to an AST-based parsing/compilation process

[Ivan Enderlin @ Hoa]

Hi,

On 04/09/12 21:57, Nikita Popov wrote:

Hey folks!

Some people asked me what the advantages of using an AST-based
parsing/compilation process are, so I put together a few quick notes
in an RFC:

https://wiki.php.net/rfc/ast_based_parsing_compilation_process

It would be nice to get a few comments from other core devs on this.
From my personal point of view, I see more advantages than 
inconvenients of using an AST.


It is a more consistent and clever way to manipulate a language. We can 
have more optimizations processes, algorithms and heuristics. We have 
already spoken about consistency in the PHP syntax, but it will also be 
easier for contributors to suggest new patches in regards to the syntax 
and syntactic-sugar. An AST will also facilitate opcode caching (even a 
trivial approach at first would be promising I think), and again, it 
will egg on contributors to propose new patches for that. Moreover, 
there are a lot of well-known algorithms and heuristics in the 
literature to compensate for memory overhead. I think about 
lazy-compilation to avoid the build of the whole AST.
Even if the first feeling is that AST appears to bring some issues at 
first, it could be very quickly a benefit for PHP, in terms of 
consistency in the code, performance and memory usage.


Conversely, it requires a lot of work. I can help if needed.

Cheers.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] $obj-attr::method() is not allowed

[Ivan Enderlin @ Hoa]

Hello,

I would like to start with an example:

   ?php

   class A {

public static function foo ( ) {

return 'foo';
}
   }

   class B {

protected $a = null;

public function __construct ( ) {

$this-a = new A();
}

public function a ( ) {

return $this-a;
}

public function f ( ) {

return $this-a::foo();
}
   }

   $b = new B();
   var_dump($b-f());

This is not possible. We have a parse error in B::f because 
$this-a::foo() is not a construction of the language. But we can write:


   $a = $this-a; $a::foo();

In the same way, we can't write:

   $this-a()::foo();

I would like to know why? Is it a compiler related issue or just an 
omission? Would it be interesting to fix it?


Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/

Re: [PHP-DEV] $obj-attr::method() is not allowed

[Ivan Enderlin @ Hoa]

On 03/09/12 17:18, Andrew Faulds wrote:

On 03/09/12 15:51, Ivan Enderlin @ Hoa wrote:


I would like to know why? Is it a compiler related issue or just an 
omission? Would it be interesting to fix it?



There are plenty of examples of this. One from my code:

Can't do this:

self::$views[$path]();

But I *can* do this:

$x = self::$views[$path]; $x();

This is because PHP has a very unusual (and IMO bad) system of 
type-checking at parse-time, by only allowing some specific (although 
quite varied) types of variable access, and combinations of these.


If nikic's idea to rewrite the parser to use an AST is done, I imagine 
this could be fixed. We could also add extra rules, but I think fixing 
the general issue is more important, since it's like plugging two 
holes in a barrel full of water that's just had a machine gun fired at it.

Absolutely.

PHP has no AST? Why? For historical reasons?

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] $obj-attr::method() is not allowed

[Ivan Enderlin @ Hoa]

On 03/09/12 17:20, Andrew Faulds wrote:

On 03/09/12 16:20, Ivan Enderlin @ Hoa wrote:


Absolutely.

PHP has no AST? Why? For historical reasons?


I believe so. Rasmus's original parser was not exactly world-class ;)
Haha, ok ;-). Thanks. I thought it was a compiler related issue, now I 
am sure it is.


Cheers.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Aspect Oriented Programming in PHP

[Ivan Enderlin @ Hoa]

On 23/08/12 16:36, Peter Nguyen wrote:

Hi,

Hi,


AOP (http://en.wikipedia.org/wiki/Aspect-oriented_programming) when used
correctly, can make your application really modular. I've seen several
implementations but they all require compiling of code beforehand. There is
however a PECL extension now (https://github.com/AOP-PHP/AOP) that enable
AOP in PHP directly. I was wondering if there are any interests/possibility
to include AOP into the PHP core?
+1! AOP is very useful when making some safeness or security tools, like 
tests automation (with contracts for making Design-by-Contract or 
Contract Driven Testing). It avoids to instrument the code each time, 
which is a drawn-out/laborious task.
I would really like to see this extension in the core. I'm sure that it 
will be useful for so many people and so many tools (each time you need 
cross-logic in your application architecture actually).


Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] UTF-8 files and include

[Ivan Enderlin @ Hoa]

On 21/08/12 15:13, Rasmus Lerdorf wrote:

On 08/21/2012 09:10 AM, Ivan Enderlin @ Hoa wrote:

Hello,

Some of my users  contributors have met an issue with files containing
UTF-8 on certain Windows configurations (but they actually did not found
the difference). Any idea why?
The issue does not appear on Linux, BSD or Mac OS system, only for
certain Windows.

What do we need to check? --enable-zend-multibyte, some php.ini magic
parameters, some ENV variables?

What kind of issue? Perhaps they are leaving in the BOM? Tell them to
configure their editors to not add a BOM.
It's not from the editor. The filename contains UTF-8 character and the 
include/require fails.


Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] UTF-8 files and include

[Ivan Enderlin @ Hoa]

On 22/08/12 08:57, Pierre Joye wrote:

hi!

On Tue, Aug 21, 2012 at 3:10 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:

Hello,

Some of my users  contributors have met an issue with files containing
UTF-8 on certain Windows configurations (but they actually did not found the
difference). Any idea why?
The issue does not appear on Linux, BSD or Mac OS system, only for certain
Windows.

What do we need to check? --enable-zend-multibyte, some php.ini magic
parameters, some ENV variables?

It can't be fixed easily. Basically avoid by any price to use Unicode
names for the filenames of your projects.

I see.



As it may (very often) works smoothly on most unices, it won't work
ever using current releases or master on Windows. One has to set the
correct codepage and do the conversion from/to UTF-8.
Exactly. I can detect if PHP is running on Windows and making the 
conversion on-the-fly but what kind of conversion? I have tried with 
utf8_decode() but it seems to also fail. Any other idea?


Cheers.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] UTF-8 files and include

[Ivan Enderlin @ Hoa]

On 22/08/12 10:16, Pierre Joye wrote:

On Wed, Aug 22, 2012 at 9:04 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:


As it may (very often) works smoothly on most unices, it won't work
ever using current releases or master on Windows. One has to set the
correct codepage and do the conversion from/to UTF-8.

Exactly. I can detect if PHP is running on Windows and making the conversion
on-the-fly but what kind of conversion? I have tried with utf8_decode() but
it seems to also fail.

It is not possible yet to automatically detect the codepage on
Windows. Also it may be changed during the request time (unlikely but
possible). But if you know it, say using an configuration parameter,
then convert from/to UTF-8  to/from this codepage using mbstring and
pass the result to the file functions, requireco. But that's really
tricky and buggy.


Any other idea?

Yes, don't use UTF-8 in your filenames, that's not portable and bring
all kind of issues (not necessary only on windows).

I had tried :-).


I told you that
already back then on twitter too when you asked me about this issue.

On Twitter? Donnot remember.

Thanks!

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] UTF-8 files and include

[Ivan Enderlin @ Hoa]

On 22/08/12 10:46, Pierre Joye wrote:

On Wed, Aug 22, 2012 at 10:39 AM, Lester Caine les...@lsces.co.uk wrote:

Pierre Joye wrote:

I'd also to ask to do not hijack this thread with a php6/whatever else
rant and keep focusing on answering Ivan's questions instead.

I would ask if any of this HAS changed in windows 7? Does windows do
anything different unicode wise? I'm going to have to move windows
development work to a windows 7 platform soon, so DO the same rules apply?
On XP I know the holes and can avoid them, the very hole Ivan is falling
into.

It is not a windows OS problem but the API we use in PHP. We use the
ANSI APIs while the wildchar ones should be used to fully support
unicode filemanes. So no matter which windows version you use, the
problem remains the same.
Ok. I will remove Unicode characters from my filenames and all will be 
ok. Thanks for clarifying the situation :-).


Cheers.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] UTF-8 files and include

[Ivan Enderlin @ Hoa]

Hello,

Some of my users  contributors have met an issue with files containing 
UTF-8 on certain Windows configurations (but they actually did not found 
the difference). Any idea why?
The issue does not appear on Linux, BSD or Mac OS system, only for 
certain Windows.


What do we need to check? --enable-zend-multibyte, some php.ini magic 
parameters, some ENV variables?


Best regards.

--
Ivan Enderlin
Developer of Hoa
http://hoa.42/ or http://hoa-project.net/

PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
http://disc.univ-fcomte.fr/ and http://www.inria.fr/

Member of HTML and WebApps Working Group of W3C
http://w3.org/


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php