What’s new in PeachPie 0.9.46

There have been some major additions and overhauls in PeachPie lately in preparation for version 1.0, so we decided to ship one more release before we set our sights on the final preparations before the first major stable version.

What happened since 0.9.45

Just in case you don’t know, PeachPie is a modern PHP compiler and runtime under .NET & .NET Core. At this point, the project has been around for a while, it supports many large real-world applications, e.g. WordPress, and multiple companies run their applications on PeachPie in production. In the last couple of months, we have been working on the stability and performance in preparation for the official 1.0 version, and we have made a tremendous amount of progress since version 0.9.45.

New Features

The compiler and the runtime have received plenty of new features that simplify working with PHP projects in .NET in general. We’ll address them in the documentation and in a separate blog post soon, but for now a short summary:

__destruct

As the name already suggests, this magic PHP function allows users to implement an object destructor. Until now, PeachPie ignored such methods, but since 0.9.46, it treats them as the CLR’s Finalize() implementation. In short, having __destruct() in a PHP class results in an implicit implementation of System.IDisposable on the containing class and in the implementation of two .NET methods:

override void System.Object.Finalize() {
  ((IDisposable)this).Dispose();
}
void System.IDisposable.Dispose() {
  if (!<>b_disposed) {
    <>b_disposed = true;
    this.__destruct();
  }
}

This is not the final behavior, but at least it allows for objects that need to be safely disposed (eventually) and for disposing the objects from within C# the .NET way. Note that the “finalizer” is called by .NET’s background Garbage Collection unlike in PHP, where it is called in a deterministic manner.

That’s why the compiler newly reports a new diagnostic PHP6004 whenever there is the __destruct function.

EmbeddedResource, GenerateEmbeddedFilesManifest

In C# and ASP.NET Core, we make use of embedded resources quite often, either for keeping strings aside of the actual code or, in case of ASP.NET Core, to bundle content files right into the compiled assembly file.

The second case has very interesting implications in combination with a PHP website. Thanks to this new feature, you can embed your content files right into the DLL, which results in a single DLL file containing both the compiled PHP code and the CSS/JavaScript/image files. You pack everything into a single file and only deploy that onto the web server. Then use ManifestEmbeddedFileProvider and let your ASP.NET Core server provide the embedded content files to the client.

To embed files into the DLL, alter the MSBuild project file as follows:

<PropertyGroup>
  <GenerateEmbeddedFilesManifest>true</GenerateEmbeddedFilesManifest>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.Extensions.FileProviders.Embedded" Version="2.*" PrivateAssets="All" />
  <EmbeddedResource Include="**/*.css;**/*.js;" />
</ItemGroup>

In the ASP.NET Core application, you add the following code into your request pipeline Configure method. Assembly.Load is used to get the assembly with your compiled PHP code.

// use static files embedded in the compiled assembly
var fp = new ManifestEmbeddedFileProvider(Assembly.Load("PhpProject.dll"));
app.UseStaticFiles(new StaticFileOptions() { FileProvider = fp });

The advantages are pretty straightforward, yet very significant; your deployment is faster and safer (replacing a single file instead of dealing with hundreds small ones), you avoid conflicts and there is no way for anyone to break or hack into your .js or .css. Why? Because they are not even on the web server anymore.

Compatibility improvements

We’ve been fixing stuff. A lot. Here’s just a quick summary of what was fixed and added in order to catch up with the PHP behavior:

  • fgetcsv(), PHP_MAXPATHLEN, mb_convert_variables(), image* functions
  • password* functions, …
  • Added a lot of missing Reflection functionality
  • Fixed iterators behavior
  • array_u* fixes, filter_var fixes
  • Throwing Error exception in most cases as it is in PHP instead of System.ArgumentExceptio
  • More implementation to DateTime, SplFileInfo, PDO, ..
  • Comparison operators handle NULL correctly
  • Implicit type conversion fixes
  • Fixed callable from array and string, respecting $this

IDE extensions

Besides bumping PeachPie to 0.9.46, we have also updated our IDE extensions. The VS Code extension is currently the more significant one, since it also brings the power of diagnostics right into the IDE.

We are also looking to add a third IDE to our list of supported development environments, so stay tuned for an announcement about this.

Next steps

The past six months have been one big preparation for version 1.0. We really want to release a stable PeachPie that performs reasonably well against PHP with the limited time we devote to speed optimizations and supports a good chunk of the most widely used apps. It’s admittedly taken us a little longer than we would have hoped, but our intention is to publish a stable version and not ship new releases every week with major fixes.

Right now, our focus is on a couple of activities that should lead us to version 1.0 fairly quickly:

  • Laravel: massive shoutout to Calvin Baart, an open source contributor who has been instrumental in helping us run this great framework. He keeps isolating the tiniest test cases of very difficult to spot inconsistencies and submitting issues, which we can usually fix relatively quickly. After Calvin managed to get the Laravel test suite to run on PeachPie, we’ve been gradually reducing the amount of failed tests, getting the number down from over 2300 fails to roughly 130 at the time of writing this. You can follow Calvin’s project here.
  • WordPress: we’re well aware of the magnitude of this platform, so ensuring that it runs smoothly on PeachPie with version 1.0 is paramount to us. We just updated WpDotNet to run on PeachPie 0.9.46 and its stability and performance are looking great. Another shoutout to Dan Llewelyn, who’s been submitting issue reports and updating WpDotNet to the latest version of WordPress.
  • Compatibility fixes: prior to releasing PeachPie 1.0, we’ll be looking to fix a few of the more pressing outstanding issues that are open on our GitHub.
  • Related tooling: a project like PeachPie can be a little tough to digest; using the compiler can be difficult, and so we want to make sure our peripheral tooling will be up to speed in order to use the project as comfortably as possible. You can be on the lookout for interesting announcements in the near future.

As always, a project like PeachPie relies on the community’s support. If you like what we’re doing, give us a shoutout, and follow us across the various platforms:

Twitter | Facebook |GitHub

Share this article:Share on FacebookShare on VKPin on PinterestShare on Google+Tweet about this on TwitterShare on LinkedInShare on Reddit
Posted on September 16, 2019, in category Information, News, tags: , , , , ,