Looks as if we have the next member in the "I want to become Caliph instead of the Caliph" club: PHPreboot

This is just a braindump of thoughts on the various bullet points and examples on the projects home page (but i don't think it's worth any more time to analyze it and comment on it either):

• less $, less ';' like in javascript

Not sure whether this is really an improvement, while $ and ; are not really necessary from a parsers (or lazy typers) point of view they do carry some context information ... so this is breaking the "The burden shall be on the writer, not the readers" principle IMHO

• secure by default: no eval, no magic quotes/string interpolation

Yes, that's all that needs to be disabled to guarantee secure code ... NOT

Magic quotes were a bad idea, but for slightly different reasons. eval() by itself is not a bad idea either if used properly, same as with backticks, system(), popen(), ...

And just by disabling magic quotes and eval() you do not make code secure by default, XSS and SQL injections can still happen without these, and i'd bet that most malicious code injections in vulnerable PHP apps were not using eval() but include/require as attack vector to make PHP execute their own code ... want to forbid these, too?

• full unicode support

That's a good thing, we may just have different ideas of "full" ...

• no from/to string auto-conversion

I do like the "to" part of it ... not really sure about the "from" part ...

• a SQL compatible syntax

Which SQL dialect? And looking at the code: how would i handle queries against multiple database connections?

• Perl 5 regex literal

I personally prefer to write preg_match() literally ... but that may be just me and my PERL allergy ...

• URI/file literal

I don't see that much gain in that one over explicit fopen(), ... calls either

• fast as Java thanks to a runtime profiler/optimizer and JSR 292 API

There's room for improvement in PHP optimizers and op code caches for sure ...

In my personal use cases a JVM based PHP would actually be a loss though. Most stuff i'm using PHP for these days is medium complex command line stuff (like my code generators), and for most of this my PHP scripts are already done with their job in a time that would not even be sufficient for a JVM to initialize and execute the very first byte code op of my user code

There's also the more general issue that when going the way of the JVM you either go bytecode all the way and have to say goodbye to all the PHP extensions that are actually just thin wrappers around native C libraries, re-implement those libraries functionality in a language supported by the JVM or go the way of JNI ...

• provide an embedded database derby and a standalone web server grizzly by default

... instead of SQLite and ?forgot-the-name-of-the-upcoming-integrated-webserver-thingy? ...?

• native XML syntax

Sorry, can't see how that's "native XML syntax", PHP and its use of XML processing instruction syntax is as native as you can get, hiding executable code in DATA not so much

• Language as close as possible to PHP

Sorry but even that simple example does not really look like PHP to me as all. Maybe part of that is due to the use of "elseif" instead of "else if". I haven't seen any PHP code using "elseif" in years, i even had to double check that it works in this context and not just in the IF: ... ELSEIF: ... ENDIF; form.

• native XQuery

Again i'm not sure whether i want to have that on the Syntax level ...

• [...]

So to summarize:

• the language does hardly look like PHP anymore (actually looks more like a PERL/Python chimera to me personally)
• the language will not be backwards compatible to PHP syntax wise (afaict)
• the language will not have many of the functionality that PHP gets from native C libraries

=> so why should it have the letters PHP in its name at all?

For testing some stuff related to MySQL Cluster, port binding and having two network interfaces on the same subnet i needed a bit more than my usual "all nodes on localhost" setup. Looking for a reusable solution i this time did not just simply plug several of my old laptops into the same hup but tried to create a Vagrant setup for this.

This quickly lead to the question how to define multiple network adapters per Vagrant VM. The manual is not too clear about this yet, and the key piece of information is not yet to be seen in the network section but is hiding in the section on port forwarding: the :adapter option.

So to define multiple adapters you need to add :adapter => $value options on each of the vm.network lines, with $value counting up from one, e.g.:

config.vm.network("33.33.33.10", :adapter => 1);
config.vm.network("33.33.33.20", :adapter => 2);

In my case i need both adapters to be on the same IP subnet. Vagrant (or VirtualBox?) is not clever enough for this yet and will create two distinct host-only networks for this, routing and binding works as expected though as the kernels inside the VMs do not care about (and are not even aware of) this.

Found this while waiting for the CSV export of a search result from (*undisclosed project*) ...

The export took almost half an hour even though it was just extracting the snail mail addresses of about 40K contacts, so what caused it to only spit out about 20 rows per second? Looking at the PROCESSLIST output a pattern was easy to detect. What greeted me was a single running query which had only been running for a few seconds even though i was already waiting for export results for about 20 minutes:

SELECT ... LIMIT 32900, 100;

And then a few seconds later:

SELECT ... LIMIT 33000, 100;

So instead of retrieving the search results for export by firing a single query and processing the results in one go the same pagination logic seemed to be used as for displaying search results. About 400 queries instead of a single one, and each iteration taking more query time, with finally the last one taking about the same time as the only query in the all-at-once alone.

Somewhere, somehow, something terribly went wrong it seems ....

With the changes i recently committed to the OSM SVN repository osm2pgsql can now read OSM files in the new binary PBF format directly (with parsing code based on that found in pbf2osm). Files in PBF format are available from the geofabrik download site along with their XML counterparts and are usually about 30% smaller than bzip2 compressed XML. osm2pgsql also parses PBF about twice as fast, so substantially reducing the time taken for the first processing step.

Also part of my committed changes are an improved autotools setup that checks for library and header file availability in the configure stage already, and that only includes PBF support if the needed GNU ProtoBuffer related tools and libraries are available.

Unfortunately the PBF code requires at least protobuf-c 0.14, which is not yet part of current distributions, so you'll have to install that one from source yourself. But with proper configure checks in place you'll be at least warned about version mismatches here and osm2pgsql will be built without PBF support then.