Hello,
There came up another idea/issue about the Phar extension and its
native SSL support.
As you might know or not, when building PHP:
./configure --with-openssl --enable-phar
the Phar extension will get so-called native SSL enabled through
OpenSSL directly. However, when built like this:
.
On Mon, 26 Aug 2024 at 20:05, Calvin Buckley wrote:
> As such, it might be a bit tricky for people on Windows/AIX; the easiest
> solution if PHAR is using the openssl extension's symbols would be to not
> build the openssl extension as shared.
I've just checked Windows build and the PHP downloade
On Wed, 4 Sept 2024 at 15:07, Christoph M. Becker wrote:
>
> Hi all,
>
> that issue came up the other day on a pull request[1], but since it is
> not particularly related to any single PR, I wanted to ask here for
> clarification.
>
> This is about changes to `./configure` options of php-src, and
On Wed, 12 Apr 2023 at 15:53, Alex Wells wrote:
>
> Hey.
>
> PHP currently uses internals@lists.php.net for communication. That includes
> mostly RFCs (or their votings, or their pre-discussion) and sometimes
> questions about the implementation or possible bugs.
>
> While emailing definitely work
On Fri, 28 Apr 2023 at 12:01, Jakub Zelenka wrote:
>
> Hi,
>
> The vote is now open for the RFC about introduction of the PHP Technical
> Committee:
>
> https://wiki.php.net/rfc/php_technical_committee
>
> Regards
>
> Jakub
It would be also good to know why people vote no.
--
PHP Internals - PH
On Tue, 11 Jul 2023 at 13:37, Levi Morrison wrote:
>
> On Sun, Jul 2, 2023 at 6:11 PM Levi Morrison wrote:
> >
> > Chatter on the [Interface Default Methods RFC][1] has been quiet for
> > the past 6 days, and the feature freeze deadline is fast approaching
> > for PHP 8.3, so I'm moving this to v
On Mon, 14 Aug 2023 at 16:18, G. P. B. wrote:
> Hello internals,
>
> While working on some DNF type bugs, I discovered some major issues around
> the disable_classes INI setting implementation. Such as:
>
> - A double-free of the type of a typed property
> - A use after free (which segfaults) whe
On Tue, 5 Sept 2023 at 11:40, Hanz wrote:
> Hello,
>
> Ran into a couple of issues with RC1 that I haven't seen online.
>
> With --with-pear: The --with-pear option is deprecated
>
> With --enable-pear: configure: WARNING: unrecognized options: --enable-pear
>
> I'm using --disable-all as the fir
On Thu, 2 Nov 2023 at 05:02, Christopher Jones
wrote:
>
> On 2/11/2023 2:46 am, Derick Rethans wrote:
> > Hi,
> >
> > I have just opened voting on the RFC to unbundle imap, pspell, and
> > oracle integrations.
>
> :)
>
> --
> https://twitter.com/ghrd
>
> --
> PHP Internals - PHP Runtime Developme
On Mon, 12 Feb 2024 at 12:13, Ilija Tovilo wrote:
>
> Hi Yuya
>
> It seems you accidentally sent your response to me instead of the list.
>
> On Sun, Feb 11, 2024 at 5:10 PM youkidearitai wrote:
> >
> > 2024年2月11日(日) 21:18 Ilija Tovilo :
> > >
> > > Hi everyone.
> > >
> > > I would like to start
On Tue, 5 Mar 2024 at 01:27, wrote:
>
> > The VSC part from github (hosting our code), can very easily be ported.
> > Issues, discussions etc can not.
> >
> > With the ongoing enshittification of most of the Internet due to
> > advertising and tracking, we'd be negligent not hosting and owning o
On Tue, 26 Mar 2024 at 06:41, youkidearitai wrote:
>
> Hi, Internals
>
> Sorry I mistake.
> Send again.
>
> grapheme_str_split going to "Voting" phase.
> Vote end is 10th April 00:00 GMT
>
> Regards
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.inf
Hello,
I was wondering if it would be useful to add GitHub milestones for the
PHP-8.4 and PHP-9.0 (or PHP-next or something like this)?
https://github.com/php/php-src/milestones
Because some pull requests might target versions after the PHP-8.4 and it
might be useful to have them additionally sor
Hello,
we're thinking of bumping the minimum PostgreSQL version supported by PHP from
current version 9.1 to version 10.0:
https://github.com/php/php-src/pull/14540
A list of PostgreSQL versions and their EOL dates can be seen at
https://en.wikipedia.org/wiki/PostgreSQL
The versions coverage by
On Mon, 17 Jun 2024 at 18:58, Pierre wrote:
>
> Would id affect the possibility to use an old PostgreSQL (eg. 9.6) via
> PHP (PDO or ext-pgsql) ?
>
> If so, it might be a dangerous move for oldest projects, you sometime
> can upgrade PHP and your software easily, but can't upgrade the database
> s
On Mon, 17 Jun 2024 at 19:16, Matteo Beccati wrote:
>
> Hi,
>
> Il 17/06/2024 19:03, Peter Kokot ha scritto:
> > On Mon, 17 Jun 2024 at 18:58, Pierre wrote:
> >>
> >> Would id affect the possibility to use an old PostgreSQL (eg. 9.6) via
> >> PHP (PDO
Hello,
Perhaps you're not aware that the PHP build system currently still
supports building apache2handler SAPI for Apache 2.0 and 2.2 branches.
Apache 2.2 has been marked as EOL in December 2017 and doesn't receive
security patches. Also, most Linux distributions and packages mostly
support 2.4 a
Hello,
There is another pull request in preparation that I'd like to squeeze in
the PHP-8.4 branch if it will possible to wrap it up until the feature
freeze milestone:
https://github.com/php/php-src/pull/13755
In short, pkg-config is *nix command line utility to query installed
libraries on the
On Thu, 18 Jul 2024, 16:32 Ilija Tovilo, wrote:
> Hi Christoph
>
> On Thu, Jul 18, 2024 at 2:09 PM Christoph M. Becker
> wrote:
> >
> > So I suggest to sync CODEOWNERS for all active branches (and maybe even
> > security branches).
> >
> > What do you think?
>
> I think back when it was introduc
On Mon, 5 Aug 2024 at 19:15, Christoph M. Becker wrote:
> But what about other compilers we support on non Windows platforms
> currently, like clang, Apple's clang, Solaris Studio and maybe some more
> we don't even know about.
Might be worth noting here that from what I've tested so far that PHP
On Tue, 13 Aug 2024 at 01:57, Juliette Reinders Folmer
wrote:
>
> Hi all,
>
> I suppose everyone is aware of 3v4l.org and a lot of us use it on a regular
> basis.
>
> 3v4l also auto-builds the PHP "master" branch every night to allow for
> testing with the latest and greatest PHP version and com
no commit.
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
+1 Yes, please...
For a better overview of these:
https://github.com/php/php-src/branches/stale?page=12
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 18 Feb 2019, 23:39 Legale.legale I have made super simple OS independent phpenmod.
>
> Https://github.com/legale/phpenmod
> On Feb 18, 2019 23:31, Gabriel Ostrolucky wrote:
> >
> > I'm fan of this idea. I miss this in any other non-debian distro.
> > What nobody mentioned yet, similar scr
ult functionality of echo in
PHP is like changing left-hand traffic countries to use right-hand
traffic. A new function name would be needed for that. You can start
with creating an extension for this... But with this level of
communication? Hm...
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ers
> Joe
>
> On Wed, 6 Mar 2019 at 10:39, Kalle Sommer Nielsen wrote:
>
> > Den ons. 6. mar. 2019 kl. 11.03 skrev Nikita Popov :
> > >
> > > On Wed, Mar 6, 2019 at 6:20 AM Sebastian Bergmann
> > wrote:
> > >
> > > > Am 06.0
Hello,
On Tue, 12 Mar 2019 at 10:51, Rowan Collins wrote:
>
> On Mon, 11 Mar 2019 at 20:06, G. P. B. wrote:
>
> > From my understanding, the ` > so maybe we should deprecate PHP's short tag altogether?
> >
>
>
> I think when that's been proposed in the past, people have said they like
> it for us
On Tue, 12 Mar 2019 at 12:15, Alexandru Pătrănescu wrote:
>
> Hi,
>
> I guess that `short_open_tag` ini settings can be deprecated/removed.
> But that would mean that short open tags will be always available, not that
> it will be removed.
>
> Regards,
> Alex
Oh, the main idea is to remove the in
ttp://www.php.net/unsub.php
>
In reality if developer wants to write "portable" and proper PHP code,
no one actually should use these short tags anymore. If they are still
used somewhere as part of some legacy code, they won't work on
majority of PHP installations anymore because th
hout
opening tag might go through also. After all, text files are simple.
Something on this was already being done and probably also discussed:
https://wiki.php.net/rfc/nophptags
On the other hand, shebangs will still be present in CLI scripts. For example:
#!/usr/bin/env php
--
Peter Kokot
--
ould be also about removing deprecated functionality. This
approach is actually following semver https://semver.org, so that's
all good I think.
In any case if we will need to wait more than another year or not,
thank you for your great work. Thumbs up. :)
--
Peter Kokot
--
PHP Internals - PHP
oving deprecated usage from their code and move to
something else. Not that they will have an option to install it over
PECL in PHP 8.0... Is this ok approach for this case? Because with
this approach PHP is also saying quietly that PECL is a museum for
extensions and not a place for developing them
simplify things more. There are only two
tags really needed in PHP templating engines https://fb.com/groups/2204685680/permalink/10157687999015681/
Best regards.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
eeper integration of JIT with VM.
>
>
> Thanks. Dmitry.
Great. No rush, we now have more than a year until Jit will be happening then :)
Otherwise, I'm really looking forward seeing this in action. Thank you
for the splendid work.
--
Peter Kokot
--
PHP Internals - PHP Runtime Develo
rs is to have Docker image(s)
available or even some Linux packages.
Also, practice shows that the dev branch in state before the few
months prior to the releases contains really a lot of bugs and also
build system bugs that normal users will have serious issues setting
this up. If Linux packagers and 3rd party repository maintainers can
help here, that would be also one way to go since PHP seems to be very
far away from doing such steps on the php.net side...
But to have PHP 8.0.0alpha1 version available at this and this date
before the PHP 7.4 release is quite challenging for all, I think.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ments...
Thank you.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
originally proposed.
>
> Regards,
> Nikita
Thanks for the RFC. The status of the document should be probably
updated from "Status: Under Discussion" to "Status: Voting"
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
On Wed, 24 Apr 2019 at 13:29, G. P. B. wrote:
>
> Hello Internal,
>
> The two weeks of voting have now ended.
> The results are 38 for and 18 against (total 56) for the primary vote to
> deprecate PHP's short open tag in PHP 7.4.
> This passes in favor with 68%.
>
> The results are 42 for
/to/php/files/with/short/tags
And then actually replacing them (without dry run):
php-cs-fixer fix --rules=full_opening_tag --diff
/path/to/php/files/with/short/tags
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
; On Wed, 24 Apr 2019, 19:10 Christian Schneider, > >
> > > wrote:
> > > > Am 24.04.2019 um 19:01 schrieb Peter Kokot :
> > > > > just a friendly reminder that by the time one writes an email here
> > > > > these tags can be already replaced
anymore neither people coding in PHP are using these anymore for a
very long time. If they postpone upgrades and neglect good coding
practices, nothing can help them improve or fix their apps.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
On Thu, 25 Apr 2019 at 09:15, Nikita Popov wrote:
>
> Hi internals,
>
> As already discussed in the corresponding voting thread, the deprecation of
> short tags as proposed has a high risk of causing inadvertent source code
> leakage. The RFC proposes to change the default of short_open_ta
ussion.
And besides, the cmake build system could even be done as a separate
project out of php for starters if anyone might be interested in doing
that.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t php.net without www.
Worth noting that now both domains result in 200 OK (previously there
was a redirection done from php.net to www.php.net):
curl -IL https://www.php.net
curl -IL https://php.net
Thank you...
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
ng that the legacy apps will work ok on PHP 8.0 also met)
- Actual removal in PHP 9 (because this is then the logical next
step). Removing something like this in PHP 8.1 is not following
semantic versioning at all. Either removal in 8.0 or 9.0.
Cheers and thanks.
--
Peter Kokot
--
PHP Internals - PH
how to
remove them. In PHP 8.0 directly as is now the result of this RFC or
in PHP 9.0 removal and in PHP 8.0 using a compilation error. Anything
in between is a more or less a revert of the original RFC which would
then come to a question of why making these RFCs at all and why voting
even matters.
Without these kind of "hacks" PHP wouldn't even move forward anymore.
Contributing to it would be in most cases only maintenance, fixing
bugs and compatibility with platforms out there. So nothing exciting
anymore like making it more syntactically correct, more logical etc.
(these are very important changes also beside new functionality and
extensions).
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
something in these tags anymore. Well, obviously this might be
for someone else a problem on a scale of an elephant, that I don't
know and probably won't understand fully. But, also at least now this
discussion and also RFC brought this thing out - short open tags
shouldn't be used
ed with BC break
effect in major release, the deprecation warning is self-evident and
therefore I'm not sure why the additional vote here. Because again, an
edge case scenario we could get a changed functionality in PHP 8 and
no warning in PHP 7.4.
Just as an example and a bit of an additional info h
x27;s very simple (and in most cases hopefully welcoming
enough) to send your pull request there. If not ping me up to check
your pull requests per manual basis.
A friendly nudge to the organizers... Next time, don't be shy and
please please avoid doing forks of this repo and let's do the noi
ill get worse actually from release to
release each year if we don't start refactoring some things. And the
manual for the installation of PHP that doesn't mention such options
(but on the other hand mentions installing PHP on servers that are
dead for decade) is also another story t
On Sat, 11 May 2019 at 06:12, Pierre Joye wrote:
>
> On Fri, May 10, 2019, 2:06 PM Peter Kokot wrote:
>
> >
> > The images for such C software are one of the more useless ones. Snaps
> > or custom Linux repositories are the way to go here. Because of the
> > in
Not trying to rush anyone to something they have no energy working on
anymore here but what's the plan here then? And what plan is there
with these short tags on the long run?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
...
>
> Can someone do some magic, and make it go away please ?
>
> Cheers
> Joe
100+ daily spam emails here also. Considering that these don't get to
other mailing lists, they can get regulated probably...
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
On Sat, 18 May 2019 at 22:02, Peter Kokot wrote:
>
> Hello,
>
> On Sat, 18 May 2019 at 12:06, Joe Watkins wrote:
> >
> > Hi all,
> >
> > Does anyone know what is the cause of all the spam from the announce
> > mailing list? I'm not sure
Hello,
On Sat, 11 May 2019 at 20:56, Peter Kokot wrote:
>
> Not trying to rush anyone to something they have no energy working on
> anymore here but what's the plan here then? And what plan is there
> with these short tags on the long run?
I'm just checking then why is t
no-check-certificate'.
For the www.php.net page this works ok:
wget https://www.php.net/distributions/php-7.3.6.tar.xz
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 12 Jun 2019 at 14:29, Sascha Schumann
wrote:
>
> Please try again.
>
> Sascha
Great. Now it works. Thank you so much, Sascha...
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
shows up, we can always
> move it back.
>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Hello, sorry for bumping this one. Is the ext/xmlrpc extension
On Fri, 28 Jun 2019 at 17:57, Christoph M. Becker wrote:
>
> On 28.06.2019 at 17:49, Peter Kokot wrote:
>
> > On Thu, 10 Jan 2019 at 19:43, Stanislav Malyshev
> > wrote:
> >>
> >>> ext/imap should follow the same road.
> >>>
> >>&g
ments has been reached on
the original RFC. Since the original RFC has been vetoed and so much
energy was invested from Zeev and some others commentators then I
guess the RFCs fail and we will have two types of opening tags in PHP
for ever. Otherwise, as described, yes.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
iling List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Yes, last time I was asking this, there was a clarification that
certain people from the group internals can veto particular RFC. So, I
think that this is the case here.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 7 Aug 2019 at 16:14, Zeev Suraski wrote:
>
>
>
> On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd wrote:
>>
>> On Wed, 7 Aug 2019 at 09:45, Peter Kokot wrote:
>> >
>> > Yes, last time I was asking this, there was a clarification that
>> &g
Hello.
On Wed, 7 Aug 2019 at 18:56, Chase Peeler wrote:
>
>
>
> On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot wrote:
>>
>> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski wrote:
>> >
>> >
>> >
>> > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd
Hello,
On Wed, 7 Aug 2019 at 19:03, Chase Peeler wrote:
>
>
>
> On Wed, Aug 7, 2019 at 1:00 PM Peter Kokot wrote:
>>
>> Hello.
>>
>> On Wed, 7 Aug 2019 at 18:56, Chase Peeler wrote:
>> >
>> >
>> >
>> > On Wed, Aug 7, 2019
On Wed, 7 Aug 2019 at 21:25, Zeev Suraski wrote:
>
>
>
> On Wed, Aug 7, 2019 at 8:45 PM Peter Kokot wrote:
>>
>> Considering that you're in favor of keeping the short opening tag in
>>
>> PHP "forever" because you haven't added any kind of
On Thu, 8 Aug 2019 at 00:38, Zeev Suraski wrote:
>
>
>
> On Thu, Aug 8, 2019 at 12:39 AM Peter Kokot wrote:
>>
>> Thank you for such a detailed response. Ok, I understand then. Then
>> next logical step here is - I would maybe want to use these awesome
>
g a new web project since the core people can't come to
conclusions how to make the language more consistent on the long run
(PHP 9 etc)... With more and more ambiguities, inconsistencies,
lockups, and dead ends behind the language there is probably also a
bit of a factor to consider that it lowers this attractiveness.
Meaning less people will think of adopting it (with all the things
combined - short tags, that and that inconsistency not being removed
from PHP due to major disastrous BC break there and there). So, the
damage is also on the long run with more and more locks and dead ends
not being able to be fixed and cleaned.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
"legacy" extension (or better named to not cause
issues with meaning that something like short tags will go away in
future - the "traditional" extension) or something like that.
Where developer would have option to enable it and use "traditional"
or whatever named PHP
ew features, even if it's just the mental energy of
> monitoring and responding to long threads like this one.
>
> Regards,
Code is like a garden. If there are unwanted weeds and nobody cleans
them up, the flowers don't shine and grow as they should. Cleaning of
the weeds is just as important as new features. A bit less but
important.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 14 Aug 2019 at 11:09, Christian Schneider wrote:
>
> Am 14.08.2019 um 10:39 schrieb Peter Kokot :
> >> The best counterargument I can give against "cleaning up" is that it takes
> >> energy away from actual new features, even if it's just th
On Wed, 14 Aug 2019, 12:09 Reinis Rozitis, wrote:
> > It is surprising how thing that is considered by one to be a security
> risk, is treated
> > as nothing relevant by others. This dichotomy is quite disturbing - in
> what case
> > removing security risk is "no real gain"?
>
> It's questionable
#x27;ll
> happily reply to private messages though.
>
> Thanks,
>
> Zeev
Hello @everyone,
this then also means that PHP will now never be a consistent language
and short tags will be forever in so we will all be able to support
Chase's gigantic legacy project forever?
Solut
ntation
phase) on the RFC? So, they can see the results before the voting
phase and if the time investment is worth the trouble of adding a
feature or not.
Thank you.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
tion. Even with a list of branches that someone with
access might even mistakenly pushed to origin decades ago.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
mentations out there. short
tags will stay in PHP for at least another 10+ years, so maybe we
should simply consider them not a part of legacy but a special kind of
a feature. There are some parts in PHP comments and docs that needs
this fixed and sorted out better a bit (probably - specially in
On Tue, 20 Aug 2019 at 18:02, Chase Peeler wrote:
>
> On Tue, Aug 20, 2019 at 11:50 AM Peter Kokot wrote:
>
> > On Tue, 20 Aug 2019 at 14:51, G. P. B. wrote:
> > >
> > > Hello internals,
> > >
> > > This RFC has been declined with
On Tue, 20 Aug 2019 at 18:39, Rowan Tommins wrote:
>
> On 20/08/2019 17:18, Peter Kokot wrote:
> > About the docs - there are
> > very minor changes needed where "backwards compatibility" is mentioned
> > maybe. Because they are not in PHP for keeping BC anymore
On Tue, 20 Aug 2019 at 19:47, Peter Bowyer wrote:
>
> On Tue, 20 Aug 2019 at 17:18, Peter Kokot wrote:
>>
>> Let's simplify this a bit because I'm not sure I have seen anyone
>> mentioning something like a PHP 10 milestone in all these discussions.
>> If
On Tue, 20 Aug 2019 at 23:37, Rowan Tommins wrote:
>
> On 20/08/2019 22:18, Peter Kokot wrote:
> >> The approach was: add the deprecation notice in PHP 8, and remove short
> >> open tags in PHP 9 or PHP 10 (purposely left vague to get more support for
> >> the
ith the
> defaults would be a good idea but then I'm not totally sure what it's point
> *would* be.
>
> Best regards
>
> George P. Banyard
About the error_reporting, I always set this to E_ALL for all
environments also, yes.
Syncing with the php.ini-production would pro
d (several 10 years) discussion comments. This is not a problem
because even with having an email archive online very rarely someone
will return to such discussion. RFC content is there and will be there
for PHP to move "elsewhere" though if such hypothetical case comes.
Tank you.
On Fri, 6 Sep 2019 at 11:11, Rowan Tommins wrote:
>
> On Thu, 5 Sep 2019 at 22:45, Peter Kokot wrote:
>
> > GitHub usage is inevitable.
>
>
>
> Did you use the wrong word here, or are you saying that, of all the
> hundreds of different platforms we could investigate
ss wants? One who won't
upgrade due to the BC breaks also won't need the new features anyway
very realistically.
Microsoft, Zend, and Red Hat have been showing that this is actually
possible. How smart this is for the PHP progress is another story, but
for the business it might be good to think about this also I guess:
https://github.com/microsoft/php-src/releases
So, to make some sort of a milestone with some of the versions -
either 8 or 9 or something.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
. But hopefully the relevant
emails could be approved on time anyhow.
Cheers.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello everyone,
I'm just adding a few cents into this discussion.
I've voted "yes" because we don't have any other async stuff RFCs available
nor in the preparation. PHP needs such functionalities very badly and very
quickly to sort of speak. Adding a brand new extension in the core is maybe
a s
On Mon, 22 Mar 2021 at 18:23, Guilliam Xavier wrote:
>
> On Mon, Mar 22, 2021 at 5:23 PM G. P. B. wrote:
>
> >
> > The thing is that by my recollections votes have already been extended.
> > Mostly when there has been issues with the mailing list, or some outside
> > event.
> >
> > Moreso, I don'
On Wed, 8 Jun 2022 at 20:16, shinji igarashi wrote:
> > declare(ignore_newline_after_close_tag=false);
>
> Thanks for coming up with another idea!
>
> As others have already pointed out, disabling the closing tag from
> eating trailing newline throughout the file would be inconvenient if
> we wan
On Sat, 10 Sept 2022 at 11:32, Yasuo Ohgaki wrote:
>
> 2022年9月7日(水) 22:58 Misha :
>
> > Hello everyone,
> >
> > We spend a lot of time to increase limits for uploads file in PHP. Can we
> > increase it in php.ini?
> >
> > Current value is 2Mb. Its so small value, when photo image can take 8Mb on
>
On Wed, 1 Feb 2023 at 13:14, Max Kellermann wrote:
>
> On 2023/01/30 11:26, Max Kellermann wrote:
> > If nobody objects, I'll announce the start of voting on February 1st.
>
> That's today.
>
> Voting starts now, please vote on my RFC:
> https://wiki.php.net/rfc/include_cleanup
>
> Original disc
On Sun, 12 Feb 2023 at 09:31, Max Kellermann wrote:
>
> On 2023/02/11 17:14, Peter Kokot wrote:
> > I've voted in favor of the RFC because of the code-cleaning,
> > tech-debt-reducing improvements to code readability.
>
> Exactly my point, and I'm surpris
On Wed, 22 Feb 2023 at 14:14, Max Kellermann wrote:
>
> On 2023/02/22 13:45, Max Kellermann wrote:
> > 13 years ago, there was commit
> > https://github.com/php/php-src/commit/477649cd3f09 which attempted to
> > fix this, but was reverted on the same day by commit
> > https://github.com/php/php-s
ake a look at these or suggest
something better? I plan to do some more cosmetic improvements later on also.
Thanks.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello all,
correct me if I'm wrong, but wouldn't be a good practice to follow the
currently set coding standards?
https://github.com/php/php-src/blob/master/CODING_STANDARDS
Good:
'foo_select_bar'
Bad:
'fooinsertbaz'
And therefore making aliases for all inconsistently named functions in
the core
Hello,
I believe it would be also good to add so called topics to
github.com/php/php-src repository. See this for more information:
https://help.github.com/articles/about-topics/
A minimal set should include these two:
- c
- php
Thanks.
--
Peter Kokot
--
PHP Internals - PHP Runtime
It's down here as well.
On 17 November 2017 at 23:03, Ryan Jentzsch wrote:
> I am trying to look up and/or enter a bug report:
>
> downforeveryoneorjustme.com reports:
> Is bugs.php.net down?
> It's not just you! bugs.php.net looks down from here.
--
Peter Kokot
y chance to start omitting them and use a single
.editorconfig file instead or is this something that is a must have in
C projects of today?
Thank you for some clarification on this :)
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www
Hello,
I've only briefly tested current implementation and from my point of view,
people new to the concept of coroutines, the async/await syntax might be
much more readable and understandable what is happening behind and why this
might be useful to have in the core. But yes, I'm sure there is a l
PBfiX3MfrlsxDxPjoiqW0jIfWLVD2RUQF
> FhwPhYuX3rv3Ur+wObDkbcOj2pepB0mABUf+2qOleYxLjRsxqpyQxyICdWPhweiP
> F1B2VZlo8+MJYO3CrtPlCLW8KQWzFK3El3jyfwCsDRhs86g5jpk7Y+wij5T9MDCI
> 3AoA2NJ3b7PSFHnzHRkoW3QD7kX3KnfcXIvcjW+0eQo=
> =ZenI
> -END PGP SIGNATURE-
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Peter Kokot
at container. I think this will improve dev experience of other
> people that want to help improving php source.
>
> Kind regards,
> Frederik Bosch
>
>
--
Peter Kokot
Joe?
>
> It was not Joe's day:
>
> https://github.com/php/php-src/commit/1891246c6637119e7ff5ab0d9826cf8f19223dac#r29914014
> --
> Jan
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Peter Kokot
4LEr13OaAlvs53niFo7r4sYzayKZdM
> NuNEQaXP7r5kS40Aqn/gjofIDg6j+4ni9atAwcbVY328iA4J5W5OWfS+XI5tSrs=
> =3ABE
> -END PGP SIGNATURE-
>
> Cheers
> Joe
Hello, thank you for the release, there is also a PHP-7.21 tag which
might be an issue when the final is released:
https://g
1 - 100 of 126 matches
Mail list logo
