Scraping content from other sites (while slightly controversial) can be a helpful way to pull information into your application without the overhead of manual interaction. In this new post to his site Sameer Borate shows how to use a DOM parser to extract data from a remote site.

In this post I have explained some elements to scrap data from external websites. Simple HTML DOM parser is a PHP 5+ class which is useful to manipulate HTML elements. This class can work with both valid HTML and HTML pages that do not pass W3C validation. You can find elements by ids, classes, tags and many more. You can also add, delete or alter DOM elements. The only one thing you should care about is memory leaks – but you can avoid memory leaks as explained later.

He starts by walking through some of the basics of creating a new instance of the class and loading the content (either as a string or as a file) to be parsed. He then give several examples of how to query the contents of the document and locate multiple or single elements (including the use of CSS-type selectors for fuzzy attribute matching). He finishes out the post showing how to access element attributes and append content back to the original HTML.

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).

The SitePoint PHP blog has a new tutorial posted from author Marcello Duarte showing you how to use functional programming techniques in your applications with the help of the Phunkie library. Phunkie is a library that brings functional programming functionality to PHP. This article was originally published on the Inviqa blog.

In the first part of this series we explored parsers and combinators to help you start getting values from functional programming with PHP. We covered the basics using examples, and now we’ll move onto more sequencing and other strategies.

Continuing on, they work towards the goal of making a more useful end result, a JSON parser that returns a JsonObject. First, though, he goes through several different combinators, showing code examples for each: sequencing, choice, and recursive. He also covers the repetition pattern and how to integrate separators. Finally, with this groundwork laid, he gets to the JSON parser showing each step of the way, from reading in the JSON string to returning the object.

The SitePoint PHP blog has posted a tutorial by Marcello Duarte showing you how to use functional programming in PHP with the help of the Phunkie library.

Phunkie is a library with functional structures for PHP. In this tutorial, Phunkie creator Marcello Duarte, head of training at Inviqa, explains how to create Parser combinators using the functional library.

[...] Learning functional programming means immersing yourself in a new paradigm, which can be challenging. It requires a totally different mindset for approaching problems. So, by the time you can use functional programming to solve real-world problems, you’ll have spent hours grasping the new thinking or getting clued-up on the theory.

In this tutorial, my aim is to help fast-track your journey by going over my implementation of Hutton & Meijer’s Monadic Parser Combinators.

He starts off by defining two terms that will be used through out the code: parsers and combinators. He shares a code example of a combinator and then moves on to examples of primitive parsers and parser combinators. Each section includes the code you'll need to use (making use of Phunkie) to make the functional magic happen.

In this post to his site PHP (core) developer Joe Watkins talks about "hacking PHP 7" based on two screencasts he's made on the subject.

Writing extensions is fun, but it's not as fun as hacking PHP. So, we're going to focus on hacking, we're going to imagine that we are introducing some new language feature, by RFC.

Without focusing on the RFC process itself, you need to know which are the relevant parts of PHP you need to change, in order to introduce new language features. You also need to know how PHP 7 works, about each stage of turning text into Zend opcodes.

After talking a bit about some of his thoughts and troubles with screencasting in general he looks at "The Beginning" of PHP's translation from text to functionality: the lexing. He introduces the basic concept around how a lexer works and how it migrates the pieces over to tokens. He then starts in on the parsing of these tokens and, finally, the AST (abstract syntax tree) resulting from the combination of these pieces, executed against a piece of code.

With that out of the way, he starts in about the "hack" - a hipster expression that only works with strings and throws an exception otherwise. He shows the pieces he had to edit to create this new expression and it's matching token/AST node.

If you've ever worked with the "cron" tool on a unix-based system, you know that there's a special syntax that comes along with defining when the commands should run. It can be difficult to get this timing exactly right, especially if you're very picky about the execution time. In this post from Sameer Borate he shows you a PHP library that can help not only parse current cron configurations but also provides shortcuts for common timings (ex: "daily" or "weekly").

Working with cron scheduling can many times be a frustrating affair. Although setting a few cron jobs at one time can be easy, calculating cron dates in the future in code can get time consuming quickly. The PHP cron expression parser described here can parse a CRON expression, determine if it is due to run, calculate the next run date of the expression or calculate the previous run date of the expression. You can calculate dates far into the future or past by skipping n number of matching dates.

He includes some examples of putting the library to use to define a cron object based on an expression (either via a shortcut or an actual cron time expression). You can then check to see if the cron is "due" or perform some various operations about its run dates. This includes a formatted output of the previous run time, the next run time and the calculation of the next/previous run time based on a relative timestamp.

Anthony Ferrara has a new post, following up from his previous look at tries and lexers, continuing along the path to apply what he learned to a HTTP routing system.

In my last post, Tries and Lexers, I talked about an experiment I was doing related to parsing of JavaScript code. By the end of the post I had shifted to wanting to build a HTTP router using the techniques that I learned. Let's continue where we left off...

He starts off with thinking that lexing and parsing the routes out into their respective tokens instead of breaking them up as many do (i.e. splitting on the slashes). He shows the results of this lexing and some parser code to handle these results and turn them into something useful. He did find that the current setup caused a lot of overhead (255 new states per character) so he optimizes the processing with a "default" trie but it was still pretty intensive.

He decided to go a different way at this point, opting for the radix tree structure instead. He includes the implementation of this tree for parsing the routes and his matching lexer updates. Finally he shows how to apply code generation to the results of these changes and how coming back to the "slash splitting" could help...

Anthony Ferrara has an interesting new post to his site talking about tries and lexers, two pieces of a puzzle that are used during script execution. In this case, he's tried his hand at writing a parser which, naturally, lead to needing a lexer.

Lately I have been playing around with a few experimental projects. The current one started when I tried to make a templating engine. Not just an ordinary one, but one that understood the context of a variable so it could encode/escape it properly. [...] So, while working on the templating engine, I needed to build a parser. Well, actually, I needed to build 4 parsers. [...] I decided to hand write this dual-mode parser. It went a lot easier than I expected. In a few hours, I had the prototype built which could fully parse Twig-style syntax (or a subset of it) including a more-or-less standards-compliant HTML parser. [...] But I ran into a problem. I didn't have a lexer...

He starts with a brief description of what a lexer is and provides a simple example of an expression and how it would be parsed into its tokens. He then talks about the trie, a method for "walking" the input and representing the results in a tree structure. He shows a simple implementation of it in PHP, iterating over a set of tokens and the array results it produces. He then takes this and expands it out a bit into a "lex" function that iterates over the string and compiles the found tokens.

From there he comes back to the subject of Javascript, pointing out that it's a lot looser than PHP in how it even just allows numbers to be defined. His testing showed a major issue though - memory consumption. He found that a regular expression method consumed too much and tried compiling out to classes instead (and found it much faster once the process was going).

Sherif Ramadan has a post looking at creating a better operator precedence parser in PHP. His example is a fully PHP implementation that takes equation strings and evaluates them to create the result.

Operator precedence parsers are very simple on the surface. So don’t feel in the least bit intimidated, because by the time you’ve read through this I hope to have you walk away with a solid foundation on how to write your very own operator precedence parser. The goal is to understand how to solve the problem of operator precedence parsing, and not necessarily to write your own parser. Learning how the problem can be solved is the most important thing to take away from this article.

He starts with an introduction to the concepts behind "operator precedence" including processing order and grouping. He also mentions infix and postfix (RPN) notations for handling different formats of equations. He used the "Shunting-yard Algorithm" and how it relates to handling the different parts of the equation, one at a time, in the correct order. He rest of the post is dedicated to the details of the execution in the tool, including code examples and the tokenization of the strings passed into it.

On the Ibuildings blog today they've released the latest episode of their DPC Radio podcast series as recorded at this year's Dutch PHP Conference (2012). In this new episode, they share Boy Baukema's session "Let's Build a Parser".

During this talk an introduction will be given to parsing. Terms like 'formal grammar', 'lexing / scanning', 'LL / LALR / PEG' will be explained and put into context. We will look at a recursive descent parsing as a practical way to parse languages. Finally the audience will be left with ways to get started with parsing structured text into memory.

You can listen to this latest episode either through the in-page player or by downloading the mp3. You can also see the slides from the presentation on Slideshare.