/intval.phpt]
Test is_int() it's FALIASes: is_long() is_integer() functions
[ext/standard/tests/general_functions/is_int.phpt]
Test printf() function : basic functionality - octal format
[ext/standard/tests/strings/printf_basic8.phpt]
Thanks. Dmitry.
On Mon, Jan 19, 2015 at 12:49 PM, Dmitry Stogov dmi
Hi Sara,
This patch increased the size of resulting PHP code size by 80KB.
I know, it's less than 1%, but unfortunately it also affects performance on
absolutely unrelated code.
This patch leads to increase in iTLB-loads from 17K to 21K on each request
to Wordpress home page and as result in
hi Pierre,
please send your test results when they available.
Thanks. Dmitry.
On Mon, Jan 19, 2015 at 1:11 PM, Pierre Joye pierre@gmail.com wrote:
On Jan 19, 2015 4:49 PM, Dmitry Stogov dmi...@zend.com wrote:
Despite of PEAR, I also found few other apps, from my usual test list
Hi Benjamin,
Thanks for idea.
With PHP7 AST compiler, it's quite easy to implement this (it took us 15
minutes to try :)
However, it doesn't make big improvement on our benchmarks.
We will take a look into possibilities to apply your idea to other patterns
(e.g. for and foreach loops).
Anyway,
I was just surprised by the current behavior :)
$ cat ops.php
?php
function foo(string $str) {
}
foo(ops);
?
$ sapi/cli/php -n ops.php
Catchable fatal error: Argument 1 passed to foo() must be an instance of
string, string given in ops.php on line 2
It too me time to realize what is going on
it on Monday.
Xinchen, Nikita, please verify me.
Thanks. Dmitry.
On Fri, Jan 16, 2015 at 7:58 PM, Xinchen Hui xinche...@zend.com wrote:
Hey:
On Sat, Jan 17, 2015 at 12:12 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi Benjamin,
Thanks for idea.
With PHP7 AST compiler, it's quite easy to implement
I don't know which ones are supported or not.
Of course we need some extension to connect to database mysql, mysqli or
pdo_mysql.
Thanks. Dmitry.
On Thu, Jan 15, 2015 at 11:03 AM, Pierre Joye pierre@gmail.com wrote:
On Thu, Jan 15, 2015 at 8:56 AM, Dmitry Stogov dmi...@zend.com wrote
, Andrea Faulds a...@ajf.me wrote:
Hey Dmitry,
On 15 Jan 2015, at 07:56, Dmitry Stogov dmi...@zend.com wrote:
ext/session and ext/json are required by most apps.
Actually I stopped attempts to build it when I saw compilation errors in
ext/session.
Thanks. Dmitry.
Oh dear, does ext/session
IR - Instruction Retired.
We measure them using callgrind to analyze micro-improvements.
See https://wiki.php.net/phpng#performance_evaluation for more details.
Thanks. Dmitry.
On Wed, Jan 14, 2015 at 5:56 PM, Alexander Kurilo a...@kurilo.me wrote:
Hi Xinchen,
my draft patch (which
Hi Andrea,
Where can I get the code?
Thanks. Dmitry.
On Thu, Jan 8, 2015 at 7:02 PM, Dmitry Stogov dmi...@zend.com wrote:
I'm really surprised by the results :)
I'll try to find time for bigint on next week and play with it a bit.
Thanks. Dmitry.
On Wed, Jan 7, 2015 at 2:54 AM, Andrea
In my opinion, version 0.1 was consistent enough.
handling two different approaches just makes mess...
We have internal function strlen(string $s), and it may be called with
integer argument e.g. strlen(123) - 3
I think user functions should follow the same rules.
If some rules are bad, lets
, at 19:43, Dmitry Stogov dmi...@zend.com wrote:
Hi Andrea,
Where can I get the code?
Thanks. Dmitry.
Hey Dmitry,
The bigint-libtommath branch was merged back into the bigint branch since
I figured there was no point keeping them separate, even if the LibTomMath
backend isn’t quite
ext/session and ext/json are required by most apps.
Actually I stopped attempts to build it when I saw compilation errors in
ext/session.
Thanks. Dmitry.
On Thu, Jan 15, 2015 at 10:44 AM, Pierre Joye pierre@gmail.com wrote:
On Thu, Jan 15, 2015 at 8:05 AM, Dmitry Stogov dmi...@zend.com
I don't see big problems committing this.
In some cases new sort() functions may provide different results, but they
are still valid, because the order of equal elements after sort is not
defined.
Thanks. Dmitry.
On Wed, Jan 14, 2015 at 12:59 PM, Xinchen Hui larue...@php.net wrote:
Hey:
yeah, I remember I saw something :)
Lets do the core work first and then decide how the Reflection should look
like.
Thanks. Dmitry.
On Fri, Jan 9, 2015 at 9:26 PM, Levi Morrison le...@php.net wrote:
The implementation misses support for reflection.
I think, it doesn't make a lot of sense
I'm really surprised by the results :)
I'll try to find time for bigint on next week and play with it a bit.
Thanks. Dmitry.
On Wed, Jan 7, 2015 at 2:54 AM, Andrea Faulds a...@ajf.me wrote:
Hey Dmitry,
On 23 Oct 2014, at 16:22, Dmitry Stogov dmi...@zend.com wrote:
I’ve so far been
Hi,
I've updated the implementation and now it's even more consistent (it
shares code for return and argument type hinting).
https://github.com/php/php-src/pull/986/files
The implementation misses support for reflection.
I think, it doesn't make a lot of sense to introduce Reflection support
consumption.
Thanks. Dmitry.
On Jan 1, 2015 12:26 AM, Anatol Belski anatol@belski.net wrote:
Hi Dmitry,
On Wed, December 31, 2014 11:19, Dmitry Stogov wrote:
Hi,
Please take a look into the patch
https://github.com/php/php-src/pull/970/files
This real changes
Hi François,
this is not a proposal yet, this is just an initial request to the most
experinced PHP developers to think about possible consequnces.
Thanks. Dmitry.
On Dec 31, 2014 9:50 PM, François Laupretre franc...@tekwire.net wrote:
De : Dmitry Stogov [mailto:dmi...@zend.com]
Please
Hi Nikita,
On Jan 1, 2015 5:23 PM, Nikita Popov nikita@gmail.com wrote:
On Wed, Dec 31, 2014 at 11:19 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi,
Please take a look into the patch
https://github.com/php/php-src/pull/970/files
This real changes are in zend_types.h, the rest
Hi,
Please take a look into the patch
https://github.com/php/php-src/pull/970/files
This real changes are in zend_types.h, the rest is renaming that in most
cases makes code cleaner.
zend_array didn't change its binary representation, but now it's not
possible to get a pointer to embedded
Hi Andrea,
Sorry, I thought you were gong to provide a patch for master.
I think it's better not to apply this in 5.6.
Even if it won't make technical problems it'll bring incompatibility
between minor 5.6.* versions.
I made a patch for master on top of yours -
). It always makes improvement. :)
Thanks. Dmitry,
On Thu, Dec 11, 2014 at 1:05 PM, Patrick ALLAERT patrickalla...@php.net
wrote:
Hi,
2014-12-10 16:27 GMT+01:00 Dmitry Stogov dmi...@zend.com:
Hi,
Please, review the following patch
https://gist.github.com/dstogov/fba2cc621ef121826efe
Hi,
Please, review the following patch
https://gist.github.com/dstogov/fba2cc621ef121826efe
It's huge, but actually, only changes in zend_compile.h are matter. The
rest is obvious renaming.
the main idea - the smaller the zend_op structure, the lees memory traffic
is required to load VM
+1
the patch is great.
It doesn't affect non-ZTS build at all.
ZTS build became even a bit faster. :)
And we finally will able to forget about TSRMLS_ macros :)
Non-ZTS ZTS
master native-tls master native-tls bench.php [sec] 1.193 1.195 1.313
1.299 micro_bench.php
[sec] 6.008 6.064 7.470
I don't see technical problems with the patch.
However, I also don't see any significant benefits.
From the user perspective it'll just change error messages and prevent
final final class declarations.
Nikita, what do you think?
Thanks. Dmitry.
On Fri, Dec 5, 2014 at 8:18 PM,
I'm not against the patch, I'm actually indifferent.
Lets wait for Nikita's opinion.
I took just a quick look over static class RFC.
I'll need to think more about it.
Thanks. Dmitry.
On Mon, Dec 8, 2014 at 5:18 PM, guilhermebla...@gmail.com
guilhermebla...@gmail.com wrote:
Hi Dmitry,
As I
I'm going to commit this, if nobody objects.
Thanks. Dmitry.
On Mon, Dec 1, 2014 at 2:08 PM, Dmitry Stogov dmi...@zend.com wrote:
See the updated patch:
https://gist.github.com/dstogov/08b545de6bf113113f58
it can be safely applied again and simplifies inheritance code (thanks to
Levi
Hi Levi,
I understood, that you don't see a big problems with the patch. :)
According to your suggestions, It's possible to do it in this way, but it's
going to be slower, because it would require additional memory allocation,
but I agree that duplicating logic in the code isn't good.
It must be
are excluded as well.
Thanks. Dmitry.
On Sun, Nov 30, 2014 at 7:25 PM, Ferenc Kovacs tyr...@gmail.com wrote:
2014.11.30. 11:14 ezt írta (Dmitry Stogov dmi...@zend.com):
Sorry, I'll try to fix it on Monday.
is it a compilation problem, or how can reproduce it?
I've fixed it already. There were
now the inheritance code is clear enough.
Thanks. Dmitry.
On Mon, Dec 1, 2014 at 11:02 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi Levi,
I understood, that you don't see a big problems with the patch. :)
According to your suggestions, It's possible to do it in this way, but
it's going
Sorry, I'll try to fix it on Monday.
is it a compilation problem, or how can reproduce it?
Thanks. Dmitry.
On Sat, Nov 29, 2014 at 1:01 AM, Ferenc Kovacs tyr...@gmail.com wrote:
2014.11.28. 9:24 ezt írta (Dmitry Stogov dmi...@zend.com):
On Fri, Nov 28, 2014 at 7:33 AM, Xinchen Hui xinche
On Fri, Nov 28, 2014 at 7:33 AM, Xinchen Hui xinche...@zend.com wrote:
Hey:
On Fri, Nov 28, 2014 at 1:27 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi,
I'm working on call/return sequence optimization. As part of this work
I'm
minimizing the size of call frame (zend_execute_data
I see no problems with these patches.
If all tests on PPC are passed, then they should be accepted.
The patches won't affect other architectures.
Anybody tested?
Thanks. Dmitry.
On Thu, Nov 27, 2014 at 3:39 PM, Gustavo Frederico Temple Pedrosa
gustavo.pedr...@eldorado.org.br wrote:
Hi,
I prefer option (3) - invariant return types.
Actually, return type compatibility check should follow all the rules for
parameter type compatibility check (may be even reuse or share the code).
This solution may be implemented efficiently and consistently.
It also must be enough for 99% use cases.
I didn't get what you mean.
parameters are invariant, invariance, which is safe for both and it
shouldn't match parameters are contradictory.
Thanks. Dmitry.
On Fri, Nov 28, 2014 at 1:57 PM, Andrea Faulds a...@ajf.me wrote:
On 28 Nov 2014, at 09:31, Dmitry Stogov dmi...@zend.com wrote
Hi Levi,
if you remember, in my patch return_type was actually stored in
arg_info[-1].
it was mainly done for unification and to allow return type hinting for
internal functions (they already use arg_info[-1])
So the strictures may be compatible.
See
Hi,
I'm working on call/return sequence optimization. As part of this work I'm
minimizing the size of call frame (zend_execute_data) and number of
read/write operations on call/return.
Could you please take a look into the patch that removes EX(scope)
Thanks. Probably, I'll commit it tomorrow.
Dmitry.
On Thu, Nov 27, 2014 at 9:09 PM, Matteo Beccati p...@beccati.com wrote:
Hi Dmitry,
On 27/11/2014 18:27, Dmitry Stogov wrote:
Could you please take a look into the patch that removes EX(scope)
https://gist.github.com/dstogov
Yes, we may store EX(called_scope) in EX(This).value.ce and set another
type and/or flag(s).
But it shouldn't slowdown $this access in _get_obj_zval_ptr_unused() and
other often used functions.
If it's possible, we may try to merge, if not, it doesn't make sense.
Thanks. Dmitry.
On Thu, Nov 27,
May be I misunderstood something, but why to introduce unicode escapes if
PHP engine doesn't support Unicode.
Always converting such escapes into UTF-8 encoding, doesn't make any sense
for people who use other encodings for output, databases, etc.
Thanks. Dmitry.
On Tue, Nov 25, 2014 at 1:09
On Tue, Nov 25, 2014 at 1:00 PM, Andrea Faulds a...@ajf.me wrote:
On 25 Nov 2014, at 08:33, Dmitry Stogov dmi...@zend.com wrote:
May be I misunderstood something, but why to introduce unicode escapes
if PHP engine doesn't support Unicode.
We don't have Unicode strings which are made
On Tue, Nov 25, 2014 at 2:18 PM, Andrea Faulds a...@ajf.me wrote:
On 25 Nov 2014, at 10:41, Dmitry Stogov dmi...@zend.com wrote:
u8string tells that the whole string is UTF-8 encoded.
Your escape Unicode proposal assumes just UTF-8 codepoint, but the
whole string encoding is still
21, 2014 at 10:40 AM, Dmitry Stogov dmi...@zend.com wrote:
thanks Stas. I'll think on next week.
Dmitry.
On Fri, Nov 21, 2014 at 6:59 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
Additional check for ZEND_NULL_FUNCTION in DO_FCALL may be expensive.
I think it must be better
, 2014 at 5:27 PM, Nikita Popov nikita@gmail.com wrote:
On Mon, Nov 17, 2014 at 10:25 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi,
Please review the patch
https://gist.github.com/dstogov/47a39aff37f0a6441ea0
Thanks. Dmitry.
Hi Dmitry, sorry for late reply.
The problem we're trying
Hi Stas,
Sorry, I didn't follow all the discussions.
I think the idea is good.
I'm not sure about implementation.
Additional check for ZEND_NULL_FUNCTION in DO_FCALL may be expensive.
I think it must be better to use special predefined function (see
zend_pass_function usage in zend_vm_def.h).
thanks Stas. I'll think on next week.
Dmitry.
On Fri, Nov 21, 2014 at 6:59 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
Additional check for ZEND_NULL_FUNCTION in DO_FCALL may be expensive.
I think it must be better to use special predefined function (see
zend_pass_function
Of course, it would be great to always use zend_string, but only arg_info
duplication (without char - zend_string) would add ~90KB on 32-bit system
and ~150KB on 64-bit system per process. So I expect 300-500KB wasted per
process.
Actually, only inheritance and reflection code was complicated by
Hi,
Please review the patch https://gist.github.com/dstogov/47a39aff37f0a6441ea0
Thanks. Dmitry.
On Tue, Nov 18, 2014 at 6:01 AM, Xinchen Hui xinche...@zend.com wrote:
Hey:
On Mon, Nov 17, 2014 at 5:25 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi,
Please review the patch
https://gist.github.com/dstogov/47a39aff37f0a6441ea0
I am not sure, why can't we build a zend_string arg-name
On Tue, Nov 18, 2014 at 7:49 AM, Xinchen Hui larue...@gmail.com wrote:
Sent from my iPhone
On Nov 18, 2014, at 12:34 PM, Dmitry Stogov dmi...@zend.com wrote:
On Tue, Nov 18, 2014 at 6:01 AM, Xinchen Hui xinche...@zend.com wrote:
Hey:
On Mon, Nov 17, 2014 at 5:25 PM, Dmitry Stogov
On Fri, Nov 7, 2014 at 7:20 PM, Levi Morrison le...@php.net wrote:
A bug was discovered in the implementation of the return types RFC[1]
that cannot be fixed by the current implementation. A strategy for
fixing the bug has been identified but alters some noticeable behavior
in PHP-land. I
Use A or B for return type in B::foo(). It'll lead to compile error anyway
(Class C is not defined).
It's not possible to compile this by design.
Thanks. Dmitry.
On Thu, Nov 6, 2014 at 6:00 PM, Andrea Faulds a...@ajf.me wrote:
On 6 Nov 2014, at 07:43, Dmitry Stogov dmi...@zend.com wrote
Faulds a...@ajf.me wrote:
On 6 Nov 2014, at 15:08, Dmitry Stogov dmi...@zend.com wrote:
Use A or B for return type in B::foo(). It'll lead to compile error
anyway (Class C is not defined).
It's not possible to compile this by design.
Ok, let’s try this:
?php
class A {
function foo
Hi Levi,
The patch is here https://gist.github.com/dstogov/8deb8b17e41c1a5abf88
I improved memory consumption and unified return type-hinting error
behavior with existing argument type-hinting.
The main semantic must be unchanged.
I also removed part of Reflection changes. I think we should
On Thu, Nov 6, 2014 at 12:05 AM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
Do we always load the class in the hint? We could perhaps only do it
for inheritance checks?
No, classes are not loaded for type checks, since it would be pointless
- if the class is not loaded, you could
I would also prefer to use the same return type hinting compatibility rules
as for argument type-hinting.
May be it's less smart, but more practical.
http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29
Thanks. Dmitry.
On Thu, Nov 6, 2014 at 1:15 AM, Stas Malyshev
It's clear, that covariant types are more smart, but not supporting them,
won't prevent access to more specific type properties and methods.
We are not C++ or Java, and we don't need to cast objects to more specific
types.
On the other hand covariance requires all return types to be defined
I agree with Nikita.
Adding an extra argument for one particular security related case looks
weird.
Will we add more arguments for others?
I would also prefer options array and [] instead of 'false'.
unserialize($string, array('allowed_classes'=[]));
It's also more readable :)
Thanks. Dmitry.
I like the idea, especially list($a, $b, ...$c) = ...
Looks like Prolog's [A, B | C] = ..., unfortunately it won't provide the
same semantic and performance.
Implementation needs to be reviewed, but I think it must not affect
existing opcodes.
Thanks. Dmitry.
On Tue, Nov 4, 2014 at 1:45 AM,
Hi Rasmus,
Sorry for delay, I'm just back to work after ZendCon and holidays.
opcache.revalidate_freq is PHP_INI_ALL on purpose.
Scripts that generate and include the same file again and again should set
it to 0 to check for modification on each include.
I didn't get what did you meant by but
Hi Stas,
I'm not sure if this new argument to unserialize() is intuitive.
May be better to use separate functions - unserialize_filtered() or
something similar.
Thanks. Dmitry.
On Mon, Oct 27, 2014 at 11:03 AM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
I'd like to have a vote on
Hi Andrea,
I don't have strong opinion about this proposal.
It doesn't make any harm to the engine, and it really may speed-up code
especially written for read-only properties.
On the other hand you introduce new orthogonal to private/protected/public
visibility rule,
and I'm not sure if this
On Mon, Oct 27, 2014 at 10:25 PM, Andrea Faulds a...@ajf.me wrote:
On 27 Oct 2014, at 18:31, Dmitry Stogov dmi...@zend.com wrote:
Hi Andrea,
I don't have strong opinion about this proposal.
It doesn't make any harm to the engine, and it really may speed-up code
especially written
if there are no conceptual and implantation problems with static readonly
properties, it's better to implement them in the same patch.
On Mon, Oct 27, 2014 at 11:15 PM, Andrea Faulds a...@ajf.me wrote:
On 27 Oct 2014, at 19:47, Dmitry Stogov dmi...@zend.com wrote:
Oh. I meant static
this won't completely solve the problem, because array keys won't be
UString anymore.
Thanks. Dmtiry.
On Thu, Oct 23, 2014 at 12:11 PM, Joe Watkins pthre...@pthreads.org wrote:
On Tue, 2014-10-21 at 10:30 -0700, Stas Malyshev wrote:
Hi!
I wish there was a way for specific objects to opt
Hi Andrea,
The synthetic benchmarks are not always reflect the impact on real-life
performance.
Unfortunately, I wasn't able to run any big real-life apps with your bigint
branch, because it misses support for commonly used extensions
(ext/session, ext/json, ext/pdo).
I ran bench.php and it's a
On Thu, Oct 23, 2014 at 5:50 PM, Andrea Faulds a...@ajf.me wrote:
Hi!
On 23 Oct 2014, at 13:47, Dmitry Stogov dmi...@zend.com wrote:
Hi Andrea,
The synthetic benchmarks are not always reflect the impact on real-life
performance.
Unfortunately, I wasn't able to run any big real
On Wed, Oct 22, 2014 at 2:51 AM, Andrea Faulds a...@ajf.me wrote:
On 21 Oct 2014, at 10:14, Dmitry Stogov dmi...@zend.com wrote:
some notes:
- it's probably make sense to implement these function as a new
opcode(s) in VM
That could be an optimisation later, yes. I note that you’ve
null or false return value would make these functions not really
useful, because they won't guarantee to return desired type.
printf(%d\n, to_int(abcd)); // will print 0
The only reliable option to support wrong input is exceptions.
On the other hand, exceptions maybe difficult to use or
around it — but I’d rather not wrap an userland function around something
throwing an exception… inefficient and weird.
Thanks,
Bob
Am 22.10.2014 um 12:27 schrieb Dmitry Stogov dmi...@zend.com:
null or false return value would make these functions not really
useful, because they won't
Hi Andrea,
Why don't you use the ability of operator overloading? (it's in the engine
since 5.6).
BIGINT don't have to be completely transparent. If user would like to work
with BIGINT, let them crate PHP objects explicitly and then use operator
overloading. e.g.
?php
function
Hi Joe,
As an extension it looks fine.
I assume, you don't propose to use UString objects in engine and other
extensions.
Unfortunately, it's yet another incomplete solution.
It won't allow Unicode strings as array keys;
concatenation using . (probably may be done),
no auto-conversion from/to
Both, the idea and implementation look fine.
Personally, I hate the existing type conversion rules, and I would like to
use something like this by default (may be with exception for
null/false/true handling), but it may be a big compatibility break, so
introducing to_int() is better than nothing.
On Tue, Oct 21, 2014 at 1:25 PM, Joe Watkins pthre...@pthreads.org wrote:
On Tue, 2014-10-21 at 13:01 +0400, Dmitry Stogov wrote:
Hi Joe,
As an extension it looks fine.
I assume, you don't propose to use UString objects in engine and other
extensions.
I'm not proposing it now
Please think if it may break something.
I wasn't able to find out a case.
Thanks. Dmitry.
-- Forwarded message --
From: Dmitry Stogov dmi...@php.net
Date: Fri, Oct 17, 2014 at 3:01 PM
Subject: [PHP-CVS] com php-src: Don't make difference between undefined and
unaccessible
The RFC is very consistent.
It proposes only a part of the desired type-hinting features, but this part
is not questionable for me.
+1
The implementation has some minor issues.
Levi, if you won't object, I would like to play with implementation a bit,
right before commit (if it accepted).
Hi Chris,
I meant scalar type hinting, nullable type hinting, may be even mixed type
hinting...
But, lets go by small steps to get all this finally accepted.
Thanks. Dmitry.
On Thu, Oct 16, 2014 at 1:35 PM, Chris Wright c...@daverandom.com wrote:
Dmitry
On 16 October 2014 08:44, Dmitry
I think the patch already does it (may be not for all magic methods).
Thanks. Dmitry.
On Thu, Oct 16, 2014 at 2:58 PM, Andrea Faulds a...@ajf.me wrote:
On 16 Oct 2014, at 05:39, Levi Morrison levi_morri...@byu.edu wrote:
- There is a new section about disallowing return types on certain
If we aren't able to fix a low-level problem in a year we most probably
won't be able to fix it in two as well.
Also, the closer we are to release, the more feedback we get, and the more
bugs are able to fix.
Delaying release would just reduce the attention of the users.
Thanks. Dmitry.
On Tue,
I think 1 year is reasonable timeline.
We still have 5 month for active development and implementation of new
ideas.
I think https://wiki.php.net/ideas/php6/engine is a bit outdated.
I'm not sure if anyone are going to work on proposals from 2009 (even if
they are great).
It would be great to
Note, that once we move extension outside of main source tree, only
extension maintainers (if any) will support them.
According to the voting process, I think it makes sense to vote for each
feature separately.
Thanks. Dmitry.
On Sun, Oct 12, 2014 at 4:13 AM, Rasmus Lerdorf
prefer to keep the semantic patch small and don't delete all
FETCH_TSRM() in thousand places (at this point).
Replacing macro in one place must be easier.
It's not a problem to remove them on second step if the PoC would really
work.
Thanks. Dmitry.
On Wed, Oct 8, 2014 at 12:18 PM, Dmitry Stogov
bench.php should be faster as well. It must be slower because of not lucky
code locality or something like that.
Thanks. Dmitry.
On Mon, Oct 13, 2014 at 4:40 PM, anatol@belski.net wrote:
Hi Dmitry,
thanks for taking a look,
On Mon, October 13, 2014 13:38, Dmitry Stogov wrote:
Hi
tjerk.meest...@gmail.com
wrote:
Hi
On 10 Oct 2014, at 03:57, Dmitry Stogov dmi...@zend.com wrote:
Yeah, JavaBridge used it, but it doesn't means it need it.
zend_class_entry * _php_java_get_class_entry(zval *object TSRMLS_DC)
{
return java_class;
}
I agree, it would
Hi Stas,
we discussed this issue with Nikita on IRC, and didn't find any use cases
for objects without ce now.
Nor in php neither in pecl.
Do you see any problems?
Thanks. Dmitry.
On Thu, Oct 9, 2014 at 11:15 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
Commit:
Yeah, JavaBridge used it, but it doesn't means it need it.
zend_class_entry * _php_java_get_class_entry(zval *object TSRMLS_DC)
{
return java_class;
}
I agree, it would be better if we would discuss it on @internals, but it
would take much longer time
If you still see use cases for it,
, Dmitry Stogov dmi...@zend.com wrote:
Yeah, JavaBridge used it, but it doesn't means it need it.
zend_class_entry * _php_java_get_class_entry(zval *object TSRMLS_DC)
{
return java_class;
}
I agree, it would be better if we would discuss it on @internals, but it
would take much
:32, Anatol Belski wrote:
Hi Dmitry,
On Wed, October 1, 2014 08:01, Dmitry Stogov wrote:
Hi Anatol,
I know, TSRM uses TLS APIs internally.
In my opinion, the simplest (and probably efficient) way to get rid
of TSRMLS_DC arguments and TSRMLS_FETCH calls, would
Hi Nikita,
I very like the idea.
Actually, it's a long time desired php feature that many big php users miss.
They don't like to show 500 response in any case.
Also +1 for removing ability of silent E_RECOVERABLE_ERROR bypass :)
I think that few things may be improved
1) I'm not sure if
, Dmitry Stogov wrote:
Hi,
I took a quick look over the patch.
I didn't get why it's named native_tls now, because it doesn't use
__thread variables anymore.
I was wondering myself but now I see (intentionally taking the 5.2 source)
http://lxr.php.net/xref/PHP_5_2/TSRM/TSRM.c#282
http
access (may be I'm wrong). Better models (like
initial-exec) have some limitations. I don't have enough experience to
say, if they could work for us.
Thanks. Dmitry.
On Mon, Sep 29, 2014 at 10:54 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi Anatol.
I'll take a look on Tuesday or Wednesday
Hi Anatol.
I'll take a look on Tuesday or Wednesday.
Thanks. Dmitry.
On Sat, Sep 27, 2014 at 12:59 AM, Anatol Belski anatol@belski.net
wrote:
Hi Dmitry,
On Mon, September 22, 2014 08:43, Dmitry Stogov wrote:
Hi Anatol,
I didn't completely get your ideas, but if tsrm_ls_cache
.
On Fri, Sep 26, 2014 at 5:27 PM, Andrea Faulds a...@ajf.me wrote:
On 26 Sep 2014, at 14:25, Pierre Joye pierre@gmail.com wrote:
On Fri, Sep 26, 2014 at 2:30 PM, Dmitry Stogov dmi...@zend.com wrote:
When I started this RFC I didn't thought about objects.
Actually, they are handled
Simple majority between second and third options will win,
Thanks. Dmitry.
On Fri, Sep 26, 2014 at 7:55 AM, Xinchen Hui larue...@php.net wrote:
On Fri, Sep 26, 2014 at 11:54 AM, Xinchen Hui larue...@php.net wrote:
Hey:
On Fri, Sep 26, 2014 at 6:10 AM, Dmitry Stogov dmi...@zend.com
May be this overflow checks should be optional?
In old ages compilers for Wirth family languages had option to enable or
disable overflow checks.
If option is enabled we may throw an exception, if no - work as today.
Any user would be able to chose between compatibility and safety.
Thanks.
It's an inconsistent undocumented behavior, that started to work not by
design, but because of implementation issues.
?php
list($a, $b) = ab;
var_dump($a,$b);
?
NULL
NULL
By the way, I'm agree, keeping string support might be better for
compatibility.
Thanks. Dmitry.
On Fri, Sep 26, 2014 at
looks like Perl magic :(
-1
Dmitry.
On Mon, Sep 22, 2014 at 3:31 PM, Derick Rethans der...@php.net wrote:
On Sat, 20 Sep 2014, Patrick Schaaf wrote:
Am 20.09.2014 01:35 schrieb Andrea Faulds a...@ajf.me:
https://wiki.php.net/rfc/isset_ternary#vote
Hi,
got a question after
Popov nikita@gmail.com wrote:
On Thu, Sep 25, 2014 at 11:47 PM, Dmitry Stogov dmi...@zend.com wrote:
It was on design. list() was intended to support plain arrays only.
Thanks. Dmitry.
So, just to clarify: If we vote to remove string handling in all cases
does that also mean that we
just change your vote.
I just did it. :)
Even if ArrayAccess worked not by design, it's going to be a big
compatibility issue, removing it.
Strings support would work for free.
Thanks. Dmitry,
On Fri, Sep 26, 2014 at 5:03 PM, Andrea Faulds a...@ajf.me wrote:
On 26 Sep 2014, at 11:11,
801 - 900 of 1669 matches
Mail list logo
