On Wed, Mar 17, 2021 at 7:41 AM Josh Di Fabio wrote:
> Note the difference between the two. Also note how, in both of the
> above cases, the asynchronicity is explicit and the developer has
> opted into it. Both of the above are different approaches to that
> being proposed in this RFC (this is a
Thanks for your reply and your interest.
Yes. Only Linux platform is tested on my side.
I spent about two months for this initial task.
To be honest, I haven't had a very clear overview of this CPU-specific JIT
parts so far, but I simply added the arm64 supports where necessary to make
JIT/arm6
This is great work! I assume you've only tested much on Linux, but I do
have an M1 Mac here to test.
I'm curious how much effort this took you, in terms of figuring out the
CPU-specific parts of the JIT, and what needed untangling from machine-
specific code and what didn't. I've been curious what
On Wed, Mar 17, 2021, 19:05 Nikita Popov wrote:
> On Wed, Mar 17, 2021 at 5:48 PM Alexandru Pătrănescu
> wrote:
>
>>
>> On Wed, Mar 17, 2021 at 5:30 PM Nikita Popov
>> wrote:
>>
>>> On Tue, Feb 23, 2021 at 3:01 PM Nikita Popov
>>> wrote:
>>>
>>> > Hi internals,
>>> >
>>> > While looking into v
On Wed, Mar 17, 2021 at 5:48 PM Alexandru Pătrănescu
wrote:
>
> On Wed, Mar 17, 2021 at 5:30 PM Nikita Popov wrote:
>
>> On Tue, Feb 23, 2021 at 3:01 PM Nikita Popov
>> wrote:
>>
>> > Hi internals,
>> >
>> > While looking into various issues related to static variable handling,
>> > I've become
On Wed, Mar 17, 2021 at 5:30 PM Nikita Popov wrote:
> On Tue, Feb 23, 2021 at 3:01 PM Nikita Popov wrote:
>
> > Hi internals,
> >
> > While looking into various issues related to static variable handling,
> > I've become increasingly convinced that our handling of static variables
> in
> > inher
On Tue, Feb 23, 2021 at 3:01 PM Nikita Popov wrote:
> Hi internals,
>
> While looking into various issues related to static variable handling,
> I've become increasingly convinced that our handling of static variables in
> inherited methods is outright buggy. However, it's also long-standing
> be
On Wed, Mar 17, 2021 at 9:06 AM Peter Stalman wrote:
>
> On Tue., Mar. 16, 2021, 23:49 Josh Di Fabio, wrote:
>>
>> Imagine for a moment that you create a library, awesome-library-x,
>> which uses a PSR logger internally. You will most certainly allow that
>> logger to be injected into your librar
On 17.03.21 09:36, Ilija Tovilo wrote:
Hi Marc
I think it would
be much clearer if there would be two different interfaces like:
``` interface IntEnum extends UnitEnum { public int $value; public
static function from(int$value): static; public static function
tryFrom(int$value): ?static; }
in
On Tue., Mar. 16, 2021, 23:49 Josh Di Fabio, wrote:
> Imagine for a moment that you create a library, awesome-library-x,
> which uses a PSR logger internally. You will most certainly allow that
> logger to be injected into your library. Now imagine that some other
> developer uses awesome-library
Hi Marc
> >> I think it would
> >> be much clearer if there would be two different interfaces like:
> >> ``` interface IntEnum extends UnitEnum { public int $value; public
> >> static function from(int$value): static; public static function
> >> tryFrom(int$value): ?static; }
> >> interface String
Am 17.03.2021 um 02:51 schrieb Mark Randall :
> It will be left to the voters to decide if 5% of an extremely common
> operation is worth the few dozen lines of code required.
Just to avoid misunderstanding things: This is a 5% boost of just the
autoloading time, right?
What does this translate
12 matches
Mail list logo
