`@@NoJit` sounds pretty alright to me.
On Mon, Aug 3, 2020, 11:27 PM Derick Rethans wrote:
> On 3 August 2020 20:20:35 BST, Benjamin Eberlei
> wrote:
>
> >In that case maybe we should rename the attribute to @@DisableJit ?
> >This
> >would not clutter the global namespace with a "jit" class.
>
On 3 August 2020 20:20:35 BST, Benjamin Eberlei wrote:
>In that case maybe we should rename the attribute to @@DisableJit ?
>This
>would not clutter the global namespace with a "jit" class.
Things with a negative name are usually a code smell. I'm not keen on a
@[disableJit] attribute name.
ch
On Mon, 3 Aug 2020 at 19:52, Stanislav Malyshev wrote:
> I think turning JIT off is a valid use case, the rest looks much more
> iffy. I am not sure we want to let people tell the engine to JIT certain
> functions - are there a lot of cases where the engine wouldn't do it but
> it's actually the
On Mon, Aug 3, 2020 at 8:51 PM Stanislav Malyshev
wrote:
> Hi!
>
> > Only the trigger mode 4 (attributes) is actually using @@Jit("tracing")
> and
> > "function". This trigger mode feels like micro-management for developers
> > and since it has virtually no spotlight in discussions and blog posts
Hi!
> Only the trigger mode 4 (attributes) is actually using @@Jit("tracing") and
> "function". This trigger mode feels like micro-management for developers
> and since it has virtually no spotlight in discussions and blog posts about
> the JIT at the moment, we don't know if it brings benefits.
Hi,
I am going to pick up a discussion from
https://github.com/php/php-src/pull/5915 about the @@Jit attribute.
Nikita mentioned he is still not 100% clear what the usecase is for @@Jit
attribute and asked to discuss here.
The reason is that the default tracing JIT is clever to decide itself whe
Is it possible to add me to "jump" and "edit-new" servers?
It seems that only cron scripts are left to add.
wbr,
Sergey Panteleev
On 3 Aug 2020, 08:52 +0300, Сергей Пантелеев , wrote:
> I'll be happy to help too
>
> wbr,
> Sergey Panteleev
> On 3 Aug 2020, 00:30 +0300, Peter Cowburn , wrote:
> >
On Mon, Aug 3, 2020 at 5:02 PM Sara Golemon wrote:
> I just learned about https://github.com/php/php-tasks/issues/6
>
> Is it the case that we've agreed as a whole to simply make these
> conversions (as quiet under-the-hood, should only break is_resource() type
> of changes) without need for indi
I just learned about https://github.com/php/php-tasks/issues/6
Is it the case that we've agreed as a whole to simply make these
conversions (as quiet under-the-hood, should only break is_resource() type
of changes) without need for individual RFCs? Or is a perfunctory RFC and
vote called for on ea
On Sun, 2 Aug 2020, Sara Golemon wrote:
> * DateTime and Daylight Saving Time Transitions
> https://wiki.php.net/rfc/datetime_and_daylight_saving_time
> - Again, no implementation attached, and no obvious sign anything has
> been merged. Same rules, mark it, do it, or defer it.
> - Daniel/Der
Hi!
Is it possible to somehow detect if a generator can accept any send()
command? That is, if it has any line like this:
$gen = yield;
Use-case is when generators are used to factor out side-effects (as in
redux-saga). If no expression depends on the result of any
side-effect, all side-effe
11 matches
Mail list logo