El El sáb, 28 de oct. de 2023 a la(s) 19:25, Jordan LeDoux <
jordan.led...@gmail.com> escribió:
>
>
> On Sat, Oct 28, 2023 at 10:54 AM juan carlos morales <
> dev.juan.mora...@gmail.com> wrote:
>
>>
>>
>> What I mean is more about … migrating a runni
El El vie, 27 de oct. de 2023 a la(s) 10:59, Kirill Nesmeyanov <
n...@xakep.ru> escribió:
>
> >Пятница, 27 октября 2023, 14:38 +03:00 от juan carlos morales <
> dev.juan.mora...@gmail.com>:
> >
> >Imagine a request comes to NgInx, then we process the r
Imagine a request comes to NgInx, then we process the request in PHP
suddenly while execution of PHP is running, we dont have more
resources in the server , so we need to process that PHP code on other
server with more resources.
How can we "move" the complete PHP process to another server
Imagine a request comes to NgInx, then we process the request in PHP
suddenly while execution of PHP is running, we dont have more
resources in the server , so we need to process that PHP code on other
server with more resources.
How can we "move" the complete PHP process to another server
Excellent Jakub, amazing, happy to know all this.
Lets wait for your proposal. Good luck, make it happen!
El mié, 1 mar 2023 a las 10:45, Jakub Zelenka () escribió:
>
> Hi,
>
> On Wed, Mar 1, 2023 at 1:36 PM Michał Marcin Brzuchalski
> wrote:
>>
>> Hi Jakub
>>
>> śr., 1 mar 2023, 14:09
will have this in PHP in 8.4 (this will be a
shock!)
Question ... are you planning to incorporate this by enhancing
json_validate() ???
El mié, 1 mar 2023 a las 9:07, Jakub Zelenka () escribió:
>
> On Wed, Mar 1, 2023 at 11:44 AM juan carlos morales
> wrote:
>>
>> Hello Internals
Hello Internals.
I am thinking about improving the json_validate() function developed
for php 8.3.
The actual descriptions goes like this:
json_validate(string $json, int $depth = 512, int $flags = 0): bool
I am thinking about enhancing this function to also be able to
validate against a JSON
As I previously wrote in the old Thread, ...
I would like to say that we should keep the release process as it is,
until a true, real, use case shows up.
Whoever participated in the threads is already aware about the so many
possibilities, and adjustments to the release/work process , that have
I am back into PHP internals.
After reading again and again, I would like to say that I think we
should keep the release process as it is. If there is a feature not
currently available in the current release, *at least* a user has
the possibility to download and compile the code by itself;
El sáb., 15 de octubre de 2022 11:02, juan carlos morales <
dev.juan.mora...@gmail.com> escribió:
> As far as I read... Everyone is right. All agree is BC break change, but
> this is being considered to be part of PHP 9.0, so if what We get is a
> better PHP then We mu
As far as I read... Everyone is right. All agree is BC break change, but
this is being considered to be part of PHP 9.0, so if what We get is a
better PHP then We must move forward, and such steps should be done
in a major version change.
The RFC got accepted and merge. Thanks for contributing :)
I am glad to announce that the RFC for json_validate() function has been
Accepted, 18 positive votes and 1 negative vote.
https://wiki.php.net/rfc/json_validate
I still have to do some adjustments to the code that is under review, but
all good.
Thanks a lot to everyone that participated and
There is a difference is declaring a function parameter of different
types ... because before hand, when the code calls the function, we
might not be sure about what kind if data the function will receive,
so the function could expect different types, and work the parameter
correctly
My small contribution to this
First of all, nice you picked "json_validate()" for your example,
thanks for this, somehow, support! :)
Second...
Apply a PECL strategy to try experimental features might not be the
convenient way always, for example, if we create a new ... sensitive
... ini
My 2 cents on this.
We should keep what is web related IMO. It does not make any sense to
take things out, that later everyone will write by its own, or end up
using a 3rd party package.
PHP should have what is web related already to be use.
Another different thing is the naming, the
Very interesting
But I think that the original suggestion had a slimer scope than the
rest of the opinions, that is why I also agree that the "scope" should
be defined clearly, and provide the examples needed to clarify the
suggestion itself.
Cheers
--
PHP Internals - PHP Runtime Development
I am also confused about this. Are you trying to generate multiple
inheritance with this? If not ... can you provide code examples of the
problem and a a hypothetical code of the solution you propose to that
problem?
Thanks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
The RFC is in voting phase now.
I want to thank everyone involved in the discussions related to this
RFC, the ones who reviewed the code in advance, and the ones that with
some emojis in github showed their interest and support.
--
PHP Internals - PHP Runtime Development Mailing List
To
I am glad to announce that the RFC for the "json_validate()" function
is in voting phase.
Voting started 2022-09-22 and will end on 2022-10-07 at 00:00:00 UTC
time zone (2 weeks + 1 day).
I kindly ask everyone to consider that is the first time I do an RFC,
if there is something wrong with it, I
> The RFC still contains a non-empty "Open Issues" section. This needs to
> be resolved before the vote starts.
>
> I would also recommend inserting a closed voting widget (or multiple, if
> you want to have additional votes for the details), so that it's clear
> for everyone how exactly the vote
> It appears the discussion came to a halt. How do you plan to proceed
> with your RFC?
Thanks for the heads up email Tim.
People, following the procedure, this is a "heads up" email to all of
you regarding this RFC. If no significant issue/complain raises, then
I will move the RFC for voting by
El mar., 13 de septiembre de 2022 20:01, Derick Rethans
escribió:
> On 13 September 2022 19:36:15 BST, juan carlos morales <
> dev.juan.mora...@gmail.com> wrote:
> >El mar., 13 de septiembre de 2022 15:33, juan carlos morales <
> >dev.juan.mora...@gmail.com> escri
El mar., 13 de septiembre de 2022 15:33, juan carlos morales <
dev.juan.mora...@gmail.com> escribió:
>
>
> El mar., 13 de septiembre de 2022 14:58, Mel Dafert
> escribió:
>
>>
>> In summary, I believe this can only be solved inside of PHP itself,
El mar., 13 de septiembre de 2022 14:58, Mel Dafert
escribió:
>
> In summary, I believe this can only be solved inside of PHP itself, by
> allowing to configure a way for `max_input_vars` to abort the request
> instead of truncating the input.
> The options I see feasible are:
> - A new ini
I also agree that increasing the size to something bigger than 8M
might not be a good idea; I can imagine that a value bigger than 8M
(like 50M) will cause an impact in hosting platforms specially, which
will be forced to always change the php's default values to a lower
one, because of potential
>
> I can sense we are all feeling like upping the value here.
>
> If we take it slow and move from 2MB to 8MB that would ease into it, and
> see how it goes in our next release ?
>
> Do we RFC this? Who is volunteering to make it,
>
There is already a PR in GitHub the author should have
I looked for a potential problem out of doing such a change but I could not
find anything.
But for sure such a change should be well marked in case is merge.
I did not take look at the PR as that can wait also.
Lets respect the RFC protocol and wait the specified time to see if someone
else
El lun, 29 ago 2022 a las 11:26, Deleu () escribió:
>
>
>
> On Mon, Aug 29, 2022 at 11:19 AM juan carlos morales
> wrote:
>>
>> El lun, 29 ago 2022 a las 11:06, Deleu () escribió:
>> >
>> > Has the option of returning a Result object been discu
El lun, 29 ago 2022 a las 11:06, Deleu () escribió:
>
> Has the option of returning a Result object been discussed/considered? Can it
> be an option? I imagine that if `json_validate(): JsonValidationResult`
> always returns a `JsonValidationResult` which contains a `public readonly
> bool
There is still 1 open question on the RFC, and is about the return value.
https://wiki.php.net/rfc/json_validate#open_issuesquestions
I would appreciate your feedback on this. Even though I was told the
RFC can go with 2 votings, I would like to know your thoughts about
that open question, in
El sáb, 27 ago 2022 a las 2:50, David Gebler () escribió:
>
> You can always offer two votes on the RFC - one for the function itself, then
> one for should it return boolean or return an int representing the
> json_last_error constants and let it be decided that way.
Thanks for the advice I
OMG, I need to take a rest, sorry for this, here it goes again; the
about JSON_INVALID_UTF8_IGNORE opinion is the same, but previous code
was wrong
Code:
string(5) "dummy" }
string(8) "No error"
Saying so, now ... yes I support and think is NEEDED the usage of the
JSON_INVALID_UTF8_IGNORE , as
El sáb, 27 ago 2022 a las 1:31, juan carlos morales
() escribió:
>
> === Open issues/concerns ===
>
>
> @@@ Usage of JSON_INVALID_UTF8_IGNORE @@@
>
> - I have my doubts now, because of this codes:
>
> ```
>
> var_dump(json_validate("\"a\x
I now provide an update of the discussion.
The good, the bads, the open questions, etc.
All of this will go into the RFC also, as requested by the procedure
in https://wiki.php.net/rfc/howto
"Listen to the feedback, and try to answer/resolve all questions.
Update your RFC to document all the
Oh! My bad. Nice work! Cheers
El vie., 26 de agosto de 2022 16:51, Tim Düsterhus
escribió:
> Hi
>
> On 8/26/22 16:15, juan carlos morales wrote:
> > Seems like we Don't Have tests for the function or we should enhance the
> > existing ones. If We would Have proper test
Seems like we Don't Have tests for the function or we should enhance the
existing ones. If We would Have proper tests the FIX would break it (as I
Don't see tests in the fix itself).That is why I say so.
I Am not in my computer atm. I Will check this later
El vie., 26 de agosto de 2022
El vie., 26 de agosto de 2022 13:08, juan carlos morales <
dev.juan.mora...@gmail.com> escribió:
>
> Is there a better way to do validation other than json_decode?
>
Better way than json_decode... Always from the core perspective
>
Just Want to remind that this discussion is not about "a json parser can be
written in PHP or not?".
We Have a JSON parser already in the core, ready to be use for validation.
Does it make sense to have another parser in User land to do validation if
We already have one?
Is there a better way
El vie, 26 ago 2022 a las 11:55, Peter Bowyer
() escribió:
>
> That's a good point which I had overlooked. Does an exception make most
> sense when this happens?
>
> Peter
I just got a code review from Derick Rethans explaining me that a
validation routine should not throw an exception.
I think
El vie, 26 ago 2022 a las 11:43, Andreas Leathley
() escribió:
>
> On 26.08.22 11:00, Michał Marcin Brzuchalski wrote:
>
> There is already a way to validate XML in PHP, and Yaml or PHP is
> something within the control of a PHP programmer, while JSON is mostly
> used as a format for communication
El vie, 26 ago 2022 a las 11:35, Michał Marcin Brzuchalski
() escribió:
> Your examples are a couple of functions.
> Assuming that they're heavily used is as true as my assumptions.
>
> Cheers,
Is good you clarify that your numbers were assumptions.
By the way, I never said anything about how my
El vie, 26 ago 2022 a las 11:26, juan carlos morales
() escribió:
>
> How can you make such an assertion in those numbers (99% of use cases
> and son on, that you mention) ? Can you give us more information about
> this assertions?
>
> I have provide real examples where the nee
El vie, 26 ago 2022 a las 11:00, Michał Marcin Brzuchalski
() escribió:
>
> A `json_decode()` is a substitute that IMO solves 99% of use cases.
> If I'd follow your logic and accept every small addition that handles 1% of
> use cases, somebody will raise another RFC
> for
El vie, 26 ago 2022 a las 10:56, Paul Crovella
() escribió:
>
> I'm for this as well. Though something more than a boolean is useful to
> indicate when the max depth has been exceeded as that's not strictly a
> problem with the json's validity.
Thanks, seems to be good idea to take it out, and I
El vie, 26 ago 2022 a las 10:28, Peter Bowyer
() escribió:
>
> Hi Juan,
>
> On Thu, 25 Aug 2022 at 17:02, juan carlos morales
> wrote:
>>
>> RFC: https://wiki.php.net/rfc/json_validate
>
>
> Thanks for bringing forward this RFC. I am in favour of this change,
El vie, 26 ago 2022 a las 6:47, Michał Marcin Brzuchalski
() escribió:
>
>
> I share the same opinion you expressed here even though you admit in recent
> email that you changed your mind.
>
> In recent versions we tend to accept more and more small standard library
> functions with IMO
> Having actually compiled the branch and tried it out, I have to say
> regardless of whether validating arbitrarily large blocks of JSON without
> being interested in the contents is a common or more niche use case, the
> memory savings ARE highly impressive. I had thought that because the
I also added in the RFC your concern about JSON_THROW_ON_ERROR usage.
RFC: https://wiki.php.net/rfc/json_validate
Implementation: https://github.com/php/php-src/pull/9399
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Ok then ... I take it out of the RFC just because we have doubts about it.
RFC: https://wiki.php.net/rfc/json_validate
Implementation: https://github.com/php/php-src/pull/9399
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Hey Tim, thanks a lot for participating and taking your time to use
the code and making your own tests, I highly appreciate it.
Regards.
RFC: https://wiki.php.net/rfc/json_validate
Implementation: https://github.com/php/php-src/pull/9399
--
PHP Internals - PHP Runtime Development Mailing List
Hello Rowan thanks for participating.
My answer for your comments would be:
=== Regarding JSON_THROW_ON_ERROR ===
I think is a valid point from your side, and I am open to change the
implementation if the maintainers believe so. I leave it there as it
existed in json_decode() and wanted to give
Thanks for participating. Cheers.
RFC: https://wiki.php.net/rfc/json_validate
Implementation: https://github.com/php/php-src/pull/9399
Hello David, thanks for your feedback.
I believe that the answer to most of your concerns/questions related to
other projects that would benefit out of something like this is already
answered by me in the RFC. I mentioned major PHP projects that will
directly benefit out of something like this.
Hello.
I am glad to present to you the RFC for json_validate() function.
The code/implementation still needs some workout, but seems to be fine
enough to be presented to you all.
I look forward for feedback
Thanks in advance.
Juan.
RFC: https://wiki.php.net/rfc/json_validate
Implementation:
I kindly ask to get RFC Karma, I already have wiki account.
RFC: is_json() function
I have previously write an email to Internals regarding this feature I
would like to include, and feedback was positive (email subject RFC Idea -
is_json - looking for feedback).
Thanks in advance.
Juan
Quite a feature to the language. Nice
I wonder if can be done using a different wording. If I can get an idea to
contribute I Will write again.
Keep it up!
Hello Ollie.
Dont be sorry. Actually I appreciate every feedback I got.
I promise I Will not dissapoint anyone.
I Will prepare de RFC next week.
Regards.
Juan
El dom., 7 de agosto de 2022 14:03, Ollie Read escribió:
> Hey,
>
> While I'm not opposed to the idea, I'm struggling to think of
Hi Juan,
>
> Thanks for your efforts, and examples.
>
> You are solving a common use case, in frameworks, libs, and general
> userland.
>
> This much needed function will see good perf/memory improvements once
> adoption of is_json() hits popular libs and frameworks.
>
> I will be voting in favor
(I received an email from mailer-dae...@lists.php.net , I had to cut the
message history as the mail server complained because the email got too
long)
Larry, here is the same benchmark including memory_get_peak_usage as
requested (more after the benchmark)
- Benchmark including
El dom, 31 jul 2022 a las 0:56, Deleu () escribió:
>
>
> On Sat, Jul 30, 2022, 4:48 PM David Gebler wrote:
>
>>
>>
>> What I'm asking is what's the practical use for this proposed function?
>> Where are you likely to need to know if a string is valid JSON but not
>> have
>> to (try to, with
El sáb., 30 de julio de 2022 16:48, David Gebler
escribió:
>
>
> On Sat, Jul 30, 2022 at 3:01 PM Nikita Popov wrote:
>
>> On Fri, Jul 29, 2022 at 4:27 PM juan carlos morales <
>> dev.juan.mora...@gmail.com> wrote:
>>
>> > I am following the R
n uses memory?
>
> # $memoryAfter = memory_get_peak_usage(true) / 1024 / 1024;
>
> Also, I'm concerned if it would be better to name the function
> `is_json_valid`?
>
> On Sat, Jul 30, 2022 at 10:37 AM juan carlos morales <
> dev.juan.mora...@gmail.com> wrote:
>
>&g
El sáb, 30 jul 2022 a las 8:30, Dusk () escribió:
> On Jul 29, 2022, at 23:05, Aleksander Machniak wrote:
> > json_decode() has $depth argument, I think is_json() probably also
> should. And I'm not sure about JSON_INVALID_UTF8_IGNORE flag.
> >
> > My point is that if you use these with
ed (I have the implementation of is_json() done already)
)
escribió:
>
>
> On Fri, Jul 29, 2022 at 7:27 AM juan carlos morales <
> dev.juan.mora...@gmail.com> wrote:
>
>> # Why this function ?
>>
>> At the moment the only way to determine if a JSON-string is valid
I believe
> this can be easily optimized by the engine itself.
>
> My vote is YES.
>
>
> Atenciosamente,
> David Rodrigues
>
>
> Em sex., 29 de jul. de 2022 às 16:32, Michał Marcin Brzuchalski <
> michal.brzuchal...@gmail.com> escreveu:
>
> > Hi Juan,
>
RFC with the help of the community if needed. I already
have a first version of the is_json() function tested and ready for review.
Thanks in advance, I am looking forward to hear your opinion on this.
Kind Regards,
Juan Carlos Morales.
67 matches
Mail list logo
