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 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
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 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
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 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
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
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
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
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
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
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
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
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 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 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 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 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, 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 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 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 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
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, 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 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, 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 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'
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
. 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
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
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
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.
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
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
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 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 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
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
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
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
#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
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
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
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
"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
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
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
>
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
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
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
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
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
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
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
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 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
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
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
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
...
>
> 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
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
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
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
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
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
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
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
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
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
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
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
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
; 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
/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
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
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
ments...
Thank you.
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
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
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
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
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
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
--
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
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
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
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
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
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
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 Thu, 7 Feb 2019 at 18:01, Peter Kokot wrote:
>
> Hello,
>
> On Thu, 7 Feb 2019, 16:52 Christoph M. Becker >
>> On 07.02.2019 at 16:14, Sjon Hortensius wrote:
>>
>> > On Wed, Feb 6, 2019 at 4:14 PM Ben Ramsey wrote:
>> >
>> >>> On
Hello,
On Thu, 7 Feb 2019, 16:52 Christoph M. Becker On 07.02.2019 at 16:14, Sjon Hortensius wrote:
>
> > On Wed, Feb 6, 2019 at 4:14 PM Ben Ramsey wrote:
> >
> >>> On Feb 6, 2019, at 01:22, Peter Kokot wrote:
> >>> I can help sort this mess. A s
is recognised in the commit
log properly and credits section is added as a recognition for the
volunteers (as noted in the php test fest instructions and all).
Let me know when we start adding those. Have a nice day.
[1] https://github.com/phpcommunity/phptestfest-php-src/pulls
--
Peter Kokot
--
[1] https://github.com/php/php-src/blob/master/README.MAILINGLIST_RULES
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, 4 Feb 2019, 02:32 Peter Kokot On Wed, 30 Jan 2019 at 13:57, Derick Rethans wrote:
> >
> > On Mon, 28 Jan 2019, Zeev Suraski wrote:
> >
> > >
> > > > I would like to make two changes to this header:
> > > >
> > > > 1. Change
big tasks that require a fork + branch checkout +
tons of very difficult and time consuming design/infrastructure/app
changes and then opening a discussion on the webmaster mailing list to
even start considering it. We need to start giving hints and make
decisions before that step if this can be done on tim
nsubscribe, visit: http://www.php.net/unsub.php
>
Hello,
I've prepared quick pull request [1] that fixes the missed headers in
source code files and additionally bumps or changes the year range on
other places.
Questions:
1.) What should "php -v" output regarding copyrights and year ranges?
2.) What should "man php" include under the COPYRIGHT section
regarding the year ranges?
3.) Similarly, should there be a common pattern for places like
phpinfo() output?
Thanks.
[1] https://github.com/php/php-src/pull/3791
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
milar
issues, PECL admins can simply set the package as "superseded by"
another package. For example:
https://pecl.php.net/package/date_time
If another "weakref" PHP extension will be developed elsewhere,
different naming can be picked for PECL or if that extension will
return to dev
n might be a better start with this.
Except that here we need to understand that PHP packages on Linux
distributions are already compiled and prepared for faster
installation, so installing extensions with PECL is a way different
approach compared to a more comfortable ways using
apt/yum/dnf/pacman/
t lack handling extensions
(we were just discussing PECL for example in some other thread)...
--
Peter Kokot
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
1 - 100 of 120 matches
Mail list logo
