blog.osuv.de        Impressum ‣ RSS


autocomplete

Für ein kleines Projekt (HTML) brauchte ich eine autocomplete Funktion für ein Suchfeld und fand schließlich autoCompltr, welches seinen Job auch ohne Zweifel erfüllte.

Allerdings stieß ich durch einen Zufall auf das datalist Element, welches eine zusätzliche Javascript bibliothek wie autoCompltr eigentlich überflüssig macht.
Da ich überflüssiges versuche zu vermeiden, hab ich mir es zusammengefrickelt.


<input id = "input" name = "display" list = "datalist" type = "text" onkeypress="return runScript(event)">
<datalist id = "datalist">
    <option value="Datei 1"><option value="Was anderes"><option value="gnu power">
</datalist>
<input id="GO" type="submit" value="Send" class="button">Default Button</a>

Man setzt eigentlich nur ein input field sowie eine datalist mit options und values die man autovervollständigt haben möchte (wo diese auch immer herkommen sei jetzt mal dahingestellt).
Für das input field triggere ich am Ende noch ein onkeypress Javascript event. Zuletzt noch irgendwo einen Klickbutton setzen...

Und nun kommen noch meine dreckigen 3 Zeilen Javascript (da ich möchte dass eine Seite aufgerufen wird wenn die "Enter-Taste" gedrückt wird).


var input = document.getElementById ("input");
document.getElementById("GO").addEventListener("click", function(e){
window.location="plot="+input.value;},false);

autocomplete

Es würde die Seite /plot=Was anderes aufgerufen werden.

Und fertig ist unser 3 Minuten-autocomplete-dings ohne schnickschnack.

PS: Ich hab eigentlich keinen schimmer von Javascript und nur wenig von HTML

Flattr this



tinywebdis

webdis ist ein HTTP Interface für redis. Soweit so gut.
Meines erachtens hat es allerdings drei Nachteile.

  1. Es funktioniert nicht alles, z.b. http://127.0.0.1:8000/scan/0/match/a:*
  2. Praktisch ist es tod (letzter commit > 1 Jahr + 26 offene Issues)
  3. Ein sehr großer haufen C-Code.

tinywebdis

Ich entschied mich ein simples replacement mit Lua zu schaffen, welches den klangvollen Namen tinywebdis trägt.

Es basiert auf luadyad, welches quasi nur auf dyad aufsetzt und den Lua Stack integriert). Hört sich aufwänig an, ist aber alles in allem KISS und klein.

Für die Kommunikation zu Redis wird lsocket und RESP verwendet. Das bedeutet, dass die gesamte HTTP kommunikation durch dyad geschieht, und der rest (redis Aufruf und JSON export) mit Lua abgewickelt wird.

Das ganze ist sehr hackfreundlich, da sich der Kern von tinywebdis auch direkt über ein require in einer Lua session verwenden lässt.

tinywebdis benötigt auch keinen neustart geschweige denn eine neukompilierung wenn jemand was am Lua code verändert. Es lässt sich also sehr sehr einfach an seine eigenen bedürfnisse anpassen.

Flattr this



Lineare Regression

Manchmal auch Trendlinie oder Regressionsgerade genannt.

In Matlab/Octave gibt es sehr viele Möglichkeiten eine solche zu erstellen.

Ausgangssituation:

>> y = [0 1 3 2 4 3 6 5 6 7];
>> x = 1:length(y);  

Polyfit

Dies ist vermutlich die am weitesten verbreitete Variante. Der Output sind die Koeffizienten einer linearen Funktion f(x)= m * x + b

>> B = polyfit (x,y,1)
ans =

     0.721212121212121    -0.266666666666668

>> trendlinie = x * B(1) + B(2);

Detrend

Man erstellt eine lineare Regression indem man den linearen Trend entfernt und anschließend die Differenz bildet. Das ist meiner Meinung die coolste Variante.

>> d = detrend(y);
>> trendlinie = y - d;

Old school

Der magische Backslash Operator. Das Ergebnis ist ähnlich wie des Polyfit Ergebnisses, nur dass die Koeffizienten quasi in einer anderen Reihenfolge ausgegeben werden.

>> B = [ ones(length(x),1) x'] \ y';
>> trendlinie = x * B(2) + B(1);

LinearModel Class

Sowas gibt es unter Matlab, worauf ich nicht weiter drauf eingehen will. Ich will nur kurz zeigen wie man sich soetwas unter Octave zurecht biegen kann.

function f = fitml(y)
    B = polyfit (1:length(y),y,1);
    f.mdl = @(x) B(1)*x + B(2);
    f.m = rats(B(1)); 
    f.b = rats(B(2));
end

Benutzen kann man es so

octave:1> y = [0 1 3 2 4 3 6 5 6 7];
octave:2> f = fitml(y);
octave:3> f.mdl(192)
ans =     138.206060606061
octave:4> f.m
ans =   119/165
octave:5> f.b
ans =     -4/15

Das Struct kann man sich auch sparen wenn man keine Informationen über die Bestandteile der linearen Funktion haben möchte.

Flattr this



Lua 5.3

Lua 5.3 steht vor der Tür.

Außerdem gibt es jetzt table.copy. Die Syntax ist allerdings etwas gewöhnungsbedürftig.

table.copy (a1, f, e, [a2,] t)

Meint so viel wie table.copy(Table_A, Start_Index, Bis_Index, Neue_Table_Varialbe, Start_Index_von_neuer_Table_Varialbe).
In der Praxis

Lua 5.3.0 (alpha)  Copyright (C) 1994-2014 Lua.org, PUC-Rio
> a={1,1,1}
> b={}
> table.copy(a,1,3,b,1)
> a[1]
1
> a[1]=5
> b[1]
1
> a[1]
5

Das interpreter Verhalten ist ebenfalls neu in 5.3. Während man in 5.2.x noch > =a[1] schreiben musste, damit der Wert direkt geprintet wird, genügt in 5.3 ein einfaches > a[1].

Kurz gesagt, Lua 5.3 fühlt sich an, als sollte es schon immer so gewesen sein.

Flattr this



ArchBook Air

Ja, ich hab mir ein Macbook Air 11" gekauft. 8GB RAM, i5.
Ja, ich habe nach ~3 Wochen Arch Linux drauf installiert.
Ja, alles Funktioniert.
Ja, ich habe kein Mac OS X mehr drauf.
Warum? Hardware hui, Software pfui.

Flattr this



Boost Graphicsmagic with GNU Parallal

Ich hatte vor längerer Zeit schon mal einen Artikel über die performance von Graphicsmagick und Imagemagick geschrieben.
Es ist auch so, dass Graphicsmagick OpenMP nutzt, um die prozesse auf alle/mehrere CPU Cores zu verteilen.

time gm mogrify -resize 50% *.JPG
real 3m57.774s

78 Bilder, jedes hat eine Auflösung von 4096 x irgendwas und ist über 5MB groß (Ja, dauert so lange weil mein Thinkpad so lahm ist).
Dabei fällt auf, dass gm beide Prozessorkerne auslastet. Das maximum der Fahnenstange ist hier also erreicht?

time ls | parallel --no-notice -j "2" gm mogrify -resize 50% 
real 3m45.902s

So, wo ist der Unterschied? gm alleine lastet beide CPUs für ein Bild aus, ist es fertig, nimmt es das nächste Bild und nutzt wieder beide CPUs.
GNU Parallel (basiert auf Perls open3) nimmt zwei Bilder und gibt je eines davon an einen gm Prozess, diese arbeiten mit je zwei CPUs das eine Bild ab - sobald ein gm Prozess fertig ist, wird direkt ein neuer gm mit dem nächsten Bild gestartet. Die system load wird in diesem Fall auch größer als 4. Kurzum, die CPU wird mit GNU Parallel noch ein kleines stückchen besser ausgenutzt.

Flattr this



GCC

Warum kann der GCC eigentlich so gut optimieren?

Na, wegen seinen geschickten If-Abfragen!. Hier noch
mal ein Screenshot für die Historie.

Da sag noch mal einer "Ich trau dem TCC nicht"...

PS:
(If it was hard to write, it should be hard to understand.)

Flattr this



Krankenkassenbeiträge, Rückzahlungen und Leistungen

Anfang des Jahres haben die gesetzlichen Krankenversicherungen Rückzahlungen getätigt. Ich war damals schon nicht dafür.
Wenn die Krankenversicherungen einen Überschuss haben, ist die logische vorgehensweise

  1. Rücklagen bilden
  2. Leistungen erhöhen (wenn der Überschuss besteht)
  3. Beiträge senken (wenn der Überschuss besteht)

Aber nein, nicht hier bei uns. Die vorgehensweise sieht hier wie folgt aus

  1. Rückzahlungen
  2. Beiträge senken
  3. Millionen Verlust
  4. Leistungen kürzen
  5. Beiträge für die AN erhöhen

Da pack sich einer an Kopf...

Flattr this



tcc

Der TCC ist ein kleiner und schneller C Compiler. Im Vergleich zum GCC optimiert er viel weniger und fährt nur einmal über den Code. Zudem bietet er auch mit -run die Option C-Code live auszuführen oder C-Code gänzlich über das shebang als Scriptsprache zu interpretieren.
Ich kann also Lua vom TCC live ausführen lassen, dass wiederum ein Script laufen lässt

time tcc *[^ca].c lgc.c lfunc.c -run lua.c ~/ziproxystats.lua ~/a
Original Size: 726.57 mb
Compressed Size: 398.30 mb
real 0m1.058s
user 0m0.950s
sys 0m0.010s 

Kompiliere ich die Lua binary tcc -lm *[^ca].c lgc.c lfunc.c lua.c -o l fällt auf, dass die binary ca. 100kb größer ist als die, die der GCC produziert.

time ./l ziproxystats.lua a
Original Size: 726.57 mb
Compressed Size: 398.30 mb
real 0m0.803s
user 0m0.780s
sys 0m0.000s 

time lua ziproxystats.lua a
Original Size: 726.57 mb
Compressed Size: 398.30 mb
real 0m0.469s
user 0m0.440s
sys 0m0.020s 

Zudem ist die GCC binary auch fast doppelt so schnell, was wohl an den optimierungen durch den GCC ihren Ursprung hat. Aber da hab ich eigentlich gar keine Ahnung von :)

Kompiliere ich eine mex Funktion von/für Octave/Matlab, ist die binary, die der TCC erstellt nur halb so groß wie die, die der GCC erstellt. Für die kompilierung braucht der TCC auch nur 1/5 der Zeit des GCCs. Über die Ausführungszeit lässt sich fast keine Aussage treffen. Minimal ist die TCC binary schneller, aber das würde ich jetzt nicht als generalisierte Aussage betrachten.

Flattr this



HTC delay

Ihr erinnert euch noch? Als HTC mich anrief? Nein? -> Wenn HTC anruft.
Das war am 11.04.2014. Heartbleed war dort fast eine Woche alt. Es war ein Totalschaden. HTC wußte von nichts.
Jetzt, zwei Monate später ...

htc1 htc2

... hab ich mich heute Morgen fürchterlich erschreckt.

htc3 htc4

Sie haben also keine aktuelle Android Version verteilt und auch kein aktuelles OpenSSL. Sie haben lediglich die heardbeed Funktion beim kompilieren von OpenSSL deaktiviert.
Kurzum, das HTC Desire X hat ein sehr sehr spätes Update gegen Heartbleed bekommen.

Flattr this



Older