Ioncube decoder and SourceGuardian decoder service
Calling all PHP developers! Want to wrap your brain around functional programming? Are you sick of reading tutorials about this magic “monad” thing but having no idea how to read Haskell? Then this book is for you.
Announcing Thinking Functionally in PHP, by yours truly, available now on LeanPub.
Continue reading this post on PeakD
Editor’s Note: This is the second in a five-part series on refactoring and modernizing PHP applications. If you were to identify the most expensive part of any development project, what would that part be? The planning phase? Acquiring copyright or intellectual property? Marketing and advertising? All of these would be wrong. The most expensive part […]
The post Part 2: Code Is The Most Expensive Solution appeared first on BrandonSavage.net.
The post Interview with Nicolas Grekas appeared first on Voices of the ElePHPant.
Editor’s Note: This is the first in a five-part blog series on refactoring and modernizing PHP applications. We’ve all heard the expression from the children’s story: “slow and steady wins the race.” But what does this have to do with refactoring? And how can this help us to modernize our applications? First, a little background: […]
The post Part 1: Slow and Steady appeared first on BrandonSavage.net.
This blog is a guide to learn about a PHP class, properties, methods, inheritance, and constructors.
In this episode of “PHP Internals News” I chat with Nikita Popov (Twitter, GitHub, Website) about the Constructor Property Promotion RFC.
The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news
Hi, I’m Derick. And this is PHP internals news, a weekly podcast dedicated to demystifying the development of the PHP language. This is Episode 53. Today I’m talking with Nikita Popov about a few RFCs that he’s made in the last few weeks. Let’s start with the constructor property promotion RFC.
Hello Nikita, would you please introduce yourself? Hi, Derick. I am Nikita and I am doing PHP internals work at JetBrains and the constructor promotion, constructor property promotion RFC is the result of some discussion about how we can improve object ergonomics in PHP.
Object economics. It’s something that I spoke with Larry Garfield about two episodes ago, where we discuss Larry’s proposal or overview of what can be improved with object ergonomics in PHP. And I think we mentioned that you just landed this RFC that we’re now talking about. What is the part of the object ergonomics proposal that this RFC is trying to solve?
I mean, the basic problem we have right now is that it’s a bit more inconvenient than it really should be to use simple value objects in PHP. And there is two sides to that problem. One is on the side of writing the class declaration, and the other part is on the side of instantiating the object. This RFC tries to make the class declaration simpler, and shorter, and less redundant.
At the moment, how would a typical class instantiation constructor look like?
Right now, if we take simple examples from the RFC, we have a class Point, which has three properties, x, y, and Zed. And each of those has a float type. And that’s really all the class is. Ideally, this is all we would have to write. But of course, to make this object actually usable, we also have to provide a constructor. And the constructor is going to repeat that. Yes, we want to accept three floating point numbers x, y, and Zed as parameters. And then in the body, we have to again repeat that, okay, each of those parameters needs to be assigned to a property. So we have to write this x equals x, this y equals y, this z equals z. I think for the Point class this is still not a particularly large burden. Because we have like only three properties. The names are nice and short. The types are really short. We don’t have to write a lot of code, but if you have larger classes with more properties, with more constructor arguments, with larger and more descriptive names, and also larger and more descriptive type names, then this makes up for quite a bit of boilerplate code.
Because you’re pretty much having the properties’ names in there three times.
Four times even. One is the property name and the declaration, one in the parameter, and then you have to the assignment has to repeat it twice.
You’re repeating the property names four times, and the types twice.
Right.
Truncated by Planet PHP, read more at the original (another 19135 bytes)
The PHP development team announces the immediate availability of PHP 7.4.6. This is a security release which also contains several bug fixes.All PHP 7.4 users are encouraged to upgrade to this version.For source downloads of PHP 7.4.6 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.
The PHP development team announces the immediate availability of PHP 7.2.31. This is a security release.All PHP 7.2 users are encouraged to upgrade to this version.For source downloads of PHP 7.2.31 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.
Platform.sh now supports displaying activities from your integrations in the API or command line.
This means that from now on, external integrations (GitHub, Gitlab, Slack, etc.) that you enable in your Platform.sh project will trigger activities every time that something happens with that integration.
This makes validating, testing, and troubleshooting an external integration so much easier.
These new activities are already available to users via the API or the CLI, and they will soon be displayed in the Platform.
The front page of the LLVM website proudly claims that:
Clang is an “LLVM native” C/C++/Objective-C compiler, which aims to deliver amazingly fast compiles […]
I’m not sure whether this has been true in the past, but it certainly isn’t true now. Each LLVM release is a few percent slower than the last. LLVM 10 put some extra effort in this area, and somehow managed to make Rust compilation a whole 10% slower, for as yet unknown reasons.
One might argue that this is expected, as the optimization pipeline is continuously being improved, and more aggressive optimizations have higher compile-time requirements. While that may be true, I don’t think it is a desirable trend: For the most part, optimization is already “good enough”, and additional optimizations have the unfortunate trend to trade large compile-time increases for very minor (and/or very rare) improvements to run-time performance.
The larger problem is that LLVM simply does not track compile-time regressions. While LNT tracks run-time performance over time, the same is not being done for compile-time or memory usage. The end result is that patches introduce unintentional compile-time regressions that go unnoticed, and can no longer be easily identified by the time the next release rolls out.
The first priority then is to make sure that we can identify regressions accurately and in a timely manner. Rust does this by running a set of benchmarks on every merge, with the data available on perf.rust-lang.org. Additionally, it is possible to run benchmarks against pull requests using the @rust-timer bot. This helps evaluate changes that are intended to improve compile-time performance, or are suspected of having non-trivial compile-time cost.
I have set up a similar service for LLVM, with the results viewable at llvm-compile-time-tracker.com. Probably the most interesting part are the relative instructions and max-rss graphs, which show the percentual change relative to a baseline. I want to briefly describe the setup here.
The measurements are based on CTMark, which is a collection of some larger programs that are part of the LLVM test suite. These were added as part of a previous attempt to track compile-time.
For every tested commit, the programs are compiled in three different configurations: O3, ReleaseThinLTO and ReleaseLTO-g. All of these use -O3 in three different LTO configurations (none, thin and fat), with the last one also enabling debuginfo generation.
Compilation and linking statistics are gathered using perf (most of them), GNU time (max-rss and wall-time) and size (binary size). The following statistics are available:
instructions (stable and useful)
max-rss (stable and useful)
task-clock (way too noisy)
cycles (noisy)
branches (stable)
branch-misses (noisy)
wall-time (way too noisy)
size-total (completely stable)
size-text (completely stable)
size-data (completely stable)
size-bss (completely stable)
The most useful statistics are instructions, max-rss and size-total/size-text, and these are the only ones I really look at. “instructions” is a stable proxy metric for compile-time. Instructions retired is not a perfect metric, because it discounts issues like cache/memory latency, branch misprediction and ILP, but most of the performance problems affecting LLVM tend to be simpler than that.
The actual time metrics task-clock and wall-time are too noisy to be useful and also undergo “seasonal variation”. This could be mitigated by running benchmarks
Truncated by Planet PHP, read more at the original (another 18417 bytes)