Live data from Hacker News

PHP Hacking aka trying to push PHP internals forwards

xarg.org

41–50 of 62 posts

Re: PHP Hacking aka trying to push PHP internals forwards

#41
post #38

Earlier quoted context omitted.

No it wasn't. As sc68cal says, its a patchbomb. And if you think otherwise, let me know how I can revert his changes to remove short tags and the mysql* changes using a single git command (hint, there isn't). I'm all for changes to an open source project - whether it acts like one or not - but every open source developer should, at some point, learn that gigantic patchsets with lots of unrelated changes are a big no-…

I'm just pissed that he didn't even bother to actually fork the project. On Github! WOW! All the previous commits before the fork? Gone. Poof. It's completely without any context. Even though there's a big "FORK" button!

Well what project would he fork? The (apparently) official PHP mirror is way out of date:

https://github.com/php/php-src

Re: PHP Hacking aka trying to push PHP internals forwards

#42
post #41
post #38

Earlier quoted context omitted.

I'm just pissed that he didn't even bother to actually fork the project. On Github! WOW! All the previous commits before the fork? Gone. Poof. It's completely without any context. Even though there's a big "FORK" button!

Well what project would he fork? The (apparently) official PHP mirror is way out of date: https://github.com/php/php-src

Well, then just use git svn to update the master of his fork to match the official PHP svn. It'll just be a fast forward anyway.

Two birds with one stone.

Re: PHP Hacking aka trying to push PHP internals forwards

#43
post #35
post #34

Earlier quoted context omitted.

That's what was done. https://github.com/infusion/PHP/commit/790d551ac9ef8e204b44f...

Why oh why didn't he fork php/php-src, make a branch for his changes, then commit as he went along? This just ends up as a big patchbomb. They're never going to merge his changes, and I don't blame them. EDIT - Hopefully we can straighten this around: https://github.com/infusion/PHP/commit/790d551ac9ef8e204b44f...

In this case, it would be better to maintain it as several topic branches (so that each logical change can be implemented in as many patches as necessary), and then a good old octopus merge as "master" that you force-update every so often.

(Yes, everyone hates you for modifying published history, it's evil, it will give you bad breath, yeah yeah yeah. But you have to think of this use case as a "code wiki" rather than "list of changes leading to the current state". After the patches are accepted, then don't force update them. When they are still in flux, modify history as often as necessary to make your changes easily comprehensible.)

Re: PHP Hacking aka trying to push PHP internals forwards

#45
I've read a lot of the PHP internals source code (I'm an author of phc), and this post leaves me a tiny bit optimistic, and a tiny bit disappointed.

I completely agree of the need to fork to make PHP a better language. The PHP internals community is the most awful OSS community I've ever been involved in, and getting shit done there just isn't going to work. So this is a good first step.

I also like the things he has taken away. PHP suffers from too many unnecessary options. I know that "unnecessary" is often subjective and in the eye of the beholder, but the OP seems to have a good eye for this. The things he removed are a blight on the codebase, so well done.

The optimizations are so-so. While I can see the benefits of the hardcoded constants, the other optimizations are hacks. And that has historically been the problem with PHP optimizations - they're all hacks. The engine needs rearchitecting to be fast, and all these hacks need to be removed, not more added.

Take for example that strlen is slow. The problem is that all function calls in PHP are slow. And if you looked at the function calling code, it's very obvious why. The correct solution is to make _all_ function calls fast, presumably by using some kind of inline cache, or just refactoring a ton of that crap out.

(Actually, someone introduced a patch to PHP-internals about two years ago to cache function calls somehow. I don't remember the exact details, but it was similar to the concept of an inline cache, perhaps storing a function cache struct in some bytecode or something. As I recall, it was denegrated as not being a full PIC. Sigh).

Finally, I really don't like the added functions. No problem with the functions themselves, just that adding functions to core PHP is not useful to anyone but the author. What if they clash with a user's function names? Why couldn't they just be implemented in user space? Etc. This is very much going on the wrong direction.

In the future, I'd like to see an effort like this go wild and make backwards incompatible changes like making the needle/haystack parameters consistent, but that's optimistic. (If they were to do it, phpcompiler.org could well be used to provide a 2to3-like too for doing the user-code porting automatically).

So overall, some good and some bad. If the OP focussed on making optimizations which improved the code base, removing more crap, and avoided adding "new" things, this would be really nice.

Re: PHP Hacking aka trying to push PHP internals forwards

#46
post #35

Earlier quoted context omitted.

Why oh why didn't he fork php/php-src, make a branch for his changes, then commit as he went along? This just ends up as a big patchbomb. They're never going to merge his changes, and I don't blame them. EDIT - Hopefully we can straighten this around: https://github.com/infusion/PHP/commit/790d551ac9ef8e204b44f...

In this case, it would be better to maintain it as several topic branches (so that each logical change can be implemented in as many patches as necessary), and then a good old octopus merge as "master" that you force-update every so often. (Yes, everyone hates you for modifying published history, it's evil, it will give you bad breath, yeah yeah yeah. But you have to think of this use case as a "code wiki" rather tha…

What do you mean by force update?

Re: PHP Hacking aka trying to push PHP internals forwards

#47
post #35

Earlier quoted context omitted.

Why oh why didn't he fork php/php-src, make a branch for his changes, then commit as he went along? This just ends up as a big patchbomb. They're never going to merge his changes, and I don't blame them. EDIT - Hopefully we can straighten this around: https://github.com/infusion/PHP/commit/790d551ac9ef8e204b44f...

In this case, it would be better to maintain it as several topic branches (so that each logical change can be implemented in as many patches as necessary), and then a good old octopus merge as "master" that you force-update every so often. (Yes, everyone hates you for modifying published history, it's evil, it will give you bad breath, yeah yeah yeah. But you have to think of this use case as a "code wiki" rather tha…

His work is based off 5.3.x, there is probably a branch for it in the official SVN repo. As one commenter noted, the github mirror is stale so he'd need to fork it and then update it with the official svn to find the branch.

It may make sense to rebase it off of trunk of svn.

Re: PHP Hacking aka trying to push PHP internals forwards

#48
post #38

Earlier quoted context omitted.

No it wasn't. As sc68cal says, its a patchbomb. And if you think otherwise, let me know how I can revert his changes to remove short tags and the mysql* changes using a single git command (hint, there isn't). I'm all for changes to an open source project - whether it acts like one or not - but every open source developer should, at some point, learn that gigantic patchsets with lots of unrelated changes are a big no-…

I'm just pissed that he didn't even bother to actually fork the project. On Github! WOW! All the previous commits before the fork? Gone. Poof. It's completely without any context. Even though there's a big "FORK" button!

This doesn't concern me as much, so long as he has a note saying "compiled onto commit hash blah". Cherry-picking would be a pain, but doable at that point.

Re: PHP Hacking aka trying to push PHP internals forwards

#49
post #46

Earlier quoted context omitted.

In this case, it would be better to maintain it as several topic branches (so that each logical change can be implemented in as many patches as necessary), and then a good old octopus merge as "master" that you force-update every so often. (Yes, everyone hates you for modifying published history, it's evil, it will give you bad breath, yeah yeah yeah. But you have to think of this use case as a "code wiki" rather tha…

What do you mean by force update ?

master would always contain the php-base+the octopus merge. So if the php-base was 5.3.6, it would be 5.3.6+patches. Tomorrow PHP 5.3.7 comes out, and then master would be 5.3.7+patches.
Post reply on HN