Re: [PHP-DEV] Re: A set of 18 functions/changes to improve PHP core

[G. P. B.]

On Fri, 6 Jan 2023 at 16:19, Christoph M. Becker  wrote:

> On 06.01.2023 at 17:01, Thomas Hruska wrote:
>
> > Pre-implemented as an extension (sort of) w/ a preliminary test suite to
> > validate the implementations:
> >
> > https://github.com/cubiclesoft/php-ext-qolfuncs
> >
> > I probably violated some coding style guidelines and a few things are
> > bound to ruffle some feathers.  Be gentle?  But all input is generally
> > useful.
>
> Thank you!  At least some of that looks interesting to me.  I'll try to
> have a closer look; maybe filing issues on GH is preferable to
> discussing all the details on this ML.
>
> > I attempted to sign in with my existing PECL credentials on wiki.php.net
> > (user:  cubic) but that didn't work.  Attempting to create a Wiki
> > account for my possibly already existing user resulted in two error
> > messages:  An empty message box and another message box saying "The user
> > could not be created."
> >
> > Requesting RFC karma for user 'cubic' (cu...@php.net) if possible.
> Thanks.
>
> That is not possible, since you already have a PHP account.  Note that
> these are completely separate from PECL accounts (although users usually
> have the same nicknames for both accounts).  To log in to the Wiki, you
> need your PHP account password.  In case you have it forgotten, use
> .
>
> > I assume I'll need to create up to 18 separate RFCs unless one RFC is
> > somehow fine?  Not sure how this should be divvied up yet.
>
> Maybe a compromise is in order, and you can split it into a couple of
> RFCs.  Maybe not; I haven't checked closely so far.
>
> --
> Christoph M. Becker
>

I think splitting into "component" RFCs might make more sense as there are
some string, image, 2D matrices, variable and hash things which are logical
delimitations between these function additions.

I've had a cursory read of the README most seem reasonable, I have my
doubts about the matrix functions (see below) and str_realloc() (but that
might just be the naming and how it's meant to be use with str_splice which
is confusing me)

About str_splice(), why not call it str_modify() as the behaviour seems to
be subtly different from its array equivalent array_splice()?

About matrices:
We already have a couple of issues supporting them that we probably should
address those first, namely that multiplication is assumed to be
commutative, something which is not true for matrices (see
https://github.com/php/php-src/pull/9218)
Hoping I get back to argue about the former, it would make it possible to
use objects and the fact extensions can overload operators to make dealing
with matrices easier.
This is IMHO a better approach than using multidimensional arrays, which
those functions also seem to limit to the (albeit very useful) 2*2 case.

Anyhow, best of luck with the RFCs.

Best regards,

George P. Banyard

[PHP-DEV] [RFC][Vote] Asymmetric Visibility

[Larry Garfield]

I am hereby opening the vote on the Asymmetric Visibility RFC: 

https://wiki.php.net/rfc/asymmetric-visibility

Voting will be open for 2 weeks.

While we would certainly prefer if everyone voted in favor, for those who vote 
against the authors kindly request that you indicate why, using the second poll 
question or comment section afterward.  Thank you.

-- 
  Larry Garfield
  la...@garfieldtech.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: A set of 18 functions/changes to improve PHP core

[Christoph M. Becker]

On 06.01.2023 at 17:01, Thomas Hruska wrote:

> Pre-implemented as an extension (sort of) w/ a preliminary test suite to
> validate the implementations:
>
> https://github.com/cubiclesoft/php-ext-qolfuncs
>
> I probably violated some coding style guidelines and a few things are
> bound to ruffle some feathers.  Be gentle?  But all input is generally
> useful.

Thank you!  At least some of that looks interesting to me.  I'll try to
have a closer look; maybe filing issues on GH is preferable to
discussing all the details on this ML.

> I attempted to sign in with my existing PECL credentials on wiki.php.net
> (user:  cubic) but that didn't work.  Attempting to create a Wiki
> account for my possibly already existing user resulted in two error
> messages:  An empty message box and another message box saying "The user
> could not be created."
>
> Requesting RFC karma for user 'cubic' (cu...@php.net) if possible.  Thanks.

That is not possible, since you already have a PHP account.  Note that
these are completely separate from PECL accounts (although users usually
have the same nicknames for both accounts).  To log in to the Wiki, you
need your PHP account password.  In case you have it forgotten, use
.

> I assume I'll need to create up to 18 separate RFCs unless one RFC is
> somehow fine?  Not sure how this should be divvied up yet.

Maybe a compromise is in order, and you can split it into a couple of
RFCs.  Maybe not; I haven't checked closely so far.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] A set of 18 functions/changes to improve PHP core

[Thomas Hruska]

Pre-implemented as an extension (sort of) w/ a preliminary test suite to 
validate the implementations:


https://github.com/cubiclesoft/php-ext-qolfuncs

I probably violated some coding style guidelines and a few things are 
bound to ruffle some feathers.  Be gentle?  But all input is generally 
useful.



I attempted to sign in with my existing PECL credentials on wiki.php.net 
(user:  cubic) but that didn't work.  Attempting to create a Wiki 
account for my possibly already existing user resulted in two error 
messages:  An empty message box and another message box saying "The user 
could not be created."


Requesting RFC karma for user 'cubic' (cu...@php.net) if possible.  Thanks.

I assume I'll need to create up to 18 separate RFCs unless one RFC is 
somehow fine?  Not sure how this should be divvied up yet.


--
Thomas Hruska
CubicleSoft President

CubicleSoft has over 80 original open source projects and counting.
Plus a couple of commercial/retail products.

What software are you looking to build?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Microseconds to error log

[Mikhail Galanin via internals]

Hi Derick, Jakub and the team,

Thank you so much for your input. Sorry for being so slow with this --
I haven't forgotten, it's just unfortunately, I'm not capable to
handle all the things going around but I keep trying :)

I did some research about why we keep using plain log files and our
folks basically follow what Jakub said - we have our custom log
collector (similar to Scribe, Fluentd and others) which has quite
complicated routing rules and it was pretty straightforward to use
files but adding Syslog adds undesirable complexity to this system.
Although, it certainly doesn't look impossible.

Speaking about backward compatibility stuff - I can think of another
option, to postpone such a change till PHP v9.0, where we tend to
introduce breaking changes. We are not a startup anymore - can wait
for a couple of years.

I saw the suggestion to draft an RFC for this to thoroughly walk
through the question. I'm pretty open to this but it'll take a lot of
time. So guys, do you feel it's feasible to do? I can imagine some
people don't want to be harsh to say "please, stop this nonsense" :)
I can see that this change might not bring a lot of value and appeared
to be controversial so I'm fine to stop - we can keep this as our
private patch. But if someone feels it might be something good, I can
proceed with the RFC or something.

Thank you for your patience so far.



On Tue, Nov 29, 2022 at 11:43 AM Jakub Zelenka  wrote:
>
> On Mon, Nov 28, 2022 at 4:13 PM Derick Rethans  wrote:
>>
>> On Fri, 21 Oct 2022, Mikhail Galanin via internals wrote:
>> > Looking into the future, probably we would like to have this format
>> > configurable, if so it looks easy to do but still I can't see an easy
>> > way to handle the microseconds issue.
>>
>> Making things configurable requires an ini setting, which we generally
>> don't like to add. It wouldn't really work in this situation, as
>> warnings/errors happen either before or during INI file parsing, meaning
>> that it can't (yet) use the new format.
>>
>
> I'm not sure I understand this because error_log itself is already 
> configurable using INI so obviously if the file path is specified there, then 
> the logged time format should be the same if configured in ini. By default 
> there is no error log so errors that happen before should not be logged 
> anyway. Or do I miss anything?
>
>>
>> > Could you please help me to find the right way and share your thoughts
>> > about this topic (maybe there are strong objections against such a
>> > change)?
>>
>> I don't think we should change anything in PHP. Instead, use your
>> system's syslog. You can configure PHP to send all warnings to syslog by
>> setting "log_errors=1 error_log=syslog" in PHP.ini. In order to separate
>> out just the PHP issues, you can also set "syslog.facility=local1" (or
>> any other local).
>>
>> On Unix systems, you can configure syslog to add milliseconds to the log
>> file messages. See  https://askubuntu.com/a/1266114
>>
>> If your system already uses systemd and journald, then you don't have to
>> use any configuration settings, and you can query the journal with:
>>
>> journalctl -o short-iso-precise -r --facility=local1
>>
>> A PHP warning would show up in there, with something like:
>>
>> $ sudo journalctl -o short-iso-precise -r --facility=local1
>> 2022-11-28T16:06:53.862980+ gargleblaster php[3143059]: PHP Warning:  
>> Undefined variable $fasd in Command line code on line 1
>>
>
> It is not always practical to use system log for PHP especially for users 
> using more than one FPM pool. Log files also offer some advantages like 
> easier export and post processing so I think there is still place for log 
> files and we should support the users that still use them which includes new 
> features like this one.
>
> Cheers
>
> Jakub

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php