Geierlein 0.8.0 released

Today I’ve released version 0.8.0 of Geierlein, the free Elster client written in HTML5 & JavaScript. Release aspects are, among others

  • bumping the Firefox MaxVersion to 41, to allow using it on the Firefox 41 XUL engine
  • upgrade of the included JavaScript crypto library Forge
  • switching over to RSAES-OAEP encryption scheme (from good old PKCS#7 scheme)

The encryption scheme switch on one hand was necessary, since the API will cease PKCS#7 support in April 2016, while currently supporting both schemes (actually since April 2015, when they opened the door for RSAES-OAEP). Besides that I wanted to make the switch early, since I consider going with better encryption is always the better option.

As Forge didn’t yet support RSAES-OAEP I spent some time implementing it back in August. My pull request on Forge unfortunately is still pending, as Dave is working on an upcoming API change.

Nevertheless Geierlein already ships the patch, so RSAES-OAEP/CMS is used from now on.

V8Js approaching PHP7

For some weeks now I had the idea that V8Js must be running on PHP7 the day it is officially published. So when I started out porting soon after they published he first release candidate (aka 7.0.0RC1) I felt some pressure, especially after noticing that it really will be a lot of work to do.

The more glad I am to announce today, that V8Js finally compiles fine and passes the whole test suite from the master branch (apart from tiny modifications that became necessary due to PHP 5.6 to PHP 7 incompatibilities).

Since it works now, I’ve moved the “php7” branch from my personal repository to the official V8Js Github repository meanwhile. Jenkins already is prepared as well, among others it now has a PHP7 V8Js matrix job, that currently checks all release candidates in combination with some V8 versions, regularly, on every commit.

Two more V8Js releases

Today as well as last Thursday I uploaded two more V8Js releases to PECL, both fixing issues around v8::FunctionTemplate usage that bit me at work.

Those v8::FunctionTemplate objects are used to construct constructor functions (and thus object templates) in V8. The problem with them? They are not object to garbage collection. So if we export a object with a method attached to it from PHP to JS, V8Js at first exports the object (and caches the v8::FunctionTemplate used to construct it; re-using it on subsequent export of the same class). If JS code wants to call the method first the named property is got, which exports a function object (via a v8::FunctionTemplate) to the JavaScript world – afterwards the function object is invoked. The problem: this v8::FunctionTemplate was not cached, hence re-created on each and every call of the method, of course leading to problems if functions are called thousands of times.

Version 0.2.4 fixes a related issue, regarding export of “normal” numeric arrays to JavaScript. Those are exported to Array-esque objects, that however do not share the normal Array prototype … the template needed to construct those was, once more, not cached … and hence lead to thousands of those templates lingering around unusable.

Poor V8Function call performance

Today I noticed, that invocations of V8Function objects have a really poor call performance. A simple example might be:

$v8 = new V8Js();
$func = $v8->executeString('(function() { print("Hello\\n"); });');

for($i = 0; $i < 1000; $i ++) {
    $func();
}

… on my laptop this takes 2.466 seconds (with latest V8Js 0.2.1); older versions like V8Js 0.1.5 even take 80 seconds.

That felt strange, since V8Js performance generally is pretty good and the slightly changed version

$v8 = new V8Js();
for($i = 0; $i < 1000; $i ++) {
    $v8->executeString('(function() { print("Hello World\\n"); })();');
}

… has drastically better performance figures, just 0.168 seconds with recent V8Js and 0.247 seconds with ancient 0.1.5.

So there clearly is something going wrong.

My pull request #159 shows the solution, V8Js was re-using cached v8::Context on subsequent executeString calls but kept creating new v8::Context instances for V8Function invocations. With the patch applied the first example now passes in 0.135 seconds, which is slightly better than the executeString performance (as expected).

After that huge improvement I released V8Js version 0.2.2, which also ships some memory leaks and errors mainly related to require() functionality.

Handyhalterung aus PET

Mein VW New Beetle hat werkseitig eine Handyvorbereitung … dafür gibt es für mehr oder weniger viel Geld auch Schalen, die man da reinklipsen kann … die dann das jeweilige Handy aufzunehmen versprechen.

Aber dafür jetzt nochmal Münzen einwerfen, zumal gut alle Jahr eh ein neues Handy folgt … weiß nicht. Und Fablab heißt ja auch selber machen.

Also OpenSCAD angeworfen und eine Handyhalterung gezeichnet, die einerseits mein Samsung Galaxy S5 aufnimmt und andererseits dem Clips-Mechanismus von VW genügt:

Screenshot Entwurf Handyhalterung, von vorn

Screenshot Entwurf Handyhalterung, von hinten

Foto vom Ergebnis

… das ganze dann auf den 3D Drucker gejagt. Als Filament habe ich PET verwendet — im Gegensatz zu PLA sollte das auch der direkten Sonneneinstrahlung im Auto längere Zeit trotzen. Und die Transparenz macht sich schon auch irgendwie gut …

Einige Fehlversuche später lässt sich das Ergebnis im Auto dann auch ansehen.

Learning des Abends: Wenn man im Cura eine „Pause at Z“ einstellt, dann die Parkposition niemals auf 0 / 0 stellen. Das führt dazu, dass der Druckkopf satt vorne links an den Anschlag läuft :-/ … zwar nicht mehr weit, sodass nicht wirklich was passiert (außer dass die Stepper Schritte verlieren und der Ausdruck dadurch Müll ist), aber trotzdem ein Schreckmoment …

php.net account approved

After waiting for a really long time (half a year) I finally have an approved php.net + PECL account granted with lead-rights on V8Js :-)

… therefore I finally published V8Js version 0.2.0, succeeding 0.1.5 which was published 1.5 years ago.

Changes include

  • adapt to latest v8 API (v8 versions from 3.24.6 up to latest 4.3 branch supported now)
  • v8 debugging support
  • apply time & memory limits to V8Function calls
  • support mapping of PHP objects implementing ArrayAccess to native arrays
  • new API to set limits: setTimeLimit & setMemoryLimit methods on V8Js object
  • typesafe JavaScript function wrappers
  • improved back-and-forth object passing (rewrapping, correcty isolate unlocking)
  • fix property and method visibility issues
  • fix memory leaks

Download the release from PECL repository.

Nervenfräse

Bernd war heute da und irgendwann kam die Idee auf, die CNC zu nutzen um seinen nickname auf einen USB-Stick zu gravieren.

Gesagt, versucht, gescheitert. Die Idee war zunächst mit Inkscape den Schriftzug zu erstellen und den Pfad als G-Code zu exportieren. PyPC-NC hat den Schriftzug ein bisschen verstümmelt:

Foto 1. Versuch

Wie sich beim Debuggen zeigte war die Polar-Koordinaten gestützte Korrektur noch nicht fehlerfrei. Nach einigen Versuchen sah es dann deutlich besser aus:

Foto ein paar Versuche später

… der letzte Versuch mit einem Streckfaktor von zwei und phi von 45°.

Polar-korrigiertes Fräsen und Bohren

… immer noch auf dem Weg zur selbst erstellten Platine, genauer gesagt beim Bohren eben dieser. Kürzlich bin ich noch über das Problem gestoßen, dass man die Platine exakt gerade in die Fräse einlegen muss, dass die Bohrlöcher auch an der richtigen Stelle im Epoxyd landen und nicht etwa ein paar Millimeter daneben. Das ist aber gar nicht so einfach …

… die „Softie“-Lösung, bevor ich mir Mühe mit der „Hardware“ geb‘, arbeite ich doch lieber mit Software um das Problem herum.

Gegeben sei also eine Platine (hier eine „Simulation“ in Form eines simplen A4-Blatts), die nicht exakt gerade in der Fräse liegt, etwa so:

Foto schief eingelegtes Frässtück

… dann muss man dem Controller der Fräse nur noch beibringen, wo zwei frei gewählte Punkte aus dem G-Code in der Realität liegen. PyPC-NC ermittelt daraus mittels Polarkoordinaten dann zwei Korrekturwerte: um wieviel Grad muss gedreht werden und um welchen Faktor ist der Radius zu korrigieren.

Screenshot von PyPC-NC mit Polar Fix

… bei der Gelegenheit ist für PyPC-NC eine grafische Darstellung des G-Codes auf der XY-Plane abgefallen nebst der Möglichkeit den Ursprung der G-Code Datei nach belieben fest zu legen.