On 11/24/2015 05:47 PM, Andrea Faulds wrote:
Can this be fixed for 7.0.0?
I sure hope so.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 11/24/2015 04:42 PM, Theodore Brown wrote:
The difference is that DateTime and \DateTime mean different things inside a
namespace.
int and \int always mean the same thing, so it seems confusing to allow the
latter syntax
as if it means something different.
That. And the fact that DateTime
On 11/24/2015 04:27 PM, Ryan Pallas wrote:
Also, this is the only way to get some IDEs to recognize the type when in a
namespace (at least currently).
Then the IDEs have to be fixed.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
The following is currently valid PHP 7 code
http://www.php.net/unsub.php
On 11/23/2015 10:10 PM, Anatol Belski wrote:
c) do RC8, release on 3rd, expect there are no bugs come in
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 11/16/2015 04:15 AM, Chris Riley wrote:
Any thoughts?
Would love to have it for implementing value objects.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 11/13/2015 04:35 PM, Stephen Coakley wrote:
This is quite similar to Python's ability to execute Python scripts
compiled to bytecode as *.pyc files. The feature has seen great success in
Python, mostly for distributing releases of software or deploying to a
server.
Correct me if I'm wrong,
On 11/08/2015 02:45 PM, Stanislav Malyshev wrote:
I think this is the right thing to do, we can wait for a bit if it means
better stability.
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 10/13/2015 04:59 PM, Anthony Ferrara wrote:
> Overall, I don't think this should be ported back to 5.x
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 22.09.2015 um 12:38 schrieb Stig Bakken:
> The point I'm trying to make is that an enum's normalized
> representation should be an integer, and that is also how it should be
> serialized.
Makes sense to me.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
Am 19.08.2015 um 16:09 schrieb Niklas Keller:
> TBH, I'd rather take the time and have a delayed release without a hurry
> than shipping a final version with unresolved problems. Having a schedule
> to follow is nice, but you should rethink the schedule when problems arise
> instead of following it
Am 18.08.2015 um 19:07 schrieb Anatol Belski:
> Do you have some impregnable issue in mind preventing to do this?
Hm, maybe: what about the need for set_throwable_handler() that was
recently raised as a topic?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
Am 18.08.2015 um 19:07 schrieb Anatol Belski:
> Do you have some impregnable issue in mind preventing to do this?
No, I was just surprised. Must have missed the announcement.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 18.08.2015 um 16:06 schrieb Anatol Belski:
> Diff:
> diff --git a/configure.in b/configure.in
> index 8907852..033c754 100644
> --- a/configure.in
> +++ b/configure.in
> @@ -120,7 +120,7 @@ int zend_sprintf(char *buffer, const char *format, ...);
> PHP_MAJOR_VERSION=7
> PHP_MINOR_VERSION=0
>
Am 17.08.2015 um 16:00 schrieb Derick Rethans:
> Actually, I don't call this intended. This is just as much as a BC break
> as the original implementation where Errors where also Exceptions. IMO,
> set_exception_handler() should be changed - with my preference it not
> capturing Error, and inste
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/28/2015 05:22 PM, Johannes Schlüter wrote:
> An approach might be to remove the automatic download and
> instructing the user to put the file there manually if this is seen
> as important.
+1
--
PHP Internals - PHP Runtime Development Maili
On 07/28/2015 04:45 PM, Johannes Schlüter wrote:
> (and yes - developers doing this might be an interesting targeted
> attack vector. Malicious code there knows where the developer keeps
> the source tree and might inject bad code into the codebase which we
> notice only with good review of commits
Am 11.07.2015 um 19:53 schrieb S.A.N:
> It will be useful for autocomplete in IDE
That argument is bogus since proper IDEs (PhpStorm, fex.) leverage
docblock annotations for that already.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.ph
On 06/19/2015 05:46 PM, Rasmus Lerdorf wrote:
> I think this is a symptom of doing deploys incorrectly.
You are right, of course. Thank you for pointing out this layer 8
problem :-) No clue why I did it different (read: stupid) for a
private project when I know better. Oh, well.
--
PHP Intern
Scenario: nginx + PHP-FPM / FastCGI.
The final step of the deployment is updating a symlink to point to the
new version.
For N <= realpath_cache_ttl seconds after the deployment, some
filesystem operations fail because of outdated realpath cache entries.
Is there a way to signal the PHP-FP
Am 17.06.2015 um 23:30 schrieb Anthony Ferrara:
> Instead, I think we should solve the problem with education. Perhaps
> the documentation can better detail out why devs shouldn't directly
> throw exception but instead use typed exceptions...?
I remember "all hell breaking lose" when I disallowed
Am 16.06.2015 um 18:10 schrieb Ferenc Kovacs:
> did not have more time to test though, so any feedback is appreciated.
I still think that the right solution would be to simply not bundle /
install PEAR anymore.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
Am 14.06.2015 um 07:55 schrieb Xinchen Hui:
> maybe related to this : 3cfa58367b1b85d346d9be6cf9ae116c63571247
Yes, reverting that commit fixes it. Thanks for the pointer!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 14.06.2015 um 07:29 schrieb Sebastian Bergmann:
> I have run across a weird segfault with the current master when trying
> to run PHPUnit (using PHPUnit's own test suite). Weird because I get a
> segfault immediately on startup with a release build and a segfault much
> later w
7773f0 in php_execute_script ()
#31 0x00868751 in do_cli ()
#32 0x00440d9b in main ()
$ /home/sb/php-7-debug phpunit
PHPUnit 5.0-gabce26e by Sebastian Bergmann and contributors.
Runtime: PHP 7.0.0-dev
Configuration: /usr/local/src/ph
Am 31.05.2015 um 13:02 schrieb Xinchen Hui:
> yeah, PHP knows, but only in lowercase
> it's not the right thing we need..
Better the right name in lowercase than the wrong name, no? :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.p
On 05/29/2015 08:59 AM, Xinchen Hui wrote:
> Actually, I had looked it, but there is no such Infos can be
> used after compiling is done in current traits design, so
But calling C::bar() works, so PHP knows that there is a method named
"bar". Yet the Reflection API says that two methods nam
Would be nice if somebody could have a look at
https://bugs.php.net/bug.php?id=69180 -- thanks!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 05/17/2015 12:15 AM, Stanislav Malyshev wrote:
> Where is it? I'd like to see it.
https://github.com/php/php-src/pull/1284
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 05/16/2015 10:57 PM, Stanislav Malyshev wrote:
> I am assuming we have broad consensus about the move from BaseException
> to Throwable. I've looked at the patch at
> https://github.com/php/php-src/pull/1282 and it seems pretty close to
> what we want to me. The only difference is that
> https:/
Am 13.05.2015 um 08:30 schrieb Pierre Joye:
> Why don't you do it? You have access and you are a very good writer.
> No big C knowledge required either in this case :)
There was/is consensus on what I proposed back in February:
* Introduce a Throwable interface
* Let Exception implement th
Am 13.05.2015 um 08:30 schrieb Pierre Joye:
> Why don't you do it? You have access and you are a very good writer.
> No big C knowledge required either in this case :)
TBH, until know I did not think I would be capable of doing it
myself. I'll look into it now.
--
PHP Internals - PHP Runtime D
Am 13.05.2015 um 07:40 schrieb Stanislav Malyshev:
> I can, except that I'm pretty busy right now. But probably will have
> some time on the weekend, so I've put it on my todo list.
Thanks!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.p
Am 09.05.2015 um 06:38 schrieb Stanislav Malyshev:
> OK, if there's consensus we can go forward with this, then let's just do
> that ASAP.
Can you implement this? Thanks!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 01.05.2015 um 07:08 schrieb Pierre Joye:
> Let do a rfc to accept to post pone features freeze with a list or a single
> RFC.
Do you volunteer to draft that RFC?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 30.04.2015 um 14:30 schrieb Julien Pauli:
> We could make an exception (sic !) and add the Throwable interface to PHP7,
> even after feature freeze, because it is an easy pick and having a clear
> Exception model for 7.0 is to my opinion very important.
+1, couldn't agree more.
--
PHP Intern
Am 30.04.2015 um 02:50 schrieb Stanislav Malyshev:
> I like the idea, however we do have the deadline and the
> deadline has been passed. So I wonder if we can't keep it for 7.1
That means introducing a change in 7.0, changing it and deprecating
part of it in 7.1, and removing said part in 7.2/8
Am 21.03.2015 um 18:05 schrieb Sebastian Bergmann:
> The vote for this missed the boat for the PHP 7 deadline. However, if
> we really want to do this we should do it in PHP 7 or not at all (at
> least not for a long time) due to BC breaks.
>
> Thoughts?
ping
--
PHP Internal
Am 15.03.2015 um 08:27 schrieb Sebastian Bergmann:
It was my idea, after all, only fair that I invest the time to make
it into an RFC: https://wiki.php.net/rfc/throwable
The vote for this missed the boat for the PHP 7 deadline. However, if
we really want to do this we should do it in PHP 7
Am 15.03.2015 um 09:24 schrieb Pavel Kouřil:
why global namespace?
Because that is where, as of today, built-in classes, interfaces,
functions, etc. go.
The introduction of a PHP namespace, for instance, would be the topic
of a separate RFC.
--
PHP Internals - PHP Runtime Development Mai
Am 16.03.2015 um 07:41 schrieb Xinchen Hui:
> what is the link problems?
http://pastebin.com/Tk1kaipQ
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 15.03.2015 um 16:36 schrieb Sebastian Bergmann:
> Over in Room 11, Michael just pointed out that this could be related
> to php_stdint.h.
Okay, this does not seem to be related to the GCC version but rather
to the fact that some int types etc. are not defined on/for my platform.
If
Am 15.03.2015 um 15:34 schrieb Sebastian Bergmann:
> I am asking because using GCC 2.95.3 and GCC 3.4.0 I get errors related
> to the usage of intptr_t (see http://pastebin.com/9Gn0AAXA).
Over in Room 11, Michael just pointed out that this could be related
to php_stdint.h.
--
PHP Int
What is the minimum version of GCC required to build PHP?
I am asking because using GCC 2.95.3 and GCC 3.4.0 I get errors related
to the usage of intptr_t (see http://pastebin.com/9Gn0AAXA).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsu
Am 15.03.2015 um 08:07 schrieb Sebastian Bergmann:
> So who will draft the RFC for
>
>* Introduce a Throwable interface
>* Let Exception implement the Throwable interface
>* Introduce an Error class that implements the Throwable interface
>* Use Error class
Am 27.02.2015 um 15:47 schrieb Jordi Boggiano:
> quickly draft another RFC to amend that part
So who will draft the RFC for
* Introduce a Throwable interface
* Let Exception implement the Throwable interface
* Introduce an Error class that implements the Throwable interface
* Use Err
Am 09.03.2015 um 12:40 schrieb Dan Ackroyd:
> So even though I hope we can clean up the exception hierarchy, merging
> the engine exceptions is the right choice imo.
Sounds reasonable to me. I'm wondering, though, whether we really need
an additional RFC for the change I suggested as nobody spok
Am 09.03.2015 um 09:44 schrieb Matteo Beccati:
> I like the approach. I'm no lexer expert but the new PR seems much nicer.
> Moreover, I like the feature itself but previously voted no on the
> implementation. I've therefore switched my vote to a "yes".
Dito.
--
PHP Internals - PHP Runtime Deve
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
> Voting is open until 2015-03-08.
Voting ends today and it looks like the RFC will be accepted. How
should we proceed with regards to the comments I made in
Message-ID: <54f07fc7.8050...@php.net>
Date: Fri, 27 Feb 2015 15:31:35 +0100
Guilher
Am 04.03.2015 um 09:52 schrieb Nikita Popov:
> So, tl;dr: I think the patch is too risky. Even if we can make sure that
> we've covered all the current edge-cases and don't regress anything, I'm
> afraid that this will cause complications with future changes. This ends up
> replicating too many par
Am 28.02.2015 um 01:57 schrieb Larry Garfield:
> The RFC is currently in voting, so editing it directly is a no-no. A new,
> short RFC, please. (Exception implements Throwable, Error implements
> Throwable sounds good to me. Should we ask about SomeUserspaceClass
> implements Throwable, or will
Am 27.02.2015 um 01:29 schrieb Matthew Weier O'Phinney:
> - PHPUnit passes a boolean false to `debug_backtrace()`... which is documented
> as expecting an integer! (There are actually several constant values it
> accepts, all of which are integer values.) In this case, PHPUnit is relying
> on
Am 27.02.2015 um 16:12 schrieb Anthony Ferrara:
> Thank you for sharing your code. I look forward to playing with it.
>
> Perhaps after 7 stabilizes (and ships) you could write up your
> thoughts around it? Why decisions were made and the findings that you
> have?
What Joe and Anthony said :-) T
Am 23.02.2015 um 19:15 schrieb Nikita Popov:
> Voting on the engine exceptions RFC, which proposes to convert existing
> fatal and recoverable fatal errors into exceptions, has opened:
>
> https://wiki.php.net/rfc/engine_exceptions_for_php7#vote
>
> The primary vote requires a 2/3 majority, a
Am 27.02.2015 um 09:53 schrieb Xinchen Hui:
> I noticed different version of xdebug, could you try without it?
Thank you for bringing Xdebug to my attention. You are right, it
appears to be related to Xdebug.
Without Xdebug
$ php -v
PHP 5.6.6 (cli) (built: Feb 19 2015 09:44:29)
Copyr
Am 27.02.2015 um 09:30 schrieb Xinchen Hui:
> maybe related to your own build?
The test in the PHPUnit test suite fails with
PHP 5.6.6 (cli) (built: Feb 19 2015 09:44:29)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
with Xdeb
Am 27.02.2015 um 09:14 schrieb Remi Collet:
> Hmmm http://3v4l.org/QST64
No clue why PHP 5.6.5 seems to have worked for that reproducing script
here earlier. Tried it again and, of course, it also fails with "my"
PHP 5.6.5.
Looks the like the reproducing script was not the right one. :-/
--
While working on PHPUnit today I noticed one test of its own test
suite failing on PHP 5.6.6 that passes on PHP 5.6.5. The details of
this can be found at
https://github.com/sebastianbergmann/phpunit/issues/1630
Florian Margaine reduced the problem to the following minimal,
self-contained
Am 17.02.2015 um 10:51 schrieb Lester Caine:
> It seems not even running distclean clears down everything that needs
> removing for some of the changes currently going through. ./vcsclean
I stopped using distclean / vcsclean a while ago. "git clean -xdf"
does the trick for me.
--
PHP Internals
Am 09.02.2015 um 15:50 schrieb Pierre Joye:
> Not strict? You loose me here.
I want support for scalar types in signatures. I want these type
declarations to be strictly enforced. This is not wanted and not
proposed by the RFC. Hence my vote.
--
PHP Internals - PHP Runtime Development Mailing
Am 07.02.2015 um 02:08 schrieb Sebastian Bergmann:
> After reading your email, Nikita, I deleted my vote (it was no before).
> I will review the RFC again, with your arguments (and others) in mind
> and maybe I'll come to a different conclusion.
I have voted (no) again.
I still
On 02/06/2015 10:22 PM, Nikita Popov wrote:
> After much initial reluctance, I've voted in favor of this RFC.
After reading your email, Nikita, I deleted my vote (it was no before).
I will review the RFC again, with your arguments (and others) in mind
and maybe I'll come to a different conclusi
On 02/04/2015 04:32 PM, Dan Ackroyd wrote:
> btw For your exact example `sin((float)$x).` this is actually a case
> where another scalar type of 'number' which is satisfiable by either a
> float or an int would be useful, but that's definitely a step too far
> before we have any scalar type hints.
Am 04.02.2015 um 10:25 schrieb Dmitry Stogov:
> Do you like the proposal with declare() switch?
No, I do not like that.
We are talking about adding support for scalars (string, integer, ...)
to the list of optional type declarations already supported (array,
callable, interface name, class na
Am 04.02.2015 um 08:25 schrieb Dmitry Stogov:
> The idea of that RFC was an ability to have zero-cost assert().
But an assert() is still in the body of a function or method and
not part of its signature. That is what I want scalar type
declarations for.
--
PHP Internals - PHP Runtime Develop
Am 04.02.2015 um 06:44 schrieb Dmitry Stogov:
> What do you think about using only lowercase type names for scalar type
> hints? In this case we won't have to introduce any limitations.
This would be inconsistent with the rest of PHP being case-insensitive
and only lead to confusion.
--
PHP I
Am 27.01.2015 um 21:13 schrieb Pierre Joye:
> However there is one thing we do need to care, and this is 3rd party
> extensions. This is all I care about and why I initiated pickle.
It just that I am not convinced that the problem you are trying to solve
with a tool such as pickle exists. From m
Am 27.01.2015 um 10:52 schrieb Lester Caine:
> On 27/01/15 09:42, Sebastian Bergmann wrote:
>> PEAR has served its purpose, it provided value for the PHP
>> ecosystem for a time, but now it should be retired.
>
> So what happens to http://pear.php.net ?
That is a good q
Am 27.01.2015 um 10:00 schrieb Lester Caine:
> composer has not even managed to get added to some distributions yet
This is not about PEAR Installer vs. Composer or something else. This
is about the PHP core getting untangled from third-party software that
impedes the development of PHP itself.
Am 27.01.2015 um 07:40 schrieb Matteo Beccati:
> The warning is certainly annoying, but making it default to UTC or a wrong
> timezone because the right one can't be guessed is a major WTF.
Couldn't agree more; -1 for removing the warning.
--
PHP Internals - PHP Runtime Development Mailing List
Am 26.01.2015 um 18:03 schrieb Ferenc Kovacs:
> imo we can't ship php without a tool to install additional pecl
> extensions.
I disagree and would argue that most people do not want to build
extensions themselves and instead prefer binary packages provided by
their OS distribution.
But even i
Am 26.01.2015 um 13:56 schrieb Lester Caine:
> how would YOU propose to replace it?
I am not talking about replacing but removing.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 26.01.2015 um 13:51 schrieb Ferenc Kovacs:
> and bundling our own installer is only temporary, as I mentioned in the PR
> probably there will be more BC breaks until php7 is frozen, and it would
> be clunky if we have to always wait for the official PEAR release so that
> the pear installer of t
Am 26.01.2015 um 11:31 schrieb Tony Marston:
>> PHP 7 would be a good time to cut the ties between the PHP core
>> and PEAR. Why not get rid of it completely?
>
> Because a lot of sites still use it, and you haven't provided an
> alternative which allows modules be to added/updated/deleted through
Am 26.01.2015 um 11:14 schrieb Ferenc Kovacs:
> Commit:cfd7f5c8a3745097e0c3c3e627f6df10f2a2acdf
> Author:Ferenc Kovacs Mon, 26 Jan 2015 11:09:53
> +0100
> Parents: 8aa146b810108bde3353d9d2f8cf05a9dd012f6d
> Branches: master
>
> Link:
> http://git.php.net/?p=php-src.git;
Am 25.01.2015 um 17:17 schrieb Andi Gutmans:
> Can you provide more info re: operating system and version?
> Compiler version?
$ cat /etc/issue
Fedora release 21 (Twenty One)
$ clang --version
clang version 3.5.0 (tags/RELEASE_350/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix
Nut sure whether this is an issue or not but I see it a lot while
compiling master:
Zend/zend_alloc.h:57:236: warning: unknown attribute 'alloc_size'
ignored [-Wunknown-attributes]
__attribute__ ((visibility("default"))) void* _emalloc(size_t size,
const char *__zend_filename, const
Am 22.01.2015 um 18:05 schrieb Rasmus Lerdorf:
> It would be really useful if we got more eyes on this. Install php7,
> then install any random app and see how it goes.
It's even easier to check whether a component or framework has issues
with PHP 7: simply run the respective test suite with PHP
Am 21.01.2015 um 20:39 schrieb Rasmus Lerdorf:
> Log:
> Slightly modify and merge PR#105 from @MegaManSec
>
> Bugs:
> https://bugs.php.net/105
I think the commit email script needs to be updated to handle PR#NNN
"links".
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Am 19.01.2015 um 17:42 schrieb Tony Marston:
> has already been pointed out that there are a large number of PEAR
> libraries which were written with PHP 4 constructors and have never been
> updated.
So? If that code is still valuable to people they will update it. Or
rather would have updated i
Am 19.01.2015 um 07:58 schrieb Stanislav Malyshev:
> Can't we just fix it? As I understand, it's just making this:
>
> function initializeConfig(&$config)
>
> into this:
>
> static function initializeConfig(&$config)
>
> In PEAR/Installer/Role.php but I'm not sure where to commit the pa
Am 19.01.2015 um 10:49 schrieb Dmitry Stogov:
> Despite of PEAR, I also found few other apps, from my usual test list,
> broken - Typo3, Xoops, SugarCRM.
> Magento is broken long time ago by "unified variable syntax".
The vendors of these applications have time to become compatible
with PHP 7 un
Am 19.01.2015 um 10:49 schrieb Dmitry Stogov:
> Despite of PEAR, I also found few other apps, from my usual test list,
> broken - Typo3, Xoops, SugarCRM.
> Magento is broken long time ago by "unified variable syntax".
The vendors of these applications have time to become compatible
with PHP 7 un
Am 18.01.2015 um 09:40 schrieb Matteo Beccati:
> what's the plan, if any?
Remove it?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 17.01.2015 um 15:02 schrieb Dan Ackroyd:
> class constructors
PHP does not have class constructors (static method automatically
invoked when a class is initialized). It only supports object
constructors (method automatically invoked when an object is
created).
> Several classes in PHP
Am 11.01.2015 um 09:03 schrieb Ferenc Kovacs:
> There is https://github.com/nikic/php-ast
Aha! Thanks for the pointer, Ferenc. Can we get this bundled with
PHP 7 (and enabled by default)?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.ph
Am 25.08.2014 um 19:39 schrieb Nikita Popov:
> I don't know if I will be implementing that ext myself. In any case, before
> that can happen I will have to create another RFC for converting parse
> errors into exceptions and making sure we don't leak memory on failed parse
> - I think thats a prere
Am 31.12.2014 um 21:27 schrieb Andrea Faulds:
> Parameter type hints for PHP’s scalar types
Please use the term "type declaration for arguments" (or "type
declaration for parameters") instead of "type hints". If it's used
then it's not a hint.
--
PHP Internals - PHP Runtime Development Maili
Am 27.12.2014 um 16:01 schrieb Kalle Sommer Nielsen:
> bugs going as far back as to PHP4.
Bug reports for PHP version that are not supported anymore [1]
should IMHO be bulk-closed. The message should ask to reopen if
the bug is reproducible with a supported version of PHP. IMHO :)
--
[1] htt
Am 17.12.2014 um 15:54 schrieb Zeev Suraski:
> I’m opposed to having a 5.7 release that has new features on
> top of 5.6.x.
Same here; 5.7 should only add deprecations etc. and must not add new
features.
> I also think we should minimize any new work on 5.6.x as much as
> possible, and focus al
Am 14.12.2014 um 19:35 schrieb Andrea Faulds:
> Thoughts?
+1 for consistency :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 12.12.2014 um 09:47 schrieb Julien Pauli:
> In the worst scenario, there is also: downgrade your Bison.
I have done that for now, of course. What worries me is the reliance
on outdated and unsupported tools.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
$ git status
On branch PHP-5.6
Your branch is up-to-date with 'origin/PHP-5.6'.
nothing to commit, working directory clean
$ ./configure --disable-all
.
.
.
Thank you for using PHP.
config.status: error: cannot find input file: `php7.spec.in'
$ git status
On branch PHP-5.6
Your bran
Hi!
I just updated my notebook to Fedora 21 and am no longer able to
build PHP on it since I now have bison 3.0.2 instead of bison 2.7.
bison 3.0 is blacklisted in Zend/acinclude.m4. Is bison 3.0
incompatible with our parser specification? If so, will it be
upgraded? It's not really a good
On 10/28/2014 03:35 AM, Trevor Suarez wrote:
> Great job on this Adam. You whipped this up pretty quickly and it looks
> good!
I second that emotion: great work, Adam! Thank you for your work!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsu
On 10/27/2014 10:48 AM, Andrea Faulds wrote:
> We should copy it.
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 10/27/2014 10:45 AM, Peter Cowburn wrote:
> The closest we have, at the moment, is probably http://php.net/eol.php
> which details the versions which are no longer supported.
We need the inverse of that :)
> Good question.
Should we start http://php.net/supported-versions.php then?
--
PHP
Hi!
Do we have a page that lists the versions of PHP that are currently
supported and when their support expires? If not, why not?
What I am looking for is basically a page that lists the information
shown in the examples used in https://wiki.php.net/rfc/releaseprocess
Thanks!
Sebastian
-
Am 25.10.2014 um 20:20 schrieb Stas Malyshev:
> somewhat relaxed rules there, but even then introducing new debugging
> protocol into PHP core seems to be something that warrants some
> notification.
That would have been my next question. I think it does not only
warrant notification but adheren
Am 25.10.2014 um 13:00 schrieb Weinand Bob:
> It’s known that all the development currently is going on in
> krakjoe/phpdbg github repo.
Why is that, exactly? I find it weird that something that is shipped
with official releases of PHP is not developed alongside the rest of
PHP.
--
PHP Inter
201 - 300 of 1233 matches
Mail list logo
