PHP 7.3.17 Released – PHP: Hypertext Preprocessor

The PHP development team announces the immediate availability of PHP 7.3.17 This is a security release which also contains several bug fixes.All PHP 7.3 users are encouraged to upgrade to this version.For source downloads of PHP 7.3.17 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.

IBM and Zend by Perforce Announcement for IBM i Users

Building a Strong Future for All

As a close IBM partner for more than 14 years, Perforce Software continues to help the IBM i community build on its existing investments with open source technologies. This includes providing Zend Server for IBM i, which delivers a secured, supported, and certified PHP stack for IBM i, along with cutting-edge tools for application monitoring, profiling, caching, and code tracing.

A generic middleware pattern in Typescript – Evert Pot

I just realized this is the third time I’m writing async middleware invoker,
I thought I would share the generic pattern for the benefit of others.

I’m not sure if this is interesting enough for a NPM package, so I’ll leave
it here for inspiration.

The specific middleware pattern I am implementing, is similar to Express,
Koa or Curveball.

We’re working off a context, and we are running a chain of middlewares
in order with this context as an argument.

We’re also passing an next function. If this next function is called,
the next middleware in the list will be called. If not, the chain will be
broken.

Furthermore, (unlike Express, but like Koa) middlewares can be async
function or return a promise. If it is, we want to await it.

The setup

Lets start with the setup, describing the middleware:

/** * 'next' function, passed to a middleware */
type Next = () => void | Promise<void>; /** * A middleware */
type Middleware<T> = (context: T, next: Next) => Promise<void> | void;

Middleware is the actual async/non-async middleware function. I made a
type for Next so I don’t need to write it out more than once.

How we want to use it

This would be the ‘getting started’ section of the documentation.

The idea here is that we have an ‘app’, a set of middlewares and a context
we want to operate on.

The following code would be written by the user of this framework:

/** * The context type of the application. * * In 'koa' this object would hold a reference to the 'request' and 'response' * But our context just has a single property. */
type MyContext = { a: number;
} /** * Creating the application object */
const app = new MwDispatcher<MyContext>(); /** * A middleware */
app.use((context: MyContext, next: Next) => { context.a += 1; return next(); }); /** * An async middleware */
app.use(async (context: MyContext, next: Next) => 

Truncated by Planet PHP, read more at the original (another 5860 bytes)

Early release of the Advanced Web Application Architecture book – Matthias Noback

In the Epilogue of the Object Design Style Guide, I started happily outlining some of the architectural patterns I’ve been using for several years now. I wanted to give some kind of an overview of how the overall design of your application would improve if you apply the object-design rules in that book. I soon realized that an Epilogue was not enough to cover all the details, or to communicate the ideas in such a way that they would be applicable in everyday projects. And so a new book project began…

I started working on it exactly a year ago, in April 2019. The initial excitement kept me going for the first 100 hours or so, after which other projects came up (like the re-release of the style guide with Manning, lots of programming projects and trainings). Finally there was some time to finish the work, but then the Corona crisis kicked in.

Even though it’s a strange time to be releasing a new book, I think it’s ready to be read by you. I’m very happy to be using the Leanpub platform again. My experience with Manning was great, but I wanted to be completely independent again, so I could experiment with several new forms of publishing. A book alone is nice, but I wanted to offer a more elaborate learning experience this time, which is why I’m offering several things at the same time:

Get a new chapter every two weeks

I’m releasing the book while I’m still working on it. Right now an early release is available for $15,-. It contains the preface, an overview of the contents, the introduction chapter which introduces the concept of infrastructure code, and the first chapter of the first part of the book. The first part is called “Decoupling from infrastructure”. The first chapter is about designing the domain model in a decoupled way.

During the following months I’ll be publishing one new chapter at least every two weeks, and every time this happens, the minimum price will go up with 2 dollars. Note that if you get your copy now, you will be entitled to all future updates.

Gain access to a new platform: “Read with the author”

There’s a special package available on Leanpub which gives you access to the new “Read with the author” platform. If you buy that package, you can join a regularly scheduled video chat, where we go over a new chapter every two weeks. You will be able to use these sessions to deepen your understanding of the topic, and learn about related topics that didn’t make it into the book. You can ask questions too, so you’ll be prepared in the best possible way when you start applying the ideas from the book to your own projects.

Inspect a showcase project that illustrates the book’s concepts

The book itself contains many architectural principles and design patterns, illustrated with code samples and diagrams. However, not all the relevant details fit on a page. And sometimes things are a bit different in a real-world project than they are in idealized code sample scenarios. In fact, the real-world project that I offer alongside the book is the “Read with the author” platform which I’ve just described. Its code base follows the concepts explained in the book and shows how the different objects work together to provide a working application that is not another Todo app, but a normal application, with everyday use cases we can all relate to. Reading through the code and the tests will provide you with many implementation ideas for your own projects.

Access to the showcase project is kindly supported by Gitstore.

Conclusion

I hope that all of this adds up to a nice reading experience, and that you’ll have fun with the book, and any combination of related products. Get it now, while it’s hot, and join other readers in their adventure!

And as always: thank you very much for your ongoing support and interest.

P.S. If you want to buy this book for your team, or for multiple teams: check out the Team and Enterprise licenses.

Go 2ème langue est en ligne – PHP-GTK Community

Le mini-site associé au livre “Le Langage Go – les fondamentaux du langage”, est en ligne et 100% traduit.

Ce site est l’occasion de trois premières pour OSInet:

Premier site interne totalement bilingue, avec l’intégralité du contenu disponible en français et en anglais.
Premier site réel sous Hugo et non Drupal ou Dokuwiki
Premier site à décrocher un score 100/100 (desktop) sur Google PageSpeed Insights

PHP Internals News: Episode 48: PHP 8, JIT, and complexity – Derick Rethans

PHP Internals News: Episode 48: PHP 8, JIT, and complexity

London, UK

Thursday, April 9th 2020, 09:11 BST

In this episode of “PHP Internals News” I discuss PHP 8’s JIT engine with Sara Golemon (GitHub).

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

Transcript

Derick Rethans 0:16: 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 48. Today I’m talking with Sara Golemon about PHP 8 and JIT. Sara, would you please introduce yourself?
Sara Golemon 0:33: Hi there. Hi there, everybody listening to PHP internals podcast. I’m Sara. I’ve been on this podcast before. But in case you’re just getting here to for the first time, welcome to the podcast. You have a nice backlog to go through. I am a lapsed web developer, come database security engineer by day, and an opinionated open source dev slash PHP 7.2 release manager by night and also day. I’ve been involved with the project for about 20 years now off and on. Somehow I just keep coming back for more punishment.
Derick Rethans 1:03: We’re leading up to PHP 8, with lots of new features being added. But one of the biggest thing in PHP 8 that I’ve spoken about on the podcast on before all the way back last year in Episode 7, is that PHP eight is going to get a JIT engine. Would you care to explain what a JIT engine does again?
Sara Golemon 1:20: Well, I’m going to give you the short, you can look this up on Wikipedia in two seconds definition of JIT, means just in time compilation. That doesn’t really tell you much, unless you listen to it on the sort of other half of that of AOT, or ahead of time compilation. AOT is what you expect from applications like GCC, you know, you just make an application that you’ve got C or C++ kind of source code to that’s ahead of time. JIT is saying, well, let’s take the source for application. And let’s just run with it. Let’s just start executing it as fast as I can. And eventually we’re going to get down to some compiled code. That’s going to run a little bit quicker than the initial stuff did. PHP already has this nice little virtual machine built into it. We call it the Zend engine. That takes your script and immediately just says: All right, well, what does this say in computer terms? Well, a computer readable term is a series of these op codes, they’re also called byte codes in other languages that give you instructions for: run this type of instruction at this time and get something done. The PHP runtime interpreter interprets that one instruction at a time basically pretending to be a CPU. This works quite well, it runs quite efficiently. But there’s still this sort of bottleneck in the middle there of a program pretending to be a CPU running on top of a CPU in order to run other code. The idea of JIT is that this thing sitting in the middle is going to gradually figure out what your program really is trying to do and how it’s intended to run, and It’s going to take those PHP instructions and it’s going to turn them all the way down into CPU instructions, so that it can get out of the way and let the CPU run your code natively as if it had been written in a compiled AOT kind of language. What that actually means for execution of PHP code in PHP 8 is still sort of a, you know, a question that’s, that’s left to be answered here. I listened to your interview with Zeev. Episode 7, is a good episode of getting some good information on that. We do definitely agree on what the status of the JIT within PHP is, right now we can. It’s subjective facts like this is how much work has been done largely by Dmitri, where we can kind of expect to see the best gains come from. I personally think I might be a little bit more pessimistic than him in terms of the actual

Truncated by Planet PHP, read more at the original (another 22290 bytes)

PHP Internals News: Episode 50: The RFC Process – Derick Rethans

PHP Internals News: Episode 50: The RFC Process

London, UK

Thursday, April 9th 2020, 09:11 BST

In this episode of “PHP Internals News”, Henrik Gemal (LinkedIn, Website) asks me about how PHP’s RFC process works, and I try to answer all of his questions.

Transcript

Derick Rethans 0:16: 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 50. Today I’m talking with Henrik come out after he reached out with a question. You might know that at the end of every podcast, I ask: if you have any questions, feel free to email me. And Henrik was the first person to actually do so within a year and a half’s time. For the fun, I’m thinking that instead of I’m asking the questions, I’m letting Henrik ask the questions today, because he suggested that we should do a podcast about how the RFC process actually works. Henrik, would you please introduce yourself?
Henrik Gemal 0:52: Yeah, my name is Henrik Gemal. I live in Denmark. The CTO of dinner booking which does reservation systems for restaurants. I’ve been doing a PHP development for more than 10 years. But I’m not coding so much now. Now I’m managing a big team of PHP developers. And I also been involved in the the open source development of Mozilla Firefox.
Derick Rethans 1:19: So usually I prepare the questions, but in this case, Henrik has prepared the questions. So I’ll hand over to him to get started with them. And I’ll try to do my best to answer the questions.
Henrik Gemal 1:27: I heard a lot about these RFCs. And I was interested in the process of it. So I’m just starting right off here, who can actually do an RFC? Is it anybody on the internet?
Derick Rethans 1:38: Yeah, pretty much. In order to be able to do an RFC, what you would need is you need to have an idea. And then you need access to our wiki system to be able to actually start writing that, well not to write them, to publish it. The RFC process is open for everybody. In the last year and a half or so, some of the podcasts that I’ve done have been with people that have been contributing to PHP for a long time. But in other cases, it’s people like yourself that have an idea, come up, work together with somebody to work on a patch, and then create an RFC out of that. And that’s then goes through the whole process. And sometimes they get accepted, and sometimes they don’t.
Henrik Gemal 2:16: How technical are the RFCs? Is it like coding? Or is it more like the idea in general?
Derick Rethans 2:23: The idea needs to be there, it needs to be thought out. It needs to have a good reason for why we want to add or change something in PHP. The motivation is almost as important as what the change or addition actually is about. Now, that doesn’t always get us here at variable. In my opinion, but that is an important thing. Now with the idea we need to talk about what changes it has on the rest of the ecosystem, whether they are backward compatible breaks in there, how it effects extensions, or sometimes how it effects OPCache. Sometimes considerations have to be taken for that because it’s, it’s something quite important in the PHP ecosystem. And it is recommended that it comes with a patch, because it’s often a lot easier to talk about an implementation than to talk about the idea. But that is not a necessity. There have been quite some RFCs where the idea was there. But it wasn’t a patch right away yet. It is less likely that t

Truncated by Planet PHP, read more at the original (another 15239 bytes)

Xdebug Update: March 2020 – Derick Rethans

Xdebug Update: March 2020

London, UK

Tuesday, April 7th 2020, 09:19 BST

Another month, another monthly update where I explain what happened with Xdebug development in this past month. It will be published on the first Tuesday after the 5th of each month. Patreon supporters will get it earlier, on the first of each month. You can become a patron here to support my work on Xdebug. If you are leading a team or company, then it is also possible to support Xdebug through a subscription.

In March, I worked on Xdebug for about 75 hours, on the following things:

Xdebug 2.9.3 and 2.9.4

The last month saw two releases. In Xdebug 2.9.3 I fixed an issue with breakpoint resolving. In files with a class that inherits from another class, the line start/end information from the inherited methods were incorrectly added to the lines map for the file with the extending class. This caused Xdebug to stop at confusing lines in some cases.

Xdebug overloads PHP’s internal error handler. As the hooks in the PHP engine aren’t great, Xdebug reimplements most of this. This code is liable for getting out of sync with how PHP itself handles errors. In Xdebug 2.9.3 I fixed such an issue, where a behavioural change in PHP 7.2 was not propagated to Xdebug’s reimplementation of the error handler.

Through a discussion with other PHP contributors I found out that Xdebug’s way of handling the overriding of opcodes (PHP Engine’s “instructions”) was not optimal. Other extensions also overload opcodes, such as Nikita’s scalar objects, or Xinchen’s taint. When Xdebug and one of these other opcode-overloading extensions are loaded at the same time, none of them would check whether they were also overloaded by another extension. In Xdebug 2.9.3 I fixed that, and this is now also resolved in taint, although the issue for scalar objects is still open.

Unfortunately this fixed introduced a crash for thread safe builds of PHP. I quickly released Xdebug 2.9.4 to rectify this problem after a number of reports.

Last month I mentioned that I merged a patch for Asynchronous Debugging Support into Xdebug’s master branch (which will become Xdebug 3.0). While doing some more work on this, in particularly towards making it less of a performance impact, I found a bug that was present in Xdebug for a long time: When an IDE uses the detach command, Xdebug would disable the remote debugger for the entire life time of the PHP process in use. This potentially explains lots of weird situations where debugger suddenly stopped working. This bug is also fixed in Xdebug 2.9.4.

Xdebug 3

I’ve been continuing to work on little improvements for Xdebug 3, such as adding Units to profiler output’s categories. This is a feature that was thought up when I did an Xdebug workshop last year at CHECK24. I expect to start with the refactoring of php.ini settings in April, as I am Staying Safe at Home, and pretty much have nothing else going on.

I’ve also continue to improve the dbgpClient and dbgpProxy tools, and made further progress on Xdebug Cloud.

Business Supporter Scheme and Funding

In March, no new supporters signed up.

If you, or your company, would also like to support Xdebug, head over to the support page!

Besides business support, I also maintain a Patreon page and a profile on GitHub sponsors.

Truncated by Planet PHP, read more at the original (another 847 bytes)

PHP Development: Using PHP Extensions

This blog:

PHP Internals News: Episode 47: Attributes v2 – Derick Rethans

PHP Internals News: Episode 47: Attributes v2

London, UK

Thursday, April 2nd 2020, 09:10 BST

In this episode of “PHP Internals News” I chat with Benjamin Eberlei (Twitter, GitHub, Website) about an RFC that he wrote, that would add Attributes to PHP.

Transcript

Derick Rethans 0:16: 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 47. Today I’m talking with Benjamin Eberlei about the attributes version 2 RFC. Hello, Benjamin, would you please introduce yourself?
Benjamin Eberlei 0:34: Hello, I’m Benjamin. I started contributing to PHP in more detail last year with my RFC on the extension to DOM. And I felt that the attributes thing was the next great or bigger thing that I should tackle because I would really like to work on this and I’ve been working on this sort of scope for a long time.
Derick Rethans 0:58: Although RFC startled attribute version two. There was actually never an attribute version one. What’s happening there?
Benjamin Eberlei 1:05: There was an attributes version one.
Derick Rethans 1:07: No, it was called annotations?
Benjamin Eberlei 1:08: No, it was called attributes. There were two RFCs. One was called annotations, I think it was from 2012 or 2013. And then in 2016, Dmitri had an RFC that was called the attributes, original attributes RFC.
Derick Rethans 1:25: So this is the version two. What is the difference between attributes and annotations?
Benjamin Eberlei 1:30: It’s just a naming. So essentially, different languages have this feature, which we probably explain in a bit. But different languages have this. And in Java, it’s called annotations. In languages that are maybe more closer home to PHP, so C#, C++, Rust, and Hack. It’s called attributes. And then Python and JavaScript also have it, that works a bit differently. And it’s called decorators there.
Derick Rethans 1:58: What are these attributes or annotations to begin with?
Benjamin Eberlei 2:01: They are a way to declare structured metadata on declarations of the language. So in PHP or in my RFC, this would be classes, class properties, class constants and regular functions. You could declare additional metadata there that sort of tags those declarations with specific additional machine readable information.
Derick Rethans 2:27: This is something that other languages have. And surely people that use PHP will have done something similar already anyway?
Benjamin Eberlei 2:35: PHP has this concept of doc block comments, which you can access through an API at runtime. They were originally I guess, added as part or of like sort of to support the PHP doc project which existed at that point to declare types on functions and everything. So this goes way back to the time when PHP didn’t have type hints and everything had to be documented everywhere so that you at least have roughly have an idea of what types would flow in and out of functions.
Derick Rethans 3:07: Why is that now no longer good enough?

Truncated by Planet PHP, read more at the original (another 19016 bytes)