TValueList = array of TValue;
  TValue = object
    FList: TValueList;
    SomeOtherStuff: integer;
  end;

(Für später geborene: das ist die alte Syntax für “record mit Methoden”.)

Leider nimmt uns der Compiler das so nicht ab. Warum? Weil TValue natürlich vorher noch nicht bekannt ist. Und im Gegensatz zu Klassen kann man Records nicht vorwärtsdeklarieren. Wie also könnten wir dieses Problem lösen? Man könnte Pointer verwenden, und bei Verwendung entsprechend erzeugen. Aber freigeben? Es gibt ja keinen Destructor, also keine Option. Man könnte das gesamte Objekt in eine Klassen-Instanz verwandeln, die von IUnknown die Referenzzählung erbt. Das ist aber wesentlich mehr Aufwand als das bisherige “Deklarieren und Verwenden”.

Die Lösung hier zeigt sich in einem fiesen, aber einfachen Hack:

TValueListAlias = array of boolean;
TValue = object
  FList: TValueListAlias;
  SomeOtherStuff: integer;
end;
TValueList = array of TValue;

Dabei spielt es keine Rolle, welchen Basistypen man für das Alias verwendet. Es muss sich nur um ein dynamisches Array handeln. Jetzt kann man in jedem Zugriff auf das eigentliche TValueList casten und alles funktioniert. Dabei kann man die Hässlichkeiten wunderbar in Zugriffsmethoden verbergen.

SetLength(TValueList(FList), 42);

Das funktioniert auch, aber wenn TValue nun Felder die finialisiert werden müssen enthält, wird sich FastMM beschweren, dass eben diese nie freigegeben werden. Es stellt sich heraus, dass SetLength zwar den BaseType richtig speichert und auch in @DynArrayClear exakt diesen wieder beräumt, aber Felder im Gegensatz zu Variablen nicht damit, sondern mit FinalizeArray freigegeben werden. Und dieses richtet sich nach der Deklaration, nicht nach dem was wirklich passiert.

Hier kommt dann der eigentliche Grund für diesen Beitrag: wir sagen der RTL einfach: “Vertrau mir, das ist ein anderer Datentyp!”. Mit anderen Worten: wir patchen die Feld-Tabelle der betroffenen Klasse so, dass FinalizeArray dort ein TValueList (BaseType also TValue, nicht unser Dummy von weiter oben) sieht und dieses korrekt finalisiert.

Das ist zunächst einfacher als gedacht:

TI:= TypeInfo(TValue);
FT := Pointer(Integer(TI) + Byte(TI.Name[0]));
for I := FT.Count-1 downto 0 do begin
  if FT.Fields[I].TypeInfo^ = TypeInfo(TValueListAlias) then
    ppti:= FT.Fields[I].TypeInfo^:= TypeInfo(TValueList);
end;

Nur – das funktioniert so nicht Runtime Error 216 ist die Folge einer Exception beim Schreiben der neuen TypeInfo. Da hat nämlich mal jemand mitgedacht und die dazugehörige Seite als PAGE_EXECUTE_READ markiert. Was man zum Glück in seinem eigenen Prozess beliebig ändern kann, und so ergibt sich (mit allen Deklarationen) folgendes Meisterwerk:

procedure FixFieldTable(TheRecord, Find, Replace: PTypeInfo);
type
  TFieldInfo = packed record
    TypeInfo: PPTypeInfo;
    Offset: Cardinal;
  end;
 
  PFieldTable = ^TFieldTable;
  TFieldTable = packed record
    X: Word;
    Size: Cardinal;
    Count: Cardinal;
    Fields: array [0..0] of TFieldInfo;
  end;
var
  FT: PFieldTable;
  ppti: PPTypeInfo;
  I, old, dummy: cardinal;
begin
  FT := Pointer(Integer(TheRecord) + Byte(TheRecord.Name[0]));
  for I := FT.Count-1 downto 0 do begin
    if FT.Fields[I].TypeInfo^ = Find then begin
      ppti:= FT.Fields[I].TypeInfo;
      VirtualProtect(ppti,SizeOf(ppti), PAGE_READWRITE, old);
      try
        ppti^:= Replace;
      finally
        VirtualProtect(ppti, sizeof(ppti), old, dummy);
      end;
    end;
  end;
end;
{...}
 
  FixFieldTable(TypeInfo(TValue), TypeInfo(TValueListAlias), TypeInfo(TValueList));

Wer sich die Datenstruktur ansieht, wird feststellen dass TFieldTable ein Feld namens “Size” enthält. Sollten wir das nicht anpassen? Die einfache Antwort ist: nein! In TValue selbst wird vom dynamischen Array nur ein Pointer auf den Anfang gespeichert, und der ist unabhängig vom genauen Aussehen des Arrays immer gleich groß: nämlich 32bit oder 4 Byte. Es ändert sich also nichts.
Außerdem praktisch: da SetLength den Array-Typ anlegt, den man ihm übergibt (und wir ja auf TValueList casten), werden auch untergeordnete Arrays als das freigegeben was in ihnen steckt.

Das funktioniert so bis mindestens BDS2006, ich kann mir aber vorstellen dass die neuen RTTI-Strukturen in XE hier einige Änderungen notwendig machen. Das müssen dann aber andere testen

Oh, übrigens, wer es nicht erkannt hat: der Titel ist natürlich eine Referenz auf Disney’s Dschungelbuch.

Man nehme z.B. eine KI mit Negamax+AlphaBeta, die immer irgendwelche völlig behämmerten Züge ausführt. Irgendwann ist mir dann mal gedämmert, dass man sich ja mal die Score-Werte ausgeben lassen könnte.

next move
  h1 to g1 score: 9
  h1 to g2 score: 9
  h1 to i2 score: 9
  h1 to h2 score: 9
  h1 to f1 score: 9
  h1 to f3 score: 9
  h1 to h3 score: 9
  i1 to h2 score: 9
  i1 to i2 score: 9
  i1 to g1 score: 9
  i1 to g3 score: 9
  i1 to i3 score: 9
  a9 to b8 score: 9
  a9 to b9 score: 9
  a9 to a8 score: 9
  a9 to c7 score: 9
  a9 to c9 score: 9
  a9 to a7 score: 9

Huch! Alles das gleiche. Wie kann das sein?

    function Score(ABoard: TBoard; Perspective: TField): TScore;
{...}
          if Board[c,r]=Perspective then
{...}

M( M( M( M( M( M( M(

Board ist ein Member von TGame, und damit an dieser Stelle durchaus ein gültiger Bezeichner. Nur leider nicht der den ich will, denn damit habe ich immer das Brett vom Startpunkt bewertet, niemals das nach einem Zug. Sehr schön, es sollte mal einer intelligente Compiler entwickeln, die mir sowas direkt sagen…

gnuplot hält sich für ein sehr gutes Diagramm-Plot-Programm – und das stimmt meistens auch. Wenn es darum geht, Daten aus Dateien einzulesen wird das Skript zwar sehr schnell sehr hässlich, aber es funktioniert. Zumindest, wenn man die Daten vorkocht, denn filtern kann man sie in gnuplot selbst nicht mehr vernünftig. Das ist aber grade dann von Nöten, wenn man lange Messreihen hat, aber zum Beispiel nur an den letzten N Messwerten interessiert ist. Eigentlich doch ein nicht grade seltenes Problem, aber fertige Lösungen jenseits von `tail -n` sind nicht wirklich auffindbar.

Noch wesentlich haariger wird das Thema, sobald man einen Zeitstempel drin hat. Nun ist zwar gnuplot per

set xdata time
set timefmt "%s"

sehr gut in der Lage das zu lesen und richtig darzustellen, aber irgendwas damit anfangen kann man nicht.

Hier muss also ein separates Programm her… und weil ein Programm da vielleicht etwas Overkill wäre, können wir doch das auch mit Shell-Foo (Wie heißt das auf Windows? cmd-foo?) lösen, oder? Klar können wir das

@echo off
setlocal
set show_last_seconds=43200
set tmx=
set tmi=
for /F "usebackq delims=;" %%i in (`tail -n 1 values.log`) do set tmx=%%i
set /a tmi=tmx-show_last_seconds
del akku.csv >nul 2>nul
for /F "tokens=1* delims=;" %%i in (values.log) do (
  if /I %%i GTR %tmi% (
    echo %%i;%%j>>akku.csv
  )
)
..binwgnuplot akku.plt
start akku.png

Kurzerklärung: das Skript sucht sich zuerst die letzte Zeile. Da cmd.exe nicht anders Strings parsen kann, muss hier for ran – eine Schleife über genau einen CSV-Datensatz. Davon wird dann die anzuzeigende Zeit subtrahiert (hier 4 Stunden) und in Folge alle Sätze der Quelldatei geprüft, ob sie neuer sind als diese Grenzzeit. Tun das, gehts ab in die gefilterte Datei, die ein einfaches gnuplot-Skript zur Grafik macht.

(Referenz im Titel)

Unser Institut für Mechanik hat für Belege und Praktika ein schickes kleines Delphi-Programm, welches die Aufgabenblätter generieren kann. Das ganze hat den Zweck, dass die Aufgaben sich mit der Matrikelnummer personalisieren lassen (RandSeed) und man seine berechneten Werte mittels dieses Programms direkt auf Korrektheit prüfen lassen kann.

Nun sind die Aufgaben nicht immer so ganz ohne, und manchmal hilft es ungemein, nicht nur Eingabefelder zu haben, die einem sagen ob man richtig oder falsch lag, sondern auch mal spicken zu können, wo denn der Fehler liegt.

Aber erstmal eine kleine Anekdote.
Man sitzt also in einer Vorlesung, und macht nebenbei mit einem Kommilitonen ein solches Übungsbelegblatt. Die Gleichungen sehen auch erstmal alle ganz schön aus. Nun hat man ja einen Laptop dabei, kann also die Ergebnisse kontrollieren. Und siehe da: nix passt.
Was tut man also? Man versucht herauszubekommen, was das Programm denn als Zahlenwert erwartet. Irgendwie dachte ich mir (warum, weiß ich auch nicht; vielleicht wars ja Schicksal ) dass mir ein Hex-Editor weiterhelfen könnte. Konnte er natürlich nicht, hat aber soweit geholfen, als dass ich festgestllt habe, dass es zu jedem Aufgabenblatt 2 Definitionen gibt. Eine generiert die Aufgabenstellung, und eine generiert… Moment. Was ist das? Ein Lösungsweg!
Es gibt also nicht nur 2 Programmversionen (wie schon das _student im Dateinamen vermuten lässt), sondern zu allem Überfluss enthält die selbe Echse offenbar beide Teile. Irgendwo muss also umgeschaltet werden, was gemacht werden soll.

Nachdem man seinen IDA Pro wiedergefunden und gestartet hat, wird also mal das Programm hineingeworfen. Etwas warten, und die Programmstelle wieder finden. Das macht sich recht einfach, immerhin ist der Titel des Belegs ein sehr eindeutiges Merkmal (im Code-Segment jedenfalls). Nun muss man nur noch die XRefs zurückverfolgen, um rauszubekommen wo der wichtige Aufruf erfolgt. Der ist nämlich da, wo basierend auf einem Vergleich der eine oder andere Zweig (=Ausgabeanweisungen) aufgerufen wird. It always boils down to a simple comparision.
Der letzte Schritt (wo allerdings leider die Vorlesung zuende war; der Teil mit dem “IDA wiederfinden” hatte etwas lange gedauert) ist es nun nur noch, die Zuweisung an die überprüfte Variable zu finden. Auch hier hilft wieder die XRefs-Funktion. Es gibt nämlich nur eine, und die schreibt eine $00, also den Ordinalwert für false. Man könnte also sagen, die betreffende Variable ist sowas wie IsTutorenVersion.
Kurzer Patch in der Exe der (wir wissen ja: es ist Delphi) eine $01 (für true) stattdessen schreibt, und fertig.

Wer das liest und ein berechtigtes Interesse hat, der hat auch Wege mich nach dem Teil zu fragen. Das ist nun grade ein Hack, bei dem ich garantiert kein Responsible Disclosure machen werde. Das wäre nämlich sehr verantwortungslos. Mir selbst gegenüber

Das wars erstmal von meiner Seite,
Martok

Das heißt auch, dass die bisher im Edgemonkey verwendete Kombination von eval/uneval zur (de)serialisierung von Einstellung und Speicherung dieser so in Chrome nie funktionieren wird (selbst wenn später einmal eine GM_setValue-Alternative zur Verfügung steht – stay tuned). Es muss also jedes Vorkommen davon durch die eigentlich viel schöneren und moderneren JSON.parse und JSON.stringify ersetzt werden. Was aber nicht so einfach ist, da die Migration bisheriger Daten natürlich funktionieren muss.
Was gar nicht so einfach ist – uneval erzeugt kein JSON, sondern nur etwas was so ähnlich aussieht!

Man muss also etwas tun, um die Daten in valides JSON zu konvertieren. Was nicht einfach geht, ohne uneval. Bleibt also nur, den String als solchen zu bearbeiten. And here’s how:

JSON.convertFromUneval = function(u) {
  function protect(s) {
    return s.replace(/./g, function(m) {
      return '#'+m.charCodeAt(0).toString(16);
    })
  }
  function unprotect(s) {
    return s.replace(/#([a-f0-9]+)/g, function(m,c) {
      return String.fromCharCode(parseInt(c,16))
    })
  }
 
  return u.
    // remove outer braces
    match(/^((.*))$/)[1].
    // protect strings
    replace(/(?::"")|(?::"(.*?)([^\]"))/g,function(m,g1,g2) {
      return ':"'+(isUndef(g2)?'':protect(g1+g2.charAt(0)))+'"';
    }).
    // prepare unquoted param names using single ticks
    replace(/([{,])s*([^:'{,]+?):/g,function(g,g1,g2) {
      return g1+"'"+g2+"':";
    }).
    // remove undefined, JSON has no notation of that data type
    replace(/([,{])s?'(?:[^']|(?:(?:\\)*\'))*':(void 0)([,}])?/g,function(g,g1,g2) {
      return ((g1!=='{')?g1='':g1) + ((g1 && g2!=='}')?'':g2);
    }).
    // turn single into double tics
    replace(/'(.+?)':/g,function(g,g1) {
      return '"'+g1.replace(/\'/g,"'").replace(/"/g,'\"')+'":';
    }).
    // unprotect strings (unwind x sequences: JSON as a Unicode standard doesn't have ASCII escapes)
    // and do that w/o lookbehinds, which would be waaaay to easy
    replace(/:"((#[a-f0-9]+)+)"/g,function(m,t) {
      return ':"'+unprotect(t).replace(/(?:(?:\\)*\)*(\x([0-9A-F]{2}))/g, function(m,g1,g2) {
        return (m.length%2)?m:m.replace(g1,String.fromCharCode(parseInt(g2,16)));
      })+'"';
    })
}
 
JSON.parseUneval = function(u) {
  return JSON.parse(JSON.convertFromUneval(u));
}

Ist diesmal sogar kommentiert, da brauch ich gar nichts weiter schreiben. Schön! Man könnte das ganze zwar sogar noch weiter einkürzen, aber wer will das schon – soll ja auch noch lesbar sein.
Was jetzt noch zu tun bliebe, wäre JSON (oder uneval’d code) zweifelsfrei erkennen – aber hier werde ich wohl trial&error nutzen: “Wenn es sich nicht als JSON parsen lässt, wirds wohl was anderes sein”. Soll sich doch Spidermonkey damit rumärgern!

Dieser Schnipsel steht wie der Rest des Affen unter CC-BY-NC-SA. Ergänzungen und Fixes willkommen, sollte z.B. mein Test-Objekt noch seltsame Sachen nicht enthalten!

Update: Kommentator BenBE hatte doch richtig vermutet: da war noch einiges holprig drin. Ein 316kByte-Datengewusel ist halt doch ein besserer Testcase als etwas konstruiertes
Der String-protect-Teil ist nach wie vor nicht wirklich korrekt, wie jeder einfache Testcase zeigt. Bis zum Beweis des Gegenteils hoffe ich aber, dass es für den Affen reicht.

So ist das bereits mehrmals passiert – die neue Sandbox der Greasemonkey 0.8-Reihe war wohl das offensichtlichste. Aber das war ja noch einfach zu umgehen. Richtig spaßig ist das aber erst viel später auf Firefox 4 geworden, welcher mich auch dazu gebracht hat die hier besprochene Thematik mal genauer zu analysieren.

Wie alles anfing…
Grundsätzlich bestehen die Foren der Entwickler-Ecke meistens aus mehreren Frames. Für viele User ist dabei mindestens die Shoutbox ein IFRAME, zusätzlich existiert auf den “Beitrag beantworten”-Seiten eine Kurzansicht der letzten paar Beiträge (“Topicreview”). Dieser Aufbau stellt Userscripts vor einige Hürden, werden sie doch für jede Seite separat ausgeführt – ab GM 0.8 eben sogar in einer getrennten Sandbox, die verhindern soll dass sich Webseiten über den GM Chrome-Privilegien holen können. Man möchte aber an einigen Stellen, dass die Scripte zusammenarbeiten können und Funktionen sowie Daten gemeinsam nutzen.

Erster Ansatz
De Grundidee war nun, dass das zuerst geladene Frame (meistens wohl das Hauptfenster) eine Variable EM in das window injeziert. Später geladene Frames suchen in ihrem window.parent dann danach und weisen dieses Objekt einer eigenen Variable zu:

if (SOP_ok && !isEmpty(unsafeWindow.parent.EM)) {
  window.EM = unsafeWindow.parent.EM;
  unsafeWindow.EM = EM;
} else {
  window.EM = {};
  unsafeWindow.EM = EM;
}

Dies muss man natürlich immer zweimal tun: einmal für das window aus der Sandbox und einmal für das externe unsafeWindow.

Diese Variante hat gut funktioniert, bis Firefox 4 kam. Dieser erzeugt bei der genutzten Funktion evalInSandbox noch einen weiteren Kontext, so dass window nicht mehr das globale Objekt ist. Damit ändert sich das Verhalten des Codes signifikant, so dass nach ausführung des oberen Blocks

var foo= EM;

nicht funktionieren wird – EM ist undefined, window.EM wäre es nicht.

Damit war die bisherige Technologie ein Fall für gründliches Überdenken. Mit dem netten Nebeneffekt, dass gleich noch ein weiterer Fehler gefunden wurde. Leider ein konzeptioneller, denn diese Methode hat ziemliche Probleme damit, dass das Topicreview auch eine Pagehacks-Instanz hat. Diese überschreibt dann die der Hauptseite. Nicht gut das ist. Transparenter du denken musst, junger Padawan!

How it should have worked…
Dann ist mir etwas eingefallen, was ich vor der Lektüre von Crockford’s The Good Parts zwar wusste, aber nicht wirklich angewendet hatte: JavaScripts Prototypische Vererbung. In a nutshell bedeutet diese, dass ein Objekt zuerst nachsieht, ob es eine Eigenschaft selbst enthält, dann bei seinem Protoypten, dann bei dessen Prototypen etc., bis Object() dann keinen mehr hat.
Dies kann man nutzen, um bestimmte Eigenschaften global zu machen und andere Privat zu halten. Praktischerweise lässt einen die Mozilla-JS-Engine auch an das dafür verwendete __proto__-Pseudoproperty ran, so dass man schreiben kann (nicht wörtlich so, aber die Idee kommt so besser rüber als im Orignalcode, welcher noch Code enthält um auf Fertigstellung zu warten):

var newEM = {};
if (SOP_ok && !isEmpty(unsafeWindow.parent.EM)) {
  newEM.__proto__ = unsafeWindow.parent.EM.__proto__;
} else {
  newEM.__proto__ = {};
}
window.EM = newEM;
unsafeWindow.EM = newEM;

Dann gilt für jedes Frame:

EM.__proto__.foo=42; // ist danach überall sichtbar
EM.bar=23; // nur dieses Frame hat die Variable. Andere könnten EM.bar auch als 5 deklarieren!

Womit das Ziel erreicht wäre: es ist möglich, Felder zwischen Frames zu teilen. Es ist aber auch möglich, private Felder zu deklarieren.
Nun funktioniert dieser Ansatz sehr schön direkt im Browser, als ClientSide-Script. Aber als Greasemonkey-Script… nunja, ich weiß nicht was da passiert, aber es ist etwas anderes. Wer möchte, kann sich das im Proof Of Concept ansehen.

… and what we did instead
Nun ist das Problem nicht ganz unbekannt, weswegen mal jemand den Content Scope Runner erfunden hat. Keine Rocket Surgery, aber schon soweit genial dass einfach der Code ins DOM injiziert wird und damit im Content Scope läuft. Nett, aber wir brauchen ja die Chrome-Privilegien die uns GM gibt.

Die Lösung ist nun, beide Techniken zu kombinieren: Die Objekt-Verlinkung passiert im Content Scope, der Rest des Scripts läuft wie gewohnt als Userscript. Dies erfordert etwas mehr Aufwand, da die jeweiligen Warteschleifen natürlich auch mit gebaut werden müssen.

Der Loader an sich wird relativ einfach, da alles in 2 Unterfunktionen gemacht wird. Env wird vorher mit Informationen über die Umgebung gefüllt, Env.parentName enthält dann Bezeichner wie “window.parent”.

  if (Env.isSOPPass) {
    injectInitCode(Env.parentName);
    waitForObject(false);
  } else {
    injectInitCode();
    waitForObject(true);
  }

injectInitCode tut nun genau das: einen Code generieren, der bei Ausführung ein neues EM-Objekt erstellt und entweder mit leerem __proto__ oder dem __proto__ des übergebenen Objektes verknüpft. Sollte etwas übergeben worden sein, muss natürlich gewartet werden, bis das Objekt dann auch verfügbar ist. Dies passiert im Conent Scope, damit funktioniert der Code!

  function injectInitCode(p) {
    var code='';
    code+='(function(par){';
    code+=' var newEM = {};';
    code+=' if (par) {';
    code+='  var wait=setTimeout(function() {';
    code+='   if (typeof par.EM!=="undefined") {';
    code+='    clearInterval(wait);';
    code+='    newEM.__proto__ = par.EM.__proto__;';
    code+='    window.EM = newEM;';
    code+='   }';
    code+='  }, 10);';
    code+=' } else {';
    code+='  newEM.__proto__ = {};';
    code+='  window.EM = newEM;';
    code+=' } ';
    code+='})('+p+')';
 
    var script=document.createElement('script');
    script.setAttribute('type','text/javascript');
    script.innerHTML = code;
    document.documentElement.appendChild(script);
    document.documentElement.removeChild(script);
  }

Nun will aber der Rest des Scripts sein gemütliches Chrome Scope nicht verlassen… also muss die weitere Initialisierung so lange verzögert werden, biss das Content-Script unser Objekt verknotet hat – danach können wir nach belieben drauf operieren. Auch hier wieder die übliche setInterval-Methode, die nach wenigen (naja, so schnell ist Firefox ja nicht…) Versuchen ein EM-Objekt im unsafeWindow vorfindet und nach ein paar Scoping-Würgarounds dieses überall bekannt gemacht hat. Wenn das der Fall ist, können noch schnell globale Objekte erstellt werden (hier nur symbolhaft) und die eigentliche, seitenspezifische Initialisierung kann stattfinden. Wie sich vermuten lässt, passiert dies in startup(). Die ist dann auch so uninteressant und total by-the-book, dass sie hier nicht mehr Gegenstand ist.

  function waitForObject(buildglobals) {
    var wait=setInterval(function() {
      if (typeof unsafeWindow.EM!== "undefined") {
        clearInterval(wait);
        window.EM = unsafeWindow.EM;
        EM = window.EM;  // Für Fx4
        if (buildglobals) {
          EM.__proto__.Ajax = new AJAXObject();
        }
        //awesome, we're done
        startup(EM);
      }
    }, 20);
  }

Mein Fazit
Also zuerstmal: meine Aussage steht noch, dass man mit JS wirklich alles lösen kann. Glück gehabt
Was lernen wir aus dem Ganzen: man sollte immer mal Out Of The Box denken, gerade wenn man eine Sandbox verlassen will. Um auf diese Idee zu kommen brauchte es immerhin einen Bug-Eintrag bei Greasemonkey. Ich bin immer noch überzeugt, dass das Verhalten von GM hier ein Bug ist. Wenn auch keiner der Sorte “geht nicht”, sonder “geht anders nicht als es nicht gehen sollte”.

Wichtigste Erkenntnis dürfte aber sein, dass man es mit Security nicht übertreiben sollte. Nicht immer, wenn etwas sicherer wird, wird es auch besser. Ohne die extrem fiese Sandbox müsste ich nichts Injecten und das Window hätte es nicht so leicht, rauszukriegen dass hier ein Edgemonkey am Werk ist. Dies sollte man wohl bei jeder Art Software-Entwicklung bedenken.

Was mich heute zum wiederholten Mal verwundert hat, sind spontan nicht mehr funktionierende PHP-Skripte.
PHPExec meinte doch eben völlig unmotiviert (“I didn’t touch anything! *looks away*”), mir einen Fehler zu melden, eine Variable wäre nicht initialisiert. Das war sie zwar wirklich nicht, aber das Skript lief ohne Unterschied literally seit Jahren. Fehlerfrei. Ich hab eine glaubhafte Versicherung meines Hosters, dass er auch nix gemacht hat…

Sowas hatte ich schonmal: ein Datenbank-Wrapper, der schon Wochenlang genutzt wurde, meinte auf einmal, Bind-Variablen nicht mehr richtig übergeben zu wollen. Und Überraschung: laut Manual hätte es nie funktionieren können.

Hatte schonmal jemand ähnliche Effekte? Plötzlich veränderliches Verhalten ist etwas, was ich mir so gar nicht erklären kann.

Man lese folgenden Code, der alternierend ein LCD mit Zahlen, Buchstaben und “nichts” füllt:

while (1) {
	for (unsigned char k=0;k<4;k++)  {
		LCD_setCursorPos(k,0);
		LCD_write("1234567890123456");
	}
	delay(250);
	LCD_clear();
	delay(250);
	for (unsigned char k=0;k<4;k++)  {
		LCD_setCursorPos(k,0);
		LCD_write("abcdefghijklmnop");
	}
	delay(250);
}

What could possibly go wrong

Gut, wir kennen ja Murphy: Alles, was schief gehen kann, geht schief. Und wenn schon der Code kaum Fehlerpotential hat, muss zwangsläufig der Compiler seinen Beitrag dazu leisten

Genau das hat er dann auch getan… erstmal äußerte sich das ganze dann darin, dass wider erwarten nur Zahlen, leere Seite und wieder Zahlen kamen. Und dabei die Seite mit den Zahlen irgendwie “zu lang” zu sehen war.
Was war also los?
Wie in Blick in das praktischerweise im Makefile angeforderte Extended Listing verrät, ist avr-gcc der Meinung, die beiden Schleifen würden das Gleiche machen, und kombiniert die in eine Schleife. Durch Ausprobieren anderer Optimierungsstufen zwischen -Os und -O1 kann man dann gcc immerhin überreden, nicht mehr beides in einer Schleife zu erledigen, sondern die zweite komplett zu ignorieren (toll!)… auch nicht ganz das Wahre. -O0 erzeugt Warnungen in <util/delay.h>, fällt also leider aus.

Die einzige mir bekannte Lösung ist das verlegen der beiden Schleifen in separate Methoden:

void test1(void)
{
	for (unsigned char k=0;k<4;k++)  {
		LCD_setCursorPos(k,0);
		LCD_write("1234567890123456");
	}
	delay(250);
}
 
void test2(void)
{
	for (unsigned char k=0;k<4;k++)  {
		LCD_setCursorPos(k,0);
		LCD_write("abcdefghijklmnop");
	}
	delay(250);
}

while (1) {
	test1();
	LCD_clear();
	delay(250);
	test2();
}

Gut, man muss eingestehen, der gcc hier ist schon etwas (avr-gcc (WinAVR 20080610) 4.3.0) älter. Das ist in einigen Kompatibilitätsproblemen mit anderen Projekten geschuldet, die sich auf ein bestimmtes Verhalten verlassen (hey, ich hab das nicht erfunden, ok?)
Kann also sein, dass das mittlerweile nicht mehr so ist. Aber trotzdem toll, dass so ein Bug es tatsächlich in eine Produktiv-Version schafft. Ist das kein Testcase? Naja, gcc halt…

Ich hab mich hier und anderswo ja schon öfter drüber beschwert, dass sich gewisse Browser nicht an Standards halten. ‘Gewisse’ war dabei meist der IE

Nun, offenbar tritt auch mal das Gegenteil auf… aber zum Anfang.

Ein Uber-1337-Web2.0-Projekt benutzt unter anderem DOM-Manipulation, dabei werden auch <style>-Nodes injected. Und zwar unterhalb des <body>s. Das funktioniert prima im Firefox(3) und in Opera, aber NICHT in IE und Safari/Webkit/KHTML/whatever. Woran liegt das? Nun, laut Standard darf ein <style>-Node nur unterhalb von <head> stehen. Meines Wissens sind Firefox und Opera die einzigen, die das ignorieren und die Dinger auch anderswo parsen. Schade eigentlich, denn meine so einfache Lösung wird jetzt durch Sonderbehandlung für die, die sich an Standards halten wieder komplizierter.

Was mich zum Fazit bringt: auch das W3C hat die Weisheit nicht gepachtet, für mich ist dieser Standard inkonsequent: die an sich ähnlich auszulegenden <script>s darf man schließlich auch überall verwenden.

Wer aber ne gute Idee hat, wie man das so hinkriegt, dass die Styles auch da geparst werden, oder wer mir sagen kann wie ich in IE/Webkit DOM-Änderungen Hooken kann (brauch ich fürs aufräumen, wenn ich doch in den <head> injecten muss), der kriegt ein Bienchen und eine About-Erwähnung

cu,
Martok

Ich melde mich mal wieder, diesmal mit etwas relativ wichtigem. Vor kurzem wurde WordPress 2.6 freigegeben, im Zuge des Updates musste ich mal wieder den wpautop()-Fix einspielen.

Dabei sind mir einige Unzulänglichkeiten aufgefallen, unter anderem dass er sinnlos kompliziert ist

Die neue Version kommt mit grade mal 7 neuen und einer geänderten Zeile aus.

Hier die Diff (wir sind wieder in wp-includes/formatting.php):

@@ -65,10 +65,15 @@
 }
 
 function wpautop($pee, $br = 1) {
+	$preserving = strpos($pee, '<preserve>') !== false;
+	if ($preserving) {
+		$pee = preg_replace_callback('!<preserve>(.*?)</preserve>!is', create_function('$matches', 'return "<revert>".base64_encode($matches[1])."</revert>";'), $pee);
+	}
+
 	$pee = $pee . "n"; // just to make things a little easier, pad the end
 	$pee = preg_replace('|<br />s*<br />|', "nn", $pee);
 	// Space things out a little
-	$allblocks = '(?:table|thead|tfoot|caption|colgroup|tbody|tr|td|th|div|dl|dd|dt|ul|ol|li|pre|select|form|map|area|blockquote|address|math|style|input|p|h[1-6]|hr)';
+	$allblocks = '(?:table|thead|tfoot|caption|colgroup|tbody|tr|td|th|div|dl|dd|dt|ul|ol|li|pre|select|form|map|area|blockquote|address|math|style|input|p|h[1-6]|hr|revert)';
 	$pee = preg_replace('!(<' . $allblocks . '[^>]*>)!', "n$1", $pee);
 	$pee = preg_replace('!(</' . $allblocks . '>)!', "$1nn", $pee);
 	$pee = str_replace(array("rn", "r"), "n", $pee); // cross-platform newlines
@@ -99,6 +104,9 @@
 	$pee = preg_replace( "|n</p>$|", '</p>', $pee );
 	$pee = preg_replace('/<p>s*?(' . get_shortcode_regex() . ')s*</p>/s', '$1', $pee); // don't auto-p wrap shortcodes that stand alone
 
+	if ($preserving) {
+		$pee = preg_replace_callback('!<revert>(.*?)</revert>!is', create_function('$matches', 'return base64_decode($matches[1]);'), $pee);
+	}
 	return $pee;
 }

Bei der Gelegenheit habe ich den Tag von <nowpautop> in <preserve> geändert, hier gegebenfalls betreffende Posts/Seiten anpassen.

Die angesprochenen anderen Unzulänglichkeiten hatten damit zu tun, dass nur p und br-Tags verhindert wurden. Alles andere wurde trotzdem munter verändert. Jetzt ist das Verhalten das erwartete: per php generierter HTML-Code wird genau so übernommen wie er aus dem Interpreter kommt. Technisch liegt das daran, dass ich jetzt nicht mehr einzelne Zeichen schütze, sondern alles, indem der Code base64-Codiert vor wpautop() versteckt wird.

Viel Spaß damit
Martok