Hi,
Another two cents here.
* Skipping binding a parameter to the exception would make debugging
harder. When you're stepping through code that isn't working correctly to
find a problem and then it throws an Exception which is caught in catch
block that doesn't name it e.g.
try
{
Hi Nikita,
Will it be possible to set the named parameter through using a parameter?
i.e. can you do:
function multipleParamFunction($var1 = null, $var2 = null, $var3 = null,
$var4 = null) {
//...
}
$paramToOverride = 'var3';
testFunction($paramToOverride = 'bar');
which would override 'var3'
Hi Nikita,
If named parameters are introduced, signature validation should include
parameter names. Throwing a fatal error (for the interface/class
combination)
would break backwards compatibility though. We could use some lower error
type...
Would it be possible to set the error level
George Bond wrote:
Then the double-dollar syntax would seem the obvious choice to me:
foo( $$param = 'whatever' );
Which is no less readable than anywhere else the double-dollar is
allowed... :-p
For the simple case I agree having double $$ signs is not that bad, but it
would get nasty for
, Sep 6, 2013 at 8:16 PM, Adam Harvey ahar...@php.net wrote:
On 6 September 2013 12:12, Dan Ackroyd dan...@basereality.com wrote:
If named parameters are introduced, signature validation should include
parameter names. Throwing a fatal error (for the interface/class
combination)
would break
Thomas Nunninger wrote:
- scalar parameter casting should just be a convenience for coding:
function foo( (int) $i, (string) $s )
{
}
is the same as:
function foo( $i, $s )
{
$i = (int) $i;
$s = (string) $s;
}
or perhaps better::
the function happy. So
that allows no E_CAST being generated, as there has been no implicit
cast, only an explicit conversion somewhere in the DIC.
cheers
Dan
On 17 July 2014 13:43, Thomas Nunninger tho...@nunninger.info wrote:
Hi Dan,
On 07/17/2014 02:12 PM, Dan Ackroyd wrote:
Thomas Nunninger wrote
is not available outside the function for
the first one.
On 17 July 2014 19:29, Dan Ackroyd dan...@basereality.com wrote:
Hi Thomas,
Perhaps I miss your point. But what is the difference to current behavior if
you do not know about the types?
Not to the current behaviour, to the behaviour that would
Hi Remi,
Thanks for the PR. I'll merge it as soon as I've been able to test it,
as the class should respect the definition of the method in the
interface.
Regarding the change in behaviour, I think the patch
https://bugs.php.net/patch-display.php?bug=67064patch=bug67064-BCrevision=1402667581
Hi,
It would be good if people announced that they were going to open
things to vote with a warning, rather than just throwing the voting
open.
The RFC is nowhere complete in it's details for people to make
rational decisions. e.g. the section on 'RFC impact' has this for the
impact on
between
PHP 5.x and PHPNG. Dmitry - please correct me if I'm wrong...
Zeev
-Original Message-
From: Dan Ackroyd [mailto:dan...@basereality.com]
Sent: Wednesday, August 06, 2014 4:01 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] [VOTE] Move the phpng branch to master
How about delaying that warning until the headers are sent?
I don't think there would be any benefit to that. The only possible
scenarios are:
i) People sending duplicate headers by accident. When they see the
error, they should fix their code, so the error goes away.
ii) People who are
Hi Andrea,
When you re-open the voting, please can you have an option that is
'Yes - without numeric typehint' ?
Although I like the idea of the RFC, having a type-hint that matches
multiple scalar types seems distinctly weird to me.
It really needs a separate case making for it, separate from
Stas wrote:
The only issue I think we need to discuss is catch(Exception $e). Now it
would catch much more than before, if we do no changes.
It's not clear why would that be an issue - can you specify what the
problem would be?
Also, if we changed `catch(Exception $e)` to not catch all
Hi,
Wouldn't this RFC be almost instantly deprecated if the Return Type
Declarations RFC ( https://wiki.php.net/rfc/returntypehinting ) is
accepted?
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Florian wrote:
On the PR https://github.com/php/php-src/pull/795/ of the setcookie patch
to become compliant with the HTTP RFC,
There are some facts:
- the current way does not follow the HTTP RFC.
Please stop saying this, it isn't true.
From rfc6265:
Servers SHOULD NOT include more than one
Andrea wrote:
Perhaps it would be worth ditching any attempts to change setcookie() (just
keep it around for backwards-compatibility), and to instead add a new
function, function family, or indeed class for cookie handling.
Thoughts? Any idea what such an API might look like?
I think this API
On 2 November 2014 15:10, Rowan Collins rowan.coll...@gmail.com wrote:
Wait, what does session handling have to do with any of this?
Sorry, I completely failed to write what I was trying to say there.
I meant that like the session handling functions and setcookie are
similar in that:
* They
Hi,
Derick wrote:
I asked him what the original scope of phpdbg was,...
And I very much agree that the above bullet points,
The original scope of a project and what it should be in the future
are not related always related. Please don't pretend that they're the
same thing.
Derick wrote:
I've
On 26 January 2015 at 00:02, Lester Caine les...@lsces.co.uk wrote:
/imagick ... need to get a copy to work with
Imagick is now working on 7; you will need to use the PHP 7 branch
from https://github.com/mkoppanen/imagick/tree/phpseven
Opening any issues you might find on Github would probably
On 2 February 2015 at 19:11, Anatol Belski anatol@belski.net wrote:
The voting ends on 2015-02-09 at 21:00 CET.
This is a ridiculously short voting period for a major decision.
Although the minimum voting time for an RFC is one week, that should
only be used in extremis.
The people affected
Lester,
If you are having issues with Imagick please report them here:
https://github.com/mkoppanen/imagick
Not only is that the right place to report issues with unreleased
versions of Imagick, but also I tend to monitor issues there more
closely than I do a mailing list.
This one of the few
On 4 February 2015 at 10:13, Dmitry Stogov dmi...@zend.com wrote:
This won't fit into loosely-typed PHP, and will lead to writing -
sin((float)$x).
Hi Dmitry,
I think what people miss is that the place where the conversion from
an unknown type to an int takes place, is also the place where you
On 5 February 2015 at 21:52, Levi Morrison le...@php.net wrote:
To chime in regarding allowing contravariant parameter types: I
struggle to find use cases for it.
Theoretically it would allow a class to implement two separate
interfaces that would otherwise be incompatible:
interface A {
As much as I want scalar types I'm voting no as:
i) Having this code:
function foo(int $numberOfRightTurns) {
$x = $numberOfRightTurns * 90;
return sin(deg2rad($x))
}
work or blow up depending on a setting at the top of the file is horrible.
ii) Having the code that I write in userland
On 5 February 2015 at 22:28, Rasmus Lerdorf ras...@lerdorf.com wrote:
Any suggestions for how to handle annotating it? We could turn it into a
fake PR and mark it up using github's PR comments.
I think that's a good idea. It is very easy for people to ask
questions about any change that they
On 16 January 2015 at 01:58, Rasmus Lerdorf ras...@lerdorf.com wrote:
The closest we have at this point is:
https://wiki.php.net/phpng-upgrading
If people
here could skim it and fix anything that isn't current it would help.
Thanks. I think the TSRM changes need to be added, which could
On 16 January 2015 at 00:03, Pierre Joye pierre@gmail.com wrote:
It is also important to note that I would like to push the usage of install
from git/other VCS in the near term, using pickle, and use the website only
for the meta info but not (or much less) for hosting the releases.
As
Hi,
I've been going through some bug reports, and have found there are
several bad behaviours related to class constructors that ought to be
corrected, but could only be done at a major version. The bad
behaviours are:
Constructors returning null
---
Several classes in
On 17 January 2015 at 16:04, Rowan Collins rowan.coll...@gmail.com wrote:
The difference is that AFAIK all the exceptions returned by OOP extensions
right now are of classes specific to that extension, whereas this would be a
global engine-thrown exception.
Sorry - I wasn't clear. I didn't
On 20 January 2015 at 20:09, Marc Bennewitz dev@mabe.berlin wrote:
Pros Cons
_Named Parameters:_
pro:
- readability (If caller is not required to call as assoc array)
- not an option for inheritance
con:
- paramter skipping is a side product with possible edge cases
-
On 14 January 2015 at 21:21, Michael Wallner m...@php.net wrote:
* imagick
Most of the work was done while it was still called NG:
https://github.com/danack/imagick/tree/phpng . Which means that branch
probably won't work against master as there have been other small
changes.
btw It would be
On 22 January 2015 at 21:07, Lester Caine les...@lsces.co.uk wrote:
imagick is now available?
Not yet. I'll try to finish it off before the end of the weekend. Most
of the work was done earlier, but I need to add the changes for the
Native TLS.
btw this request to update the PHPNG upgrading
On 13 February 2015 at 23:25, Nikita Popov nikita@gmail.com wrote:
Subclassing: Should there be more specific subclasses of EngineException
for particular errors?
It's not obvious that any subclasses would be useful. However using
the code to specify the exact type of error, rather than
On 19 February 2015 at 09:54, Dmitry Stogov dmi...@zend.com wrote:
I think we may introduce the following hierarchy
the existing code that caught Exception is going to be unaffected.
We could do that. But it's not obviously correct, and ought to be
justified as to why it would be the correct
On 16 February 2015 at 22:50, François Laupretre franc...@php.net wrote:
it is clear that we don't have consensus on this topic. So, IMO, the RFC is
dead, whatever 2/3 or 3/4 we may have.
It's okay for people to disagree about things. And we have voting to
allow us to resolve those
On 17 February 2015 at 00:22, Nikita Popov nikita@gmail.com wrote:
Thank you for taking over.
I like use strict and declare as top-level only most.
That would be this no vote changed to a yes.
And I'd also like to say thank you Sara for taking over.
cheers
Dan
--
PHP Internals - PHP
On 19 February 2015 at 16:25, Dmitry Stogov dmi...@zend.com wrote:
we are tying to
do it with minimal breaks for our users. If we may keep compatibility, we
would prefer to keep it,
Yeah - you still haven't said why choosing to extend exception rather
than using an interface has fewer BC
On 19 February 2015 at 15:46, Dmitry Stogov dmi...@zend.com wrote:
Exception declares protected properties that may be used in child classes
directly.
This is not possible with interface.
So, you're saying it's easier to implement?
That isn't a fantastic way of making a language design
On 26 January 2015 at 21:06, Lester Caine les...@lsces.co.uk wrote:
I'm getting a
unknown type name ‘smart_str’ after failing to find php_smart_str.h
because my php7 build has php_smart_string.h.
Apologies - this was caused by the filename being changed in the PHP
src, and me compiling against
On 28 January 2015 at 22:50, Andrey Andreev n...@devilix.net wrote:
You're voting no because the FIG can't agree yet?
They've been discussing this for *at least* an year and iirc the first
PSR-7 coordinator gave up on it because he no longer believed in the
end result. What does that tell us?
On 25 January 2015 at 11:26, Peter Cowburn petercowb...@gmail.com wrote:
That's what the mailing list threads are for, right?
If someone has already said a reason on the list for why an RFC should
be voted no, when someone else agrees with that reason it's not common
for them to email, as it
On 31 January 2015 at 17:31, Philip Sturgeon pjsturg...@gmail.com wrote:
On Sat, Jan 31, 2015 at 3:12 AM, Matteo Beccati p...@beccati.com wrote:
2) There's a tiny bit of overlap with scalar type hints,
2) There might be some overlap in the scalar type hint stuff kinda,
but I'd like to think
Hi François,
The RFC is missing one thing if nothing else; a reason for why this
functionality would be so much better implemented in the core than in
userland code.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Levi wrote:
...and what to do with feature requests?
Stanislav Malyshev smalys...@gmail.com wrote:
if it's clear what is being asked than just leave them alone,
Would it be appropriate to close issues that are clear, but can easily
be done in userland e.g. https://bugs.php.net/bug.php?id=64639
On 16 March 2015 at 06:44, Sara Golemon poll...@php.net wrote:
The voting period for the Even More type hints reservation RFC is now open.
Hi Sara,
There's been a little bit of traffic on the list in the past few days;
I don't think your RFC has received enough cogent discussion.
In
On 15 March 2015 at 00:54, Niklas Keller m...@kelunik.com wrote:
Morning,
I'd like to announce that I'll open the vote for the in operator later that
day.
You can find the RFC here: https://wiki.php.net/rfc/in_operator
We've discussed this elsewhere and the RFC is still lacking one thing
-
Hi List,
The 'Constructor behaviour of internal classes' RFC is now in voting.
Please note, it's the coding standard that is being voted on. If
anyone thinks I've implemented the changes in a way that is less
awesome then there is no reason the changes couldn't be improved.
Additionally, while
On 15 March 2015 at 06:59, Marcio Almada marcio.w...@gmail.com wrote:
Hi,
I received some requests to update the RFC with more information about BC
breaks + possible minor adjustments regarding dynamic function calls.
Please can you stop abusing the RFC process?
This RFC is attempting to
On 16 March 2015 at 11:49, Pavel Kouřil pajou...@gmail.com wrote:
Seriously, think about it for a while - when some setting that changes
how code behaves was a good idea?
The problem is that there are two irreconcilable camps - some people
want weak STHs, other people want strict STHs.
This
On 16 March 2015 at 09:05, Xinchen Hui larue...@php.net wrote:
Hey:
I don't like strict_types at all..
And you would never be forced to use them.
But you're voting against allowing anyone else to use them. :-(
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To
On 16 March 2015 at 02:31, Marcio Almada marcio.w...@gmail.com wrote:
There was no need to update the BC break section. The only minor change was
the addition of the following section:
Yeah, really strong -1 on this one, even after the modification.
Now that the RFC only covers static
Hi Niklas,
To reiterate and explain my no vote:
The RFC is still lacking one thing
- any justification of why this deserves being a new piece of syntax,
rather than just being a function implemented either internally, or
even better in userland PHP.
The equation is not just will PHP be better
Hi Zeev,
On 11 March 2015 at 18:48, Zeev Suraski z...@zend.com wrote:
Rest assured that if I see that they both seem to be failing as we near the
end of the voting time, I'll retract the Coercive STH RFC - and I'll
actually vote in favor of the dual mode RFC,
People sometimes tell me that
Thank you Zeev.
On 16 March 2015 at 14:35, Xinchen Hui larue...@php.net wrote:
Unecessary for everybody, one or two change from no to yes will make it pass.
:)
Although not necessary, it would reduce the level of drama, which
would be a good thing.
cheers
Dan
--
PHP Internals - PHP
I dislike the lobbying, and think some of the allgeged abusive
back-channel communications are wildly out of order, but I would be
against this change.
There have been a couple of instances in the past few weeks where
someone has voted in a particular way.
When asked why they voted like that,
On 19 March 2015 at 20:26, Eric Stenson erics...@microsoft.com wrote:
PHP Internals folks--
We're doing some performance work in WinCache, and we're finding that some
frameworks
are...uh...enthusiastically using file_exists(), is_file() and is_dir()
functions on
files/directories that
On 19 March 2015 at 17:14, François Laupretre franc...@php.net wrote:
As you may have noticed if you had a look at the RFC or twitter, I have
decided to follow people's suggestion.
Please note that the switch from E_DEPRECATED to fatal error won't require
any new RFC/discussion/vote
as the
Hi Zeev,
On 19 March 2015 at 17:49, Zeev Suraski z...@zend.com wrote:
Technically, we're not allowed to move from from a working feature into a
removed one without a deprecation phase.
Please can you point me to where this is written down? Please also
show me where it says that this rule
On 15 March 2015 at 19:19, Marcio Almada marcio.w...@gmail.com wrote:
Hi
It's also going to be impossible for people to try the patch out, or
to measure it for performance hit.
Performance has never been an issue with this RFC. You probably meant bc
break not performance hit, and the
On 9 March 2015 at 11:04, David Zuelke d...@heroku.com wrote:
Why not wait with the merge until a consensus emerges regarding Throwable?
The patch for engine exceptions is large - the longer that it is left
unmerged, the more difficult it will be to do and people's time is
valuable. It also
On 11 March 2015 at 16:45, Zeev Suraski z...@zend.com wrote:
I think that going through a transition period ... that ultimately results
in one, consistent language behavior
This RFC is explicitly saying that there is stuff that will be need to
be changed in the future. Why would anyone upgrade
On 11 March 2015 at 21:44, Dmitry Stogov dmi...@zend.com wrote:
Hi,
Improvement ideas are welcome...
Hi Dmitry,
The idea was raised before of having both soft and hard limits for the
memory consumption and time limits, and to trigger a user defined
callback when the soft limit was reached.
On 14 March 2015 at 15:05, Lester Caine les...@lsces.co.uk wrote:
Just what is being added which PHP5 will actually baulk at?
The code base I will be running myself with PHP7 is PHP5.4 with E_STRICT
etc. clean code.
For the RFC https://wiki.php.net/rfc/scalar_type_hints_v5 that is on
the edge
Patrick Schaaf wrote:
But that has proven, in the past, a fountain of joy wrt.
placement, with variations needed for APC and opcache, and general frustration
all around.
Is there a bug report for the problems? OPCache shouldn't have
side-effects on the code.
cheers
Dan
On 12 March 2015 at
On 12 March 2015 at 09:58, Thomas Punt tp...@hotmail.co.uk wrote:
Hey PHP Internals,
I'm not entirely sure why
people are against it - and no one seems to want to debate it either.
I think these were covered in the discussion phase, but I will
reiterate the reasons I voted against it for
On 10 March 2015 at 15:02, Anthony Ferrara ircmax...@gmail.com wrote:
Can we please come down to a single RFC, with a single vote yes/no?
It's easier to understand, easier to manage and has less possibility
of gaming.
While I generally agree, in the case where there is a small detail
that
Voting no due to:
i) Having conversion rules be difference in userland to internal functions.
You list 'Single Mode' as a benefit of this RFC, but it's only single
mode if you gloss over this difference. This is a massive cognitive
load, and will be one of those issues that catches users out
On 29 March 2015 at 12:28, Gints Murans g...@gm.lv wrote:
What happened to this RFC? This is a really great idea for php.
The 'Skip Params' RFC (https://wiki.php.net/rfc/skipparams) went to
vote and was declined.
The 'named params' RFC (https://wiki.php.net/rfc/named_params) author
has been
Hi Dmitry,
Your approach is definitely a better one, and I have no objection to
it whatsoever.
Sorry, I was too busy to look deeply at each class but I can't see any problems.
Nikita Popov wrote:
does that mean that the same code using strict_types=1 mode will start
throwing TypeException
Hi James,
On 31 March 2015 at 21:51, James Gilliland neclim...@gmail.com wrote:
By design, \EngineException does not extend \Exception so code doesn't
accidentally catch this special type of exception. ...
I don't know if this is all acceptable and/or by design but it is awkward
so I wanted
This was approved by a vote of 32 - 1.
Dmitry said that he would like to review and possibly polish the patch
before it is committed.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
I'd like to get people's feedback for the idea of making setlocale be
either deprecated and to be removed eventually or just increasing the
warning level against people using it.
The short version of why we should do this is that setlocale breaks
things. It is a process wide operation, that
On 2 March 2015 at 14:24, Zeev Suraski z...@zend.com wrote:
https://wiki.php.net/rfc/array-to-string (which I voted yes to) deviates
from our guidelines of deprecating features first, and removing them
later;
Should we not go through this deprecation cycle, even if may feel anxious
to get
Hi Internals,
This email is to announce the formal opening of discussion for an RFC
to clean up the behaviour of the constructors shown by several
internal classes.
https://wiki.php.net/rfc/internal_constructor_behaviour
For reference this was discussed before
On 1 March 2015 at 22:05, Stanislav Malyshev smalys...@gmail.com wrote:
I'm not sure why this RFC assumes the exception is much better than
returning null.
It is a long standing tradition in PHP that operations that can be
expected to fail - like fopen().. do not produce
fatal errors but
On 1 March 2015 at 18:35, Marc Bennewitz dev@mabe.berlin wrote:
What are the reasons to not make this class instantiable / extendable ?
That class handles database state / resources that are not exposed
through the userland classes. It's correct in my opinion for it to not
be extendible or
On 26 February 2015 at 17:48, Zeev Suraski z...@zend.com wrote:
From: Theodore Brown [mailto:theodor...@outlook.com]
2. Strict types are important in some cases.
I would *want* any value with the wrong type (even a string like
26)
to be flagged as an error when passed to a function expecting
From the RFC:
Patches and Tests
Will be prepared before vote.
The implementation details may determine how some people vote. Is the
patch still coming before the voting is opened?
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On 21 February 2015 at 07:20, Markus Fischer mar...@fischer.name wrote:
On 21.02.15 06:11, Thomas Punt wrote:
From the RFC:
Also, it will make empty() more inline with the not-too-disimillar isset(),
Here I disagree.
I would have assumed from the start that empty() would only return true
On 25 February 2015 at 00:09, Pádraic Brady padraic.br...@gmail.com wrote:
Your example omitted the image validation step which would have
noticed your attempt to upload a phar immediately. Add that and try
again.
Image validation is no defense against this type of attack:
On 26 March 2015 at 20:19, Dmitry Stogov dmi...@zend.com wrote:
Hi Dmitry,
however the patch looks a bit surprising to me.
We have special function to do this - zend_ctor_make_null() and some tricks
in the VM.
I made just a quick look over your patch but didn't find any references to
them.
On 21 January 2015 at 04:39, Thomas Bley ma...@thomasbley.de wrote:
In userland it is sometimes necessary to extend PHP's notices/warnings with
additional information (e.g. username from session, stack trace, etc.)
Why can't you just use in the error handler function to write the
exact message
On 2 April 2015 at 16:01, Keyur Govande keyurgova...@gmail.com wrote:
To Rasmus's point, here's a PR for HHVM to provide a thread-safe setlocale
implementation: https://github.com/facebook/hhvm/pull/4736/files
It should be fairly easy to refactor the thread-safe-setlocale.(h/cpp) files
for
Adam Harvey wrote:
What about just adding another function: setlocale_global(), or similar?
Do you mean setlocale would become the thread safe one, and
setlocale_global() would be the current behaviour? If so, that would
be a BC break for the small number of people who are deliberately
using
On 23 April 2015 at 12:13, Mathieu Rochette math...@rochette.cc wrote:
I didn't find much information about this change (even finding about
|clear_env| is not that easy when search for php fpm env var) so I don't
know if there is others reason than BC.
It looks like it wasn't discussed that
On 30 April 2015 at 02:17, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Current PHP: Search query failure.
New PHP type hint: Fatal error because foreign key is out of PHP int range.
There may be some confusion; NikiC is still doing some work to tidy up
the EngineExceptions. When that is finished
On 16 May 2015 at 17:00, Ryan Pallas derokor...@gmail.com wrote:
Why do you want to test parse exceptions? Lint your code before you run it
and you won't have any. ... maybe I'm missing something
obvious,
Yeah, there's been a misunderstanding. I'm not talking about wanting
to test whether my
Hi Christopher,
On 15 May 2015 at 23:14, Christoph Becker cmbecke...@gmx.de wrote:
Hello internals,
today I have been pointed to bug #60982[1], which appears to be an
unpleasant limitation.
It sure is!
I wonder why the GC is not triggered when the memory limit is exhausted,
To hopefully
On 15 May 2015 at 14:38, Xinchen Hui larue...@gmail.com wrote:
Hey:
as described in https://bugs.php.net/bug.php?id=69640thanks=1
instead of fixing it by exam the error type, I'd prefer to
disallow initializing a engine exception from user land..
How would that work when people
On 15 May 2015 at 17:12, Xinchen Hui larue...@gmail.com wrote:
How would that work when people want to write unit/integration tests
to test the behaviour of a module when an EngineException is thrown?
If you can't create a certain type of exception, it would mean that
some code is basically
Hi Johannes,
On 13 April 2015 at 13:37, Johannes Ott m...@deroetzi.de wrote:
Hi,
finally I managed to do my first RFC draft.
https://wiki.php.net/rfc/static_class_constructor
I hope I have done everything correct so far and I'm looking forward to
your feedback on it.
Here is some
On 14 April 2015 at 17:39, Johannes Ott m...@deroetzi.de wrote:
Am 14.04.2015 um 16:33 schrieb Dan Ackroyd:
Here is some feedback then:
Johannes Ott wrote:
But in the new draft (v0.4) I'm preparing at the moment I'll try to
formulate the trigger first call more common by comparing
On 1 April 2015 at 18:27, Marc Bennewitz dev@mabe.berlin wrote:
Functionality not related to locale should not be effected by this global
This is issue is that that the locale affects all of the C library
that use it, which includes printf();
- The following bug reports are valid bugs and
On 1 April 2015 at 18:58, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
Stanislav Malyshev wrote:
Library should not assume it runs in C locale,
Because it is not thread-safe, it is not safe for libraries to alter the locale.
I can't see any workaround to make this 'just work' - when
Hi Julien,
I am unsure of the timing windows for things being committed to being
in a release, but it seems unfortunate to not have this included:
https://github.com/php/php-src/commit/86f983bd3ea13def42e36842e03f785d02d40a7f
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
Ferenc Kovacs wrote:
this would also eliminate
the confusion, that something is present in 5.6.27 but not in
5.5.40(because 5.6.27 was released after 5.5.40, and this new stuff will
land in 5.5.41).
I think the solution to this is pretty clear, as Rowan put it:
Rowan Collins wrote:
- Once a
On 19/05/2015 00:07, Christoph Becker wrote:
What happens if the soft limit is exhausted, but the GC can free only a
little memory? That might trigger the GC shortly afterwards again and
again.
The usual way to stop this sort of flapping is to set the point at
which the alarm gets reset to be
On 19 May 2015 at 14:28, Rowan Collins rowan.coll...@gmail.com wrote:
Dan Ackroyd wrote on 19/05/2015 14:08:
* When gc_collect_cycles is called (and potentially other functions),
at the end of that function check whether the amount of memory being
used is less than reset level for each
On 15 May 2015 at 14:38, Xinchen Hui larue...@gmail.com wrote:
I'd prefer to
disallow initializing a engine exception from user land..
like if you try to initialize a engine/type/parser exception, an E_ERROR
of:
what do you think?
Someone reminded me that TypeExceptions are almost
1 - 100 of 622 matches
Mail list logo
