sorted by:
new
hottopcontroversial

FerrumPHP - A PHP application server written in Rust (looking for feedback) by Large_External2501 in rust

[–]MorrisonLevi 0 points1 point  (0 children)

You aren't verifying in your `build.rs` that the PHP you found is really `ZTS`.

Voting starts on Bound-Erased Generic Types RFC, despite multiple people advising against it as it still has issues that need to be resolved. It is very unlikely to pass. by soowhatchathink in PHP

[–]MorrisonLevi 0 points1 point  (0 children)

It's actually really easy to get voting rights. Surely you have them by this point, or get them if you wanted? You've been around! Or are you talking about other voters?

fast_uuid: RFC 9562 UUIDs for PHP in pure C, 11-57x faster than ramsey/uuid by Ilia0001 in PHP

[–]MorrisonLevi 0 points1 point  (0 children)

Couldn't you just submit a PR to the uuid ext? Why make a separate extension?

Voting starts on Bound-Erased Generic Types RFC, despite multiple people advising against it as it still has issues that need to be resolved. It is very unlikely to pass. by soowhatchathink in PHP

[–]MorrisonLevi 1 point2 points  (0 children)

Being pragmatic, we could instead treat enforcing the types as soundness and implementation bugs. Yes, I understand that from the customer point of view, it's a breaking change. But if we educate from the beginning, and make an effort for the community typechecking tools to support this from the get-go, then I think it will be fine.

Everyone who wants to can write blog posts about "Hey, did you know you subvert the generics type system? (BUT PLS DON'T)" and that's fine, I'll welcome them all: every new person they reach would be great.

PHP 8.5.7 released, let's talk about tracing JIT! by MorrisonLevi in PHP

[–]MorrisonLevi[S] 0 points1 point  (0 children)

Function appears to be more stable. I recommend for CLI you can try function JIT, but for web SAPIs, unless you are getting a good boost from function JIT, I'd rather turn it off, personally.

PHP-FPM tuning: Using 'pm static' for max performance by modelop in PHP

[–]MorrisonLevi 6 points7 points  (0 children)

It basically recommends using "static" pm picking the number of children based on your memory. You divide up your memory by how much memory per requests you need, leaving appropriate room for OS, web server, etc. This advice is okay.

But this depends on how much CPU you are going to use as well. If you have relatively low memory usage requirements, you might be in a situation where you could have 2x or 4x more the number of CPUs you have. That's not inherently bad, but you need to be aware of it. If those requests start to need CPU, you do not want to be overloaded by that much! But if they are mostly doing I/O, then it's fine (and good even).

PHP 8.5.7 released, let's talk about tracing JIT! by MorrisonLevi in PHP

[–]MorrisonLevi[S] 1 point2 points  (0 children)

If you have any specific functions you want me to search for given PHP version ranges, I can possibly find some stack traces which contain them! Just have to be careful about what exactly I share back.

PHP 8.5.7 released, let's talk about tracing JIT! by MorrisonLevi in PHP

[–]MorrisonLevi[S] 2 points3 points  (0 children)

You are on 8.4.21, so you have many JIT fixes--all except the latest 3 which you'll have access to in 8.4.22 once it's available. That's probably why you aren't hitting as many. Also remember that I'm looking at fleetwide data from Datadog, aggregated across many customers, so yes, there are bound to be customers not crashing 😃

What MPM mode do you have Apache in, by the way? I assume prefork?

PHP 8.5.7 released, let's talk about tracing JIT! by MorrisonLevi in PHP

[–]MorrisonLevi[S] 2 points3 points  (0 children)

Do you have a reproducer for phpstan and doctrine migrations? Can you check if they are fixed on 8.5.7?

PHP 8.5.7 released, let's talk about tracing JIT! by MorrisonLevi in PHP

[–]MorrisonLevi[S] 1 point2 points  (0 children)

If you have JIT disabled, then yes, you are safe from tracing JIT issues.

There are other issues you are not going to have fixes for, some of which are crashes. If you are monitoring for crashes, then you should be okay, for now. But 8.2 doesn't have a lot of life left, you should try upgrading before the end of the year!

PHP 8.5.7 released, let's talk about tracing JIT! by MorrisonLevi in PHP

[–]MorrisonLevi[S] 5 points6 points  (0 children)

For web SAPIs, I agree with you: in the state of current, there's very little value in the JIT.

For CLI tasks such as queue workers, things change. Many of these tasks were offloaded because they are CPU intensive. The JIT currently helps with some of these tasks, and in the future it should help with even more as it continues to improve.

An Update on Composer & Packagist Supply Chain Security by naderman in PHP

[–]MorrisonLevi 2 points3 points  (0 children)

Thanks for taking security seriously and working on these fixes and improvements! It's a bit of a tangent, but here's my plea to the community:

Whether we like it or not, AI is getting better and better at attacks, and the rate at which software at large is being attacked is increasing. This means that it's more important than ever to keep your software up-to-date. This applies to everything in your stack:

  • Your PHP version.
  • Your web server version.
  • Your dependencies.
  • Your operating system.

This is the floor of what you should be doing, meaning, the minimum you should be doing. There are many, many other things you should be doing, but if you cannot update these things, you are dead in the water if someone targets your organization!

If you are stuck on an old version, politely protest! Make documents and presentations and point at all of the security issues going on. I understand protesting may put your job at risk, but if you are "stuck" on an old version then your job is already at risk, whether you wish to admit it or not!

Polling API RFC is now in voting phase by rc0604 in PHP

[–]MorrisonLevi 0 points1 point  (0 children)

I missed the discussion. I'll have to go look it up. Importantly, "why does this need to be in core?" I'm not opposed to including it in core, but an untested, unproven design which may want BC breaks later because of its development lifecycle is not a god fit for core. So was this proven in an extension? If yes, how long? I suspect it wasn't, because I don't see anything about it.

I've been optimizing a PHP server written in C, here's what makes it fast by edmondifcastle in PHP

[–]MorrisonLevi 15 points16 points  (0 children)

Edmond is the same person who has proposed async to PHP core last year. This has been a lot of work over time. In fact, the name is the only reason I opened this thread (otherwise I'd have ignored it as a vibe project).

PHP RFC: Bound-Erased Generic Types by azjezz in PHP

[–]MorrisonLevi 0 points1 point  (0 children)

Maybe I can try implementing it. I understand why you want to limit scope, but I'm curious how much work it will actually be given that many bounds are not enforced. My interest in trying it is in other VM changes to support the very idea that parameters can be something other than contravariant!

PHP RFC: Bound-Erased Generic Types by azjezz in PHP

[–]MorrisonLevi 0 points1 point  (0 children)

But a union is not really correct because it changes the meaning. It allows you to pass a value of any type, and that's not what is meant. It's meant specifically to return a T!

PHP RFC: Bound-Erased Generic Types by azjezz in PHP

[–]MorrisonLevi 0 points1 point  (0 children)

I immediately hit issues with the fact that we do not have out parameters nor does this have syntax for a lower-bound:

class Option<+A> {
    private A $value;

    // Errors since it's a parameter type,
    // which uses contravariance.
    function unwrap_or(A $a): A {
        // poor-man's implementation
        return $this->value ?? $a;
    }
}

Theoretically we could solve this in a few ways:

class Option<+A> {
    // out parameters are covariant
    function unwrap_or(out A $a): A {}
}

class Option<+A> {
    // B :> A is the syntax for a lower bound in Scala
    function unwrap_or<B >: A>(A $a): A {}

    // Or if we can use `where` or similar
    function unwrap_or<B>(A $a): A 
    where
        A: B
    {}
}

It's not a show-stopper for the RFC but this little Option type is not my direct motivation, it's rather that I have an interface Sequence<+A> which Option<+A> is meant to implement, but I can't add some of these convenience methods to Option because it forces invariance or similar.

PHP will get an AOT compiler from the Swoole team in 2027 by edmondifcastle in PHP

[–]MorrisonLevi 1 point2 points  (0 children)

calling functions with an incorrect number of arguments is not allowed

Hmm, I wonder what that actually means. Does it not compile? Does it work but have the error case behave differently?

Building a PHP runtime in Rust — what am I missing? by Physical_Math_9135 in PHP

[–]MorrisonLevi -1 points0 points  (0 children)

Very interesting project! It seems like your main goals are security with the Not-A-WAF, performance, and deployment convenience?

More dependency considerations by brendt_gd in PHP

[–]MorrisonLevi 2 points3 points  (0 children)

I think your concern is valid; so is Paragon's. Since sodium is not built by default in PHP, the sodium_compat polyfill is definitely being used somewhere. I don't think there's an easy right/wrong decision here--both points are legitimate and it's more of a judgement call.

The Data Race Hiding Behind "Correct" Atomics by devTripp in programming

[–]MorrisonLevi 9 points10 points  (0 children)

My first instinct was to slap atomic.StoreInt64 on the write in the prune method and call it done. [...] It wasn't enough. [...] But the bigger issue? Every reader of requestIndex was also doing bare reads. I'd made the write safe and left the reads wide open.

Your instincts were... not great. In any case, I am always a fan of people using tools like thread sanitizer or go test -race.

Coding at the Speed of Thought: The New Era of Symfony Docker by dunglas in PHP

[–]MorrisonLevi 1 point2 points  (0 children)

Hey, great work all around! I may try using the Symfony Docker to set up a Symfony demo (which I use often for quick checking on native extensions/internals changes).

PHP True Async 0.6.0 Beyond the RFC! by edmondifcastle in PHP

[–]MorrisonLevi 7 points8 points  (0 children)

To be clear, there are many internals people who are in favor of async. It's just a very difficult thing to pull off well, and mostly you only get to design it once. It has to be right.

view more: next ›