Hi Internals,
Currently PHP JIT only supports x86 and x86_64 CPUs on POSIX platforms and
Windows.[1] With the prevalence of PHP language and the notable
growth of ARM-based servers market, we believe JIT/arm64 would be in urgent
need in the near future.
As an initial effort to enable PHP
On Tue., Mar. 16, 2021, 13:58 Josh Di Fabio, wrote:
> Fibers will not make those issues obvious at all. The issues I'm
> describing will only crop up spontaneously and under load.
>
Hi Josh,
Is this really that big of a concern though? The issue will only be a
problem if it's run inside an
On 17/03/2021 01:29, Mike Schinkel wrote:
Would core not be able to implement an add() more efficiently than a
get()/set()? I am especially concerned the get()/set() approach might require
allocating memory for the returned array for every get().
There is no good way to add features to
> On Mar 16, 2021, at 1:46 PM, Levi Morrison via internals
> wrote:
>
> On Tue, Mar 16, 2021 at 11:06 AM Harm Smits wrote:
>>
>> Hey,
>>
>> First time ever replying so hope all went well.
>>
>> I believe the `autoload_set_classmap` function's signature should change
>> rather to
> On 17 Mar 2021, at 03:11, Jordi Boggiano wrote:
>
>
> On 16/03/2021 15:02, Stephen Reay wrote:
>>> On 16 Mar 2021, at 20:07, Jordi Boggiano wrote:
>>>
>>>
>>> P.S: While I am here looking at spl_* docs, it seems to me like
>>> spl_autoload_call should be deprecated in favor of
> I already showed you that: "next weekday". It can either be +1 days, +2
> days, or +3 days.
…depending on the time of execution, yes. The moment a developer consciously
decides to transform an interval to an ISO string representation, they
obviously accept the premise of anchoring the
Hi Larry,
Thanks for the feedback. Replies inline.
On Tue, Mar 16, 2021 at 8:33 PM Larry Garfield wrote:
>
> On Tue, Mar 16, 2021, at 1:44 PM, Josh Di Fabio wrote:
>
> > Perhaps we could rather make fibers *opt in* at the *callsite*
> > (similar to goroutine calls) in order to prevent functions
Hi Niklas,
On Tue, Mar 16, 2021 at 8:07 PM Niklas Keller wrote:
>
> Hey Josh,
>
>>
>> > This is a very valid concern to have. However, this code won't simply
>> > break if executed asynchronously.
>> > It only breaks if the same method (or other methods making use of the same
>> > state) is
On Tue, Mar 16, 2021, at 1:44 PM, Josh Di Fabio wrote:
> Perhaps we could rather make fibers *opt in* at the *callsite*
> (similar to goroutine calls) in order to prevent functions
> unexpectedly being executed asynchronously due to faraway changes.
> This would be safe and predictable while also
On 16/03/2021 15:02, Stephen Reay wrote:
On 16 Mar 2021, at 20:07, Jordi Boggiano wrote:
P.S: While I am here looking at spl_* docs, it seems to me like
spl_autoload_call should be deprecated in favor of class_exists, and
spl_autoload_extensions + spl_autoload also probably should be
Hey Josh,
> > This is a very valid concern to have. However, this code won't simply
> break if executed asynchronously.
> > It only breaks if the same method (or other methods making use of the
> same state) is executed concurrently on that object.
>
> I understand this, but of course this will
On 16/03/2021 18:56, Moritz Friedrich wrote:
Again, I’m not attached to `__toString()`. Having another helper method or a
special formatting constant, as suggested by others in this thread, would
likewise be a viable option. I’d merely prefer to have a built-in way of
parsing*and* composing
On Tue, Mar 16, 2021 at 6:20 PM Niklas Keller wrote:
>
> Hey Josh,
>
>>
>> Apologies, this is a long one!
>>
>> This RFC strikes me as being very dangerous. Implicitly allowing code
>> which is synchronous by design to be executed asynchronously seems
>> sure to lead to very subtle,
Hey Josh,
> Apologies, this is a long one!
>
> This RFC strikes me as being very dangerous. Implicitly allowing code
> which is synchronous by design to be executed asynchronously seems
> sure to lead to very subtle, unpredictable, confusing and dangerous
> bugs.
>
Thank you for sharing your
On Tue, Mar 16, 2021 at 11:06 AM Harm Smits wrote:
>
> Hey,
>
> First time ever replying so hope all went well.
>
> I believe the `autoload_set_classmap` function's signature should change
> rather to something like this:
>
> ```
> /**
> * Sets the internal autoloader to use the given classmap.
On Mon, Mar 15, 2021 at 12:41 PM Mark Randall wrote:
> I would like to propose the addition of a new mechanism of autoloading
> classes - a classmap that will be consulted prior to checking the
> spl_autoload_register'd callbacks.
>
> https://wiki.php.net/rfc/autoload_classmap
>
>
My initial
Hey,
First time ever replying so hope all went well.
I believe the `autoload_set_classmap` function's signature should change
rather to something like this:
```
/**
* Sets the internal autoloader to use the given classmap.
*
* @param $mapping key value pair of classes;
* @param $merge A
> I also don't understand what you're trying to say. You can't round trip
> every interval as encoded in a DateInterval object through an ISO
> interval string, so we shouldn't attempt to do that.
I think you do know what I’m trying to say, but choose to disagree with me. ISO
interval
On Tue, 16 Mar 2021, Moritz Friedrich wrote:
> > I also don't understand what you're trying to say. You can't round
> > trip every interval as encoded in a DateInterval object through an
> > ISO interval string, so we shouldn't attempt to do that.
>
> I think you do know what I’m trying to
On 16/03/2021 14:21, Larry Garfield wrote:
1) As the stated reason for this RFC is performance, have you any benchmarks to
show how much we'd win by using an engine-space lookup rather than user-space
lookup?
Performance benefit is unfortunately quite small, my tests suggest it is
in the
On Tue, Mar 16, 2021 at 8:02 AM Mark Randall wrote:
> On 15/03/2021 22:18, Levi Morrison via internals wrote:
> > Like any other case insensitive symbol PHP works with that comes from
> > userland, I would lower it in the engine's side of things. I would not
> > push the lowercase requirement on
On Mon, Mar 15, 2021, at 12:41 PM, Mark Randall wrote:
> Hi Internals,
>
> I would like to propose the addition of a new mechanism of autoloading
> classes - a classmap that will be consulted prior to checking the
> spl_autoload_register'd callbacks.
>
>
> On 16 Mar 2021, at 20:07, Jordi Boggiano wrote:
>
> Hey,
>
> Here some perspective on this from the Composer side of things. To the best
> of my knowledge the Composer autoloader is the default autoloader used by
> most PHP projects at this point except for WordPress. I am sure there are
Hey,
Here some perspective on this from the Composer side of things. To the
best of my knowledge the Composer autoloader is the default autoloader
used by most PHP projects at this point except for WordPress. I am sure
there are a few more outliers and people using custom autoloaders in
On 15/03/2021 22:18, Levi Morrison via internals wrote:
Like any other case insensitive symbol PHP works with that comes from
userland, I would lower it in the engine's side of things. I would not
push the lowercase requirement on the API.
That was the first design, however it required
On Mon, 15 Mar 2021, Moritz Friedrich wrote:
> I would assume the moment I call some kind of ISO conversion or
> serialization method on a dynamic interval, I’d receive output
> relative to now. `createFromDateString` creates the interval relative
> to now, so why shouldn’t the reverse hold
On 16/03/2021 09:42, Dik Takken wrote:
I guess that using an observer results in scenario 1. This would yield a
confusing debugging experience. At the call site, you cannot see that
the function is decorated. You expect to enter the called function but
the debugger will jump some place else.
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
On 16-03-2021 02:37, Katie Volz wrote:
> I was able to get a proof of concept of the following at
> https://github.com/iggyvolz/hooks:
That looks like a nice starting point to explore how this could work. I
use decorators a lot in Python code and would love to see something
similar in PHP.
One
On Fri, Mar 12, 2021 at 10:54 PM Aaron Piotrowski wrote:
>
>
> > On Mar 12, 2021, at 4:36 PM, Christoph M. Becker wrote:
> >
> > On 12.03.2021 at 23:04, Michael Wallner wrote:
> >
> >> Thank you, and everyone involved, for your effort.
> >>
> >> On 08/03/2021 20.40, Aaron Piotrowski wrote:
> >>>
30 matches
Mail list logo
