Nikita,
please add a few words abut your latest object handlers related changes.
However, I hardly ever expect that people who might use these handlers read
docs :)
Thanks. Dmitry.
On Fri, Oct 10, 2014 at 2:59 AM, Tjerk Meesters
wrote:
> Hi
>
> On 10 Oct 2014, at 03:57, Dmitry Stog
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, please
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
wrote:
> Hi!
>
> > Commit:ee5b30fa197046973e813a80dd0b7c67827c0
, 2014 21:32, Anatol Belski wrote:
> >
> >> Hi Dmitry,
> >>
> >>
> >>
> >> On Wed, October 1, 2014 08:01, Dmitry Stogov wrote:
> >>
> >>
> >>> Hi Anatol,
> >>>
> >>>
> >>>
> >&g
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 "cact
lot of time on this
topic.
May be description of TLS internals on ELF systems would give you some
ideas.
http://www.akkadia.org/drepper/tls.pdf
Thanks. Dmitry.
On Wed, Oct 1, 2014 at 3:50 AM, Anatol Belski wrote:
> Hi Dmtry,
>
> thanks for taking a look at this.
>
> On Wed, October
se it'll lead to additional function call
for each "__thread" variable 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, 201
ks. Dmitry.
On Fri, Sep 26, 2014 at 5:27 PM, Andrea Faulds wrote:
>
> On 26 Sep 2014, at 14:25, Pierre Joye wrote:
>
> > On Fri, Sep 26, 2014 at 2:30 PM, Dmitry Stogov wrote:
> >> When I started this RFC I didn't thought about objects.
> >> Actually, they
Hi Anatol.
I'll take a look on Tuesday or Wednesday.
Thanks. Dmitry.
On Sat, Sep 27, 2014 at 12:59 AM, Anatol Belski
wrote:
> Hi Dmitry,
>
> On Mon, September 22, 2014 08:43, Dmitry Stogov wrote:
> > Hi Anatol,
> >
> >
> > I didn't completely ge
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 wrote:
>
> On 26 Sep 2014, at 11:11, Nikita Popov w
PM, Nikita Popov wrote:
> On Thu, Sep 25, 2014 at 11:47 PM, Dmitry Stogov 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
looks like Perl magic :(
-1
Dmitry.
On Mon, Sep 22, 2014 at 3:31 PM, Derick Rethans wrote:
> On Sat, 20 Sep 2014, Patrick Schaaf wrote:
>
> > Am 20.09.2014 01:35 schrieb "Andrea Faulds" :
> > >
> > > https://wiki.php.net/rfc/isset_ternary#vote
> >
> > Hi,
> >
> > got a question after being b
It's an inconsistent undocumented behavior, that started to work not by
design, but because of implementation issues.
NULL
NULL
By the way, I'm agree, keeping string support might be better for
compatibility.
Thanks. Dmitry.
On Fri, Sep 26, 2014 at 11:16 AM, Stas Malyshev
wrote:
> Hi!
>
> >
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. Dmitry.
Simple majority between second and third options will win,
Thanks. Dmitry.
On Fri, Sep 26, 2014 at 7:55 AM, Xinchen Hui wrote:
> On Fri, Sep 26, 2014 at 11:54 AM, Xinchen Hui wrote:
> > Hey:
> >
> >
> >
> > On Fri, Sep 26, 2014 at 6:10 AM, Dmitry Stogov wrot
I told it doesn't support strings and objects because it was designed this
way.
I don't know who and when did it.
It's not complicated to change it in any way.
The question which way is better, and it's the reason of voting.
I would prefer not to extend list() to support strings, but in case
"ena
It was on design. list() was intended to support plain arrays only.
Thanks. Dmitry.
On Fri, Sep 26, 2014 at 12:45 AM, Nikita Popov wrote:
> On Thu, Sep 25, 2014 at 10:32 PM, Nikita Popov
> wrote:
>
>> On Thu, Sep 25, 2014 at 1:15 PM, Dmitry Stogov wrote:
>>
>>
> On Thu, Sep 25, 2014 at 1:15 PM, Dmitry Stogov wrote:
>
>> disabling string handling would allow make operation simpler and would
>> improve regular access to array elements.
>> We won't need to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK)
>>
gt; On 25 September 2014 08:42, Dmitry Stogov wrote:
> > Hi,
> >
> > The vote is opened at
> > https://wiki.php.net/rfc/fix_list_behavior_inconsistency
> >
> > Thanks. Dmitry.
>
> Since in the "should people be allowed to vote" thread, I said I th
Hi,
The vote is opened at
https://wiki.php.net/rfc/fix_list_behavior_inconsistency
Thanks. Dmitry.
n Sat, September 20, 2014 09:58, Anatol Belski wrote:
> > Hi Dmitry,
> >
> >
> > On Fri, September 19, 2014 12:43, Dmitry Stogov wrote:
> >
> >> I know :)
> >> Interned strings in PHP5 were implemented as characters allocated in one
> >> si
I think we should vote yes/no for each SAPI independently.
At least I don't see any reason to remove apache SAPI.
We should also email SAPI maintainers.
Thanks. Dmitry.
On Thu, Sep 18, 2014 at 9:34 PM, Anatol Belski
wrote:
> Hi Marius,
>
> On Thu, September 18, 2014 11:08, marius adrian popa wr
Both decisions make sense. I'm indifferent which one to make.
Just not to keep the undocumented inconsistency :)
Thanks. Dmitry,
On Wed, Sep 17, 2014 at 3:00 PM, Derick Rethans wrote:
> On Thu, 11 Sep 2014, Dmitry Stogov wrote:
>
> > Please take a look and make your opini
On Tue, Sep 16, 2014 at 1:23 PM, Andrea Faulds wrote:
>
> On 16 Sep 2014, at 10:16, Dmitry Stogov wrote:
>
> > Shifts by negative number may make sense. (N << -1) => (N >> 1)
> > At least receiving "false" from shift is not very pleasant.
>
Hi Andrea,
Shifts by negative number may make sense. (N << -1) => (N >> 1)
At least receiving "false" from shift is not very pleasant.
In the patch you use SIZEOF_LONG. It probably should be changed to
SIZEOF_ZEND_LONG.
Thanks. Dmitry.
On Mon, Sep 15, 2014 at 8:31 PM, Andrea Faulds wrote:
>
Hi,
Please take a look and make your opinion.
https://wiki.php.net/rfc/fix_list_behavior_inconsistency
This inconsistency might be interpreted like a bug, but fixing it might
break existing PHP code (at least my attempt to fix it in documented way
broke few phpt tests).
Thanks. Dmitry.
Hi Nikita,
On weekend I ran PHP test suite with valgrind and opcache.
I noticed few new tests failures, that most probably introduced by AST
patch.
Bug #21820 ("$arr['foo']" generates bogus E_NOTICE, should be E_PARSE)
[tests/lang/bug21820.phpt]
Bug #66286: Incorrect object comparison with inheri
Hi Matt,
You are right about zend_mm_small_size_to_bit(). It's result must be
undefined for 0 and corresponding part of non-GCC version may be removed as
well. I'll do it.
Thanks. Dmitry.
On Fri, Sep 5, 2014 at 8:00 PM, Matt Wilmas wrote:
> Hi Dmitry, all,
>
> I was looking through a few part
no.
Dmitry.
On Fri, Sep 5, 2014 at 12:14 PM, Pierre Joye wrote:
> On Fri, Sep 5, 2014 at 9:40 AM, Dmitry Stogov wrote:
> > most of the functions converted to FAST_ZPP were collected by profiling
> or
> > real life apps.
> > These functions spent signifi
quot; type specifiers (like "C" or
"L").
Thanks. Dmitry.
On Fri, Sep 5, 2014 at 11:20 AM, Pierre Joye wrote:
> On Fri, Sep 5, 2014 at 8:45 AM, Dmitry Stogov wrote:
> > It's already done for strlen() - ZEND_STRLEN opcode (and few other
> > functions).
> &
It's already done for strlen() - ZEND_STRLEN opcode (and few other
functions).
But it make no sense to convert all useful functions into opcodes.
We need an ability of fast parameter parsing anyway.
Thanks. Dmitry.
On Fri, Sep 5, 2014 at 5:55 AM, Stas Malyshev
wrote:
> Hi!
>
> > As I understa
On Thu, Sep 4, 2014 at 5:32 PM, Derick Rethans wrote:
> On Thu, 4 Sep 2014, Bob Weinand wrote:
>
> > After a long time… back to our fast_zpp RFC.
> >
> > Initially Dmitry proposed to have two different APIs, one for the fast
> version, one for current version:
> > #if FAST_ZPP
> > /* new API
I like the idea of having a single syntax for all cases, but I don't like
the syntax you propose.
In my opinion, it's syntactically inconsistent, less readable and more
error prone, than the old one (sscanf based) and the FAST_ZPP one that is
already in php-master.
I would also prefer to have an a
Hi Anatol,
what do you mean? heap allocated structure?
I think, it's not a good option :(
I didn't have time to think about this yet.
Thanks. Dmitry.
On Mon, Sep 1, 2014 at 5:37 PM, Anatol Belski wrote:
> On Sun, August 31, 2014 22:31, Anatol Belski wrote:
> > Hi Pierre,
> >
> >
> > On Sun,
Hi Tjerk,
Agree.
Bob, is working on adopting his version of the patch.
Once he finish, we will update RFC and open voting.
If you have any related proposals, we may discuss them.
Thanks. Dmitry.
On Thu, Aug 28, 2014 at 8:05 AM, Tjerk Meesters
wrote:
> Hi all,
>
> Now that we’re slowly sett
On Mon, Aug 25, 2014 at 2:59 PM, Pierre Joye wrote:
>
> On Aug 25, 2014 12:56 PM, "Dmitry Stogov" wrote:
> >
> >
> >
> >
> > On Mon, Aug 25, 2014 at 2:45 PM, Pierre Joye
> wrote:
> >>
> >>
> >> On Aug 25, 2014 9:22
On Mon, Aug 25, 2014 at 2:45 PM, Pierre Joye wrote:
>
> On Aug 25, 2014 9:22 AM, "Dmitry Stogov" wrote:
> >
> > Hi Pierre,
> >
> > I'm glad, you agree to rename IS_INT back to IS_LONG.
> >
> > zend_long and size_t usage looks fine.
>
Now we have just 5 failed tests related to 2 unsolved incompatibilities
introduced by phpng.
I'll take care about them. Don't fix them by changing expectation yet.
Thanks. Dmitry.
On Mon, Aug 25, 2014 at 2:01 PM, Tjerk Meesters
wrote:
> Hi!
>
> On 25 Aug, 2014, at 5:4
utput of ext/data/tests/bug67118.phpt seems right.
I'm going to change expectation of these tests in master if you don't
object.
Thanks. Dmitry.
-- Forwarded message ------
From: Dmitry Stogov
Date: Mon, Aug 25, 2014 at 1:28 PM
Subject: Re: date extension broken tests
To:
Hi Matt,
Can you provide instruction how to install and run Joomla and Symfony unit
tests.
Thanks. Dmitry.
On Thu, Aug 21, 2014 at 10:27 PM, Matt Ficken
wrote:
> Master (with PHPNG) builds on Windows (our snapshot build servers were
> never interrupted BTW), though extensions including PDO,
Hi Pierre,
I'm glad, you agree to rename IS_INT back to IS_LONG.
zend_long and size_t usage looks fine.
I see no problems changing zend_string related API and related macros
introduced in NG. They are new for everyone.
I hope, the changes won't make API less clear or useful (so it would be
great
100% agree with RFC.
It would be great if technical improvements wouldn't be messed with this
renaming :(
Thanks. Dmitry,
On Fri, Aug 22, 2014 at 3:16 PM, Nikita Popov wrote:
> Hi internals!
>
> Today the int64 RFC has been merged, despite objections regarding the
> naming changes it introdu
I think it's ok to keep zend_off_t and zend_size_t as is.
Thanks. Dmitry,
On Fri, Aug 22, 2014 at 4:09 PM, Anatol Belski
wrote:
> Hi Nikita,
>
> On Fri, August 22, 2014 13:16, Nikita Popov wrote:
> > Hi internals!
> >
> >
> > Today the int64 RFC has been merged, despite objections regarding th
, Aug 18, 2014 at 7:59 PM, Levi Morrison wrote:
> >>
> >> On Mon, Aug 18, 2014 at 6:04 AM, Dmitry Stogov wrote:
> >> > Hi,
> >> >
> >> > Please take a look into the proposed new Memory Manager for PHP:
> >> >
> >> >
zend_long/zend_ulong without renaming everything else would be a perfect
solution from my point of view.
Thanks. Dmitry.
On Fri, Aug 22, 2014 at 12:49 AM, Nikita Popov wrote:
> On Thu, Aug 21, 2014 at 7:23 PM, Dmitry Stogov wrote:
>
>> Hi,
>>
>> Thanks to Anatol and
Hi Matt,
it looks like you use phpt tests not from master branch.
But anyway, master with phpng definitely has bugs and problems.
I'll try to look into these tests more careful on next week, once big
patches (int64 and AST) are merged.
Thanks. Dmitry.
On Thu, Aug 21, 2014 at 10:35 PM, Matt Fick
On Thu, Aug 21, 2014 at 10:17 PM, Andrea Faulds wrote:
>
> On 21 Aug 2014, at 19:14, Dmitry Stogov wrote:
>
> > Pierre, wait a day, and if we won't have many developers, who against
> the new names - commit it as is.
>
> Perhaps none will be against it now, how
I completely agree.
Dmitry.
On Thu, Aug 21, 2014 at 10:21 PM, Pierre Joye wrote:
>
> On Aug 21, 2014 8:14 PM, "Dmitry Stogov" wrote:
> >
> > Pierre, wait a day, and if we won't have many developers, who against
> the new names - commit it as is.
>
Pierre, wait a day, and if we won't have many developers, who against the
new names - commit it as is.
Thanks. Dmitry.
On Thu, Aug 21, 2014 at 10:03 PM, Pierre Joye wrote:
>
> On Aug 21, 2014 7:58 PM, "Andrea Faulds" wrote:
> >
> >
> > On 21 Aug 2014, at 18:56, Pierre Joye wrote:
> >
> > > T
Hi,
Thanks to Anatol and Pierre the 64-bit patch is ready
https://github.com/weltling/php-src
I made quick code review and don't see any technical problems now.
The performance and memory consumption difference is negligible. see
https://docs.google.com/spreadsheets/d/1PD4oiiXz6B0JbeZYnUSat5fHoq
Hi Stas,
Can you post the list of failed tests
Thanks. Dmitry.
On Thu, Aug 21, 2014 at 11:49 AM, Stas Malyshev
wrote:
> Hi!
>
> >
> > Committed and it works, the build done at travis finished OK.
>
> Yes, I saw it, thanks. A number of tests on debug version have errors or
> segfaults or glibc
done.
Dmitry.
On Thu, Aug 21, 2014 at 12:50 AM, Stas Malyshev
wrote:
> Hi!
>
> > array of registered resources of particular type. See patch:
> >
> > https://gist.github.com/dstogov/f96c04f5979e726909ab
>
> It would be better as a pull, it's be easier to comment on it.
> For the function get_r
The are not defined.
They are open (or closed but not freed yet).
You probably meant get_defined_resorce_types()
Thanks. Dmitry.
On Wed, Aug 20, 2014 at 1:12 PM, Julien Pauli wrote:
> On Wed, Aug 20, 2014 at 7:24 AM, Dmitry Stogov wrote:
> > Anyone objects about it or thinks it
On Wed, Aug 20, 2014 at 1:20 PM, Andrea Faulds wrote:
>
> On 20 Aug 2014, at 06:52, Dmitry Stogov wrote:
>
> > 1) INF conversion to zero seems wrong. May be +INF should be converted
> to MAX_LONG and -INF to MIN_LONG?
>
> I think of Infinity as more of an error value th
1) INF conversion to zero seems wrong. May be +INF should be converted to
MAX_LONG and -INF to MIN_LONG?
2) Negative shifts would be useful, as Sara mentioned.
3) a bit unrelated, but it also may make sense to introduce a logical right
shift operator (>>> in Java)
the rest seems fine, patch look
Anyone objects about it or thinks it needs RFC?
Thanks. Dmitry.
On Wed, Aug 20, 2014 at 6:48 AM, Laruence wrote:
> Hey:
>
>
> On Tue, Aug 19, 2014 at 10:10 PM, Dmitry Stogov wrote:
> > Hi,
> >
> > Yesterday we discussed with Nikta the failure of
> > ext/s
Hi,
Yesterday we discussed with Nikta the failure of
ext/standard/tests/http/bug60570.phpt. It was in context of AST patch, but
the failure is not related to AST at all. It's just a bad test that makes
wrong assumption.
Resource leaks can't be caught using get_memory_usage().
To have a robust wa
Hi Andi,
We already discussed most of semantic changes introduced in AST patch.
Most of them came from another approved RFC
https://wiki.php.net/rfc/uniform_variable_syntax
Thanks. Dmitry.
On Tue, Aug 19, 2014 at 6:32 AM, Andi Gutmans wrote:
> Hi Nikita,
>
> I reviewed the AST RFC on my way t
usage for cases without return type hinting and
decrease it with return type hinting.
Thanks. Dmitry.
On Tue, Aug 19, 2014 at 8:23 AM, Levi Morrison
wrote:
> On Mon, Aug 18, 2014 at 1:43 PM, Dmitry Stogov wrote:
> > Hi Levi,
> >
> > The implementation is really not a pr
8:21 AM, Dmitry Stogov wrote:
> > I see your point. For me they just don't have a lot of sense without each
> > other.
>
> I am the author of two of those RFCs. I've worked with several members
> of the HHVM team so that any inconsistencies are planned and recorded
>
I see your point. For me they just don't have a lot of sense without each
other.
Thanks. Dmitry.
On Mon, Aug 18, 2014 at 6:14 PM, Andrea Faulds wrote:
>
> On 18 Aug 2014, at 15:11, Dmitry Stogov wrote:
>
> > What do you think about merging the following proposals
Hi,
What do you think about merging the following proposals into a single and
consistent one:
https://wiki.php.net/rfc/scalar_type_hinting_with_cast
https://wiki.php.net/rfc/returntypehinting
https://wiki.php.net/rfc/nullable_typehints
I think it makes sense to keep syntax consistent with subset
On Mon, Aug 18, 2014 at 3:39 PM, Nikita Popov wrote:
> On Mon, Aug 18, 2014 at 1:19 PM, Dmitry Stogov wrote:
>
>> On Mon, Aug 18, 2014 at 2:26 PM, Nikita Popov
>> wrote:
>>
>>> On Mon, Aug 18, 2014 at 9:32 AM, Dmitry Stogov wrote:
>>>
>>>>
Hi,
Please take a look into the proposed new Memory Manager for PHP:
https://github.com/php/php-src/pull/777
The patch provides visible performance improvement on real life apps
(tested on Linux 32 and 64 bit). It's based on ideas mainly borrowed from
jemalloc and tcmalloc.
I hope, the patch mu
one more problem
sapi/cli/php -r ' $a = [1,2]; list($b, $a) = $a; var_dump($a,$b);'
Segmentation fault
Thanks. Dmitry.
On Mon, Aug 18, 2014 at 3:19 PM, Dmitry Stogov wrote:
>
>
>
> On Mon, Aug 18, 2014 at 2:26 PM, Nikita Popov
> wrote:
>
>> On Mon, Aug
On Mon, Aug 18, 2014 at 2:26 PM, Nikita Popov wrote:
> On Mon, Aug 18, 2014 at 9:32 AM, Dmitry Stogov wrote:
>
>> Hi Nikita,
>>
>> I think RFC misses few important notes about behavior changes:
>>
>> 1) The behavior of $a->$b[$c] is changed. PHP apps that
Magento doesn't work with AST patch.
500 response on home page, no crash.
Other applications I tested seem to work.
Thanks. Dmitry.
On Mon, Aug 18, 2014 at 11:32 AM, Dmitry Stogov wrote:
> Hi Nikita,
>
> I think RFC misses few important notes about behavior changes:
>
>
constant expressions for properties, etc.
class Foo {
public $x = 5 + SOME_CONST;
}
Thanks. Dmitry.
On Mon, Aug 18, 2014 at 11:52 AM, Sebastian Bergmann
wrote:
> Am 18.08.2014 um 09:32 schrieb Dmitry Stogov:
> > Can OPcahce always keep AST in shared memory and don'
Hi Nikita,
I think RFC misses few important notes about behavior changes:
1) The behavior of $a->$b[$c] is changed. PHP apps that used such syntax
have to be changed into $a->{$b[$c]}.
2) The evaluation order of left and right parts of assignment is changed.
$a[$i++] = $a[$i++]; It wasn't guaran
Thanks for catching this. I'm fixing it.
Dmitry.
On Mon, Aug 18, 2014 at 5:57 AM, Andrea Faulds wrote:
> Hi!
>
> In _z_param_long in Zend/zend_API.h:
>
> if (EXPECTED(Z_TYPE_P(arg) == IS_LONG)) {
> if (strict && UNEXPECTED(Z_DVAL_P(arg) > LONG_MAX)) {
>
Hi,
According to voting result, phpng was merged into master and the version
number was bumped to 7.0.0-dev.
Thanks to contributors, testers, bloggers, voters and everyone evolved :)
Thanks. Dmitry.
On Wed, Aug 6, 2014 at 4:36 PM, Zeev Suraski wrote:
> I opened the voting on the phpng RFC:
>
it's ambiguous with regular object creation.
Thanks. Dmitry.
On Tue, Aug 12, 2014 at 12:47 AM, Michael Wallner wrote:
> How about 'new Function()'?
>
> Might be a WTF that it creates an instance of Closure, though.
> On 11 Aug 2014 22:32, "Dmitry Stogov"
11:33 PM, Andrea Faulds wrote:
>
> On 11 Aug 2014, at 20:07, Dmitry Stogov wrote:
>
> >
> > may be:
> >
> > $a = function strlen;
> >
> > or
> >
> > $a = function(stren);
> >
> > but these are not excellent as well :(
>
> I w
On Mon, Aug 11, 2014 at 10:09 PM, Andrea Faulds wrote:
>
> On 11 Aug 2014, at 08:36, Dmitry Stogov wrote:
>
> > Hi Andrea,
> >
> > Could you measure the performance impact of function referencing.
> >
> > > $func = "strlen";
>
Hi Andrea,
Could you measure the performance impact of function referencing.
vs
I don't like the "&" syntax a lot, but I understand that it's a compromise
between readability and implementation complication.
The patch probably misses support for "&self::foo", "&parent::foo",
"&static::foo".
hi Dan,
you can look into the difference for each particular extension using git.
e.g.
git diff master..phpng -- ext/bcmath
Thanks. Dmitry.
On Wed, Aug 6, 2014 at 7:38 PM, Dan Ackroyd wrote:
> Hi Zeev,
>
> >I have no problem with changing this
> >habit, but I do have an issue with changing
On Wed, Aug 6, 2014 at 5:11 PM, Zeev Suraski wrote:
> Dan,
>
> Votes area almost never pre-announced. I have no problem with changing
> this
> habit, but I do have an issue with changing it retroactively for a
> particular vote.
>
> Regarding your points, there's a mandatory discussion period du
Hi Andrea,
On Wed, Aug 6, 2014 at 4:38 PM, Andrea Faulds wrote:
>
> On 6 Aug 2014, at 13:36, Zeev Suraski wrote:
>
> > I opened the voting on the phpng RFC:
> >
> >
> >
> > https://wiki.php.net/rfc/phpng#vote
> >
> >
> >
> > Voting ends on Thursday, August 14th.
>
> I voted Yes, but I have to
yet another stupid implementation driven behavior :)
+1 for master.
Thanks. Dmitry.
On Wed, Aug 6, 2014 at 9:31 AM, Sebastian Bergmann
wrote:
> Am 06.08.2014 um 06:38 schrieb Sara Golemon:
> > https://wiki.php.net/rfc/switch.default.multiple
>
> Makes sense to me; +1.
>
> --
> PHP Internals
Now it must be completely fixed in git.
Thanks. Dmitry.
On Mon, Aug 4, 2014 at 9:44 PM, Dmitry Stogov wrote:
> We can disable immutable arrays when opcache not loaded or disabled.
> But it's going to be difficult to disable them when script can't fit into
> SHM, becau
We can disable immutable arrays when opcache not loaded or disabled.
But it's going to be difficult to disable them when script can't fit into
SHM, because at the moment of compilation (or optimization) we don't know
the final required size.
Thanks. Dmitry.
On Mon, Aug 4, 2014 at 9:26 PM, Andrea
hi Pascal,
Laruence is right - immutable arrays are not destroyed until the end of
request and this causes a problem in your case.
I've committed a partial fix that destroys unnecessary copies when script
is cached by OPCache, but it doesn't work without opcache or when it
doesn't have enough sha
Bob,
I see you already committed this into PHP-5.6.
I would agree that new behavior is more consistent and may be committed
into master, but I'm still afraid that it may bring as problems because of
last minute changes and lack of tests coverage.
Thanks. Dmitry.
On Sun, Jul 27, 2014 at 3:02 PM
I think opinions about readability are subjective.
The real problem, that it'll break compatibility with old uncommon
compilers.
I'm not sure if new MSVC versions support it, but the one I use - does not.
Breaking something without a real reason is not a good move.
Thanks. Dmitry.
On Mon, Ju
We didn't care about versions while it was a separate branch.
Changing to ZEND_ENGINE_3 makes full sense from my point of view.
Thanks. Dmitry.
On Fri, Jul 25, 2014 at 7:47 AM, Yasuo Ohgaki wrote:
> Hi Zeev,
>
> On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski wrote:
>
> > The RFC is available
n any words.
Thanks. Dmitry,
On Fri, Jul 25, 2014 at 1:39 AM, Kris Craig wrote:
>
>
>
> On Thu, Jul 24, 2014 at 1:37 PM, Dmitry Stogov wrote:
>
>> one week - two weeks - months - years.
>> I'll wait.
>> I know what I'm doing. I'll make it.
&g
one week - two weeks - months - years.
I'll wait.
I know what I'm doing. I'll make it.
Dmitry.
On Fri, Jul 25, 2014 at 12:26 AM, Pierre Joye wrote:
>
> On Jul 24, 2014 10:13 PM, "Dmitry Stogov" wrote:
> >
> > agree,
> >
> > I just don&#x
agree,
I just don't see any blockers, except for Pierre.
Lets wait a week.
Thanks, Dmitry.
On Fri, Jul 25, 2014 at 12:01 AM, Nikita Popov wrote:
> On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov wrote:
>
>> Hi,
>>
>> I didn't see any phpng related discussio
You talk not about starting the voting, you talk about your opinion.
Anyway. No problem I can wait another week and start the voting according
to all the rules.
Dmitry.
On Thu, Jul 24, 2014 at 11:55 PM, Pierre Joye wrote:
>
> On Jul 24, 2014 9:45 PM, "Dmitry Sto
y,
>
> On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov wrote:
> > Hi,
> >
> > I didn't see any phpng related discussion for a day.
> > If we have nothing to discuss, may be we should just the start a voting
> > process. :)
> >
> > It's not a p
The "the" before "start" is a mistake :)
On Thu, Jul 24, 2014 at 11:04 PM, Dmitry Stogov wrote:
> Hi,
>
> I didn't see any phpng related discussion for a day.
> If we have nothing to discuss, may be we should just the start a voting
> process. :)
>
&g
Hi,
I didn't see any phpng related discussion for a day.
If we have nothing to discuss, may be we should just the start a voting
process. :)
It's not a problem for me to wait a week or even month. I just like to
know. if anyone thinks, that we have any stoppers to start the voting.
Last days we
.
On Wed, Jul 23, 2014 at 1:45 PM, Bob Weinand wrote:
> Am 23.7.2014 um 11:34 schrieb Dmitry Stogov :
>
> On Wed, Jul 23, 2014 at 1:20 PM, Bob Weinand wrote:
>
> Yes. Did you see my thoughts before?
>
> I'm just wondering if we can't somehow deeply copy the asts for o
minute before
release.
Actually, you already broke it, and just prohibited usage at run-time.
Thanks. Dmitry.
>
> Bob
>
> Am 23.7.2014 um 10:47 schrieb Dmitry Stogov :
>
> On Wed, Jul 23, 2014 at 12:16 PM, Bob Weinand wrote:
>
>> Hey, thank you for looking i
On Wed, Jul 23, 2014 at 12:16 PM, Bob Weinand wrote:
> Hey, thank you for looking into it :-)
>
> Am 23.7.2014 um 00:23 schrieb Dmitry Stogov :
> > hi Bob,
> >
> > I still think that current array usage in constant expressions is not
> > consistent and dangerou
spent few hours trying to find a solution, but failed. May be my ideas
could lead you to something...
Otherwise, I would recommend to remove this feature from PHP-5.6.
Thanks. Dmitry.
On Tue, Jul 22, 2014 at 10:00 AM, Dmitry Stogov wrote:
> Hi Bob,
>
> Now I think it's not
I'll try to do this.
It would be great, if someone may help.
Thanks. Dmitry.
On Tue, Jul 22, 2014 at 5:18 PM, Etienne Kneuss
wrote:
> On Tue, Jul 22, 2014 at 3:07 PM, Zeev Suraski wrote:
>
> > Once the RFC is approved (I hope)
> >
>
> Before the merge RFC can be considered for voting, I think
On Tue, Jul 22, 2014 at 11:11 AM, Lester Caine wrote:
> On 22/07/14 07:44, Dmitry Stogov wrote:
> > Big PHP users just can't not to care about performance, because it's
> money.
> > I know most of them already experimented with HHVM.
> Big users don't use
Pierre,
I don't replay to you, because it's bad for my health. Many people here
would agree with me.
I prefer to do things instead of endlessly repeated words.
According to PHPNG - we set one big goal (performance), and worked on it
really hard. Now everyone may see the result. It's just not poss
Hi Bob,
Now I think it's not fixable by design :(
I'll try to think about it later today.
Could you please collect all related issues.
Thanks. Dmitry.
On Mon, Jul 21, 2014 at 8:36 PM, Bob Weinand wrote:
> Am 2.7.2014 um 15:43 schrieb Dmitry Stogov :
>
> I don't ha
901 - 1000 of 1732 matches
Mail list logo
