Tomas Vortuba has a tutorial posted to his site showing you how to test private services in Symfony in unit tests for pre-4.1 Symfony installations (it has been resolved via simpler testing methods in Symfony 4.1 with the FrameworkBundle).

2 versions of Symfony are affected by this dissonance between services and tests. Do you use Symfony 3.4 or 4.0? Do you want to test your services, but struggle to get them in a clean way?

Today we look at possible solutions.

He starts with an example of the error you'd face if you tried to pull a service directly from the container that was marked as private. While you can specifically make it public in the yaml configuration, this potentially means doing that for all of the services you need to test. While this might work for smaller projects, it's unmaintainable for larger ones. He then shares some other options that could help resolve the issue including the one he ended up on: a compiler pass. He gets into a bit of detail on the changes this would require and where the "magic" is that lets it work.

The SitePoint PHP blog has a tutorial they recently posted from Christopher Pitt covering creating compilers in PHP and examples of it in use.

Many developers avoid writing their own compilers or interpreters, thinking that the topic is too complex or difficult to explore properly. I used to feel like that too. Compilers can be difficult to make well, and the topic can be incredibly complex and difficult. But, that doesn’t mean you can’t make a compiler.

[...] Compilers (and interpreters) begin with humble string manipulation and temporary variables. When they’re sufficiently popular (or sufficiently slow) then the experts can step in; to replace the string manipulation and temporary variables with unicorn tears and cynicism. [...] In our case, we want to maintain most of the PHP syntax, but we also want to add our own little bit of syntax on top. We could create a whole new interpreter…or we could preprocess the new syntax, compiling it to syntactically valid PHP code.

He starts off with some of the basic concepts involved with creating compilers and breaking the current code down into tokens. He shares all the code you'll need to follow along as he goes through the parsing and splitting of the tokens. He shows how to organize the tokens into a more AST-like structure and building it out into a more correct PHP structure. He ends the tutorial by taking what he's helped you create and integrate it with the Pre PHP-based precompiler as a custom compiler. He includes some examples of it in use and a simple screencast of what the end result looks like (a basic task list application).

In his latest post Juozas Kaziukenas shares a video of his "From PHP to Machine Code" talk he presented at the PHP UK Conference earlier this year (2016).

I recently gave a talk at a few conferences titled “From PHP to Machine Code”. It explains how compilers and interpreters work in general, where are the performance gains to be found and how I applied all of that to build PyHP. PyHP is a little toy project which showcases the basics of taking source code of a programming language and executing it.

As I mention a few times in the talk, it is completely and utterly useless for practical use, but it’s one of the fundamental skill-sets for any programmer. I think knowing how a bunch of text makes a computer do things at the low level is required knowledge for everyone.

The video of the presentation is embedded in the post or you can watch it directly over on YouTube if you'd like. In it he walks you through the entire process that happens from the time the PHP is executed all the way down to opcodes and bytecodes.

On the HHVM (HipHop Virtal Machine) blog there's a new post that looks at the evolution of the HHVM JIT compiler since the project started about four years ago.

When the hhvm project was started almost 4 years ago, it had a two-part mandate: First, create a PHP JIT that could serve facebook.com at least as efficiently as hphpc, the PHP execution engine we were using at the time. Second, replace hphpi, the interpreter our PHP developers were using in their daily work. hphpc and hphpi were independent pieces of software with unintentional subtle differences in behavior and a significant maintenance burden. Unifying the execution engines used in production and development would make our jobs easier while giving the PHP devs a nicer experience at the same time.

The article goes on to talk about their needs from the environment and the basics of how the JIT compiler works to "translate" the code into something more low level than even C++. They chart out the performance of the HHVM versus the HPPC, showing a major growth around the end of the last year and continuing into this year. They also give an example of how this translation happens from a PHP script to bytecode to the translated result from their "TranslatorX64" tool.

Allan MacGregor has posted a (high level) introduction to the HipHop Virtual Machine (HHVM) that was created by Facebook to address some of their PHP-related needs inside their platform. It sacrifices some things in the name of speed and less resource consumption.

In early 2008 Facebook began working on HipHop(now HPHP), a PHP execution engine; its original motivation was to convert Facebook massive PHP code base into C++ in order to save resources and increase the application performance. [...] At it’s peak, HipHop PHP code showed up to 6x times better performance than its ZEND counterpart. However, there where several drawbacks to this first iteration of HipHop. [...] At the same time Facebook started the development of the modern version of HipHop, known as HHVM (HipHop Virtual Machine), HHVM improves the strengths of HPHPc and corrects many of the critical problems.

He talks some about Facebook's efforts to open source the platform and what the HipHop VM does to make your PHP code execute that much faster. It's all about bytecode, machine code and a JIT (just in time) compiler where the bytecode is parsed during execution instead of before.

Currently HHVM supports PHP 5.4 almost on its entirety, however there are still numerous bugs that prevent some applications from running, for that reason Facebook has set as goal to have the top 20 open source PHP applications running on HHVM. The first popular application to achieve this was Wordpress.

On the PHPClasses.org site they've posted the latest episode of their "Lately in PHP" podcast series - Episode #30, "Will PHP6 Feature a JIT compiler?"

Now that Facebook made some progress with their PHP HipHop VM JIT compiler engine, some PHP core developers are considering having also a JIT compiler implementation of the official implementation based on LLVM, eventually in PHP 6. [...] They also commented on the first alpha release of PHP 5.5.0, proposals for having pure interfaces in the PHP core, the Facebook PHP JIT compiler enhancements, and the new system of levels and missions of the PHPClasses and JSClasses sites.

You can listen to this latest episode either through their in-page player, by downloading the mp3 or by subscribing to their feed. You can also watch the video of the recording as well.

On the Sankuru blog today the next post in the series about creating a compiler in PHP has been posted. In this latest tutorial he shows how to set up a plugin architecture for the compiler that allows you to quickly and easily extend it beyond its base functionality.

A plugin architecture allows multiple developers to work on the same application and let yet another person assemble their work later on. It allows the plugin developer to understand just his plugin API without having to understand all the details of the entire application.

He describes a few platforms that already have the concept of plugins including Joomla, Mediawiki and SugarCRM. He explains what a plugin architecture should be and what it shouldn't be. All of this is his first steps towards building a plugin-enabled compiler and virtual machine in PHP.

Improving on his last post about creating a bytecode compiler in PHP, the Sankuru blog has a new post in the series looking at extending the basic compiler to add support for if/while and do while logic.

In order to obtain a turing-complete programming language, that is, a language in which we can implement and execute any arbitrary algorithm, that is, that other turing-complete machines can execute too, we now need to add a way of (conditionally) branching, that is, the IF statement, and at least one way of repeating statements, that is the WHILE or the DO WHILE statements.

He includes a simple TL-based script as an end goal for the compiler to be able to execute and shows how to add rules for it to the lexer/parser. Rules for the "if" are relatively simple, but there's a hitch in dealing with embedded "while" statements he had to work around. The post ends with the bytecode results for the sample program and the resulting output from the compiled versions execution.

On the Sankuru blog there's a recent post looking at the construction of a simple bytecode compiler with a virtual machine as written in PHP (for Expression Language).

In my previous blog posts, I demonstrated how we can use the builtin PCRE library, to create a lexer in Php. I also showed how to use Bison-generated LALR1 parser tables in Php. In this blog post, I will re-use these lexing and parsing facilities to compile EL programs from within Php.

He uses his lexer/parser (available for download) in an example program that outputs some values and does some simple mathematical operations. There's sections detailing the Bison grammar used, execution stacks, callbacks and the bytecode it produces.

In a new post to his blog Brian Swan explains why the latest versions of PHP (the 5.3.x series) are faster now on Windows than some previous versions have been. (Hint: updated technology can work wonders sometimes)

[Rasmus Lerdorf recently said at a Seattle meetup] "If you aren’t running PHP 5.3 on Windows, you’re lucky…because you have a 40% performance boost coming." He clarified this by saying that, with some help from Microsoft, improvements were made in PHP 5.3 that led to a 40% performance improvement of PHP on Windows. Because he didn’t go into the details of why this performance boost was realized, I got questions in email the next day asking about why.

The information in a borrowed slide (from a presentation by Pierre Joye) shows what the differences between the versions are - things like the use of a more modern compiler (VC9 vs VC6), calls to the Win32 API directly and better library management.