Neue Antwort schreiben 
 
Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Pre-Release: siginfo-ng 0.2.0pre5 mit Lua-Support (Update: 08.März.2011)
gandro Offline
Quälgeist

Beiträge: 8.951
Registriert seit: Jul 2008
Beitrag #1
Pre-Release: siginfo-ng 0.2.0pre5 mit Lua-Support (Update: 08.März.2011)
Wie schon angekündgt, hab ich siginfo-ng praktisch von Grund auf neu geschrieben, jetzt mit Lua für Plugins, anstelle statisch einkompilierter C-Funktionen.

Ich bin allerdings mit der Plugin-Architektur noch nicht so ganz zufrieden, daher veröffentliche ich meinen Status-Quo (der abgesehen vom noch nicht zufriedenstellenden Plugin-System aber robust sein sollte) als Pre-Release. Das Ding bietet nicht alle Features der 0.1.xer-Serie, ist daher viel mehr zum ausprobieren und Feedback geben gedacht, wie man dass dann in der "finalen" 0.2.0er machen soll.

Dokumentation ist praktisch nicht existent zur Zeit. Für Plugins gilt grundsätzlich folgendes:

Es sind gewöhnliche .lua-Dateien, die an sich keine besonderen Anforderungen erfüllen müssen. Diese werden von siginfo-ng geladen und ausgeführt. Alle aus sicht des Plugisn globalen Variabeln befinden sich allerdings in einer separaten Table, und können in der Config-Datei dann so angesprochen werden. Beispiel:

Code:
-- Datei "plugin.lua"

local tmp = 21
illuminaten = tmp + 2

function random()
    return math.random(0, 100)
end

Lädt man diese Datei in der Konfigurationsdatei (config.lua) mit load_plugin("plugin", "plugin.lua"), dann kann man in der Konfigurationsdatei im Layout diese wie folgt verwenden:

Code:
siginfo.layout = {} -- neues, leeres Layout
siginfo.layout.row1 = { "Zahl der Illuminaten: ", plugin.illuminaten }
siginfo.layout.row2 = { "Zufallszahl: ", plugin.random }

Während plugin.tmp via Konfigurationsdatei nicht ansprechbar ist. Hoffe, das ist einigermassen verständlich.

Problem an der Architektur ist, dass zwar ständig ändernde Werte möglich sind (siehe plugin.random, diese Funktion wird bei jedem Update frisch aufgerufen), aber das bei vielen kleinen Werten sehr mühsam wird (siehe mem.lua). Daher wäre ich um Feedback froh.

Auch ein ungelöstes Problem ist es, wie und wo man die Plugins lädt. Zur Zeit gibt es in der Config-File zwei Funktionen: load_plugin(ns, file) und load_plugin_dir(file), erstere lässt einem bestimmen, wie das Plugin angesprochen wird, zweitere lädt einfach alle Plugins in einem Verzeichnis und gibt ihnen den Dateinamen als Namespace.

Grundsätzliche Lua-Kenntnisse sind allerdings schon von nöten, daher empfehle ich folgende Seiten:
Lua für Anfänger: Lua fr Anfnger
Programming in Lua (Buch, englisch): Programming in Lua, Second Edition
Lua 5.1 Sprachrefrenz (englisch): Lua 5.1 Reference Manual - contents

Der Rest sollte einigermassen fertig sein. HTTP-Support wurde komplett überarbeitet und fehlerbereinigt, auch wenn der HTTP-Parser nicht immer ganz standardkonform arbeitet, so reicht es wenigstens für siginfo.de. Die Portabilität wird vorerst etwas zurückgegangen sein, weil ich 2-3 POSIX-Funktionen mehr verwendet habe, und sogar eine GNU-Funktion, auf einem Linux mit dynamischer glibc wird es aber funktionieren. Während statisches reinkompilieren des Lua-Interpreteres unter
Arch zwar funktioniert hat, aber das Binarie danach nich lief. Daher auch Pre-Release.

Download wie immer auf GitHub: gandro's siginfo-ng at master - GitHub
27.07.2010 13:51
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
gandro Offline
Quälgeist

Beiträge: 8.951
Registriert seit: Jul 2008
Beitrag #2
Pre-Release: siginfo-ng 0.2.0pre5 mit Lua-Support (Update: 08.März.2011)
Fürs Protokoll: Die Portabilität ist ggf. doch nicht so übel wie befürchtet, hab siginfo-ng ohne Änderung im Quellcode statisch kompiliert gekriegt, auf Basis der dietlibc.

Man muss die dietlibc zwar für libm patchen, damit es mit Lua läuft, und Lua selber braucht auch einen Einzeiler-Patch, dann läufts aber und man kriegt ein statisch gelinktes Binary, ohne jegliche Abhängigkeiten (anders als das alte siginfo-ng, was mit der glibc auch nicht komplett statisch kompilieren konnte, wegen DNS), und das ganze Programm ist nur 254 KBytes gross (inklusive HTTP und Lua).

Einzig io.popen() von Lua wird rausgeschmissen, weil "posix" ein zu generisches Target für Lua ist. Das kann man aber bestimmt wieder reinholen.

Nachtrag: Das mit popen ist Blödsinn, das ist drin wenn man POSIX macht. Man muss es nur auch nutzen.

Werd mir das was überlegen, wie man das etwas automatisieren kann.
(Dieser Beitrag wurde zuletzt bearbeitet: 27.07.2010 20:57 von gandro.)
27.07.2010 18:31
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
oreissig Offline
Maître Modérateur

Beiträge: 12.021
Registriert seit: Jul 2008
Beitrag #3
Pre-Release: siginfo-ng 0.2.0pre5 mit Lua-Support (Update: 08.März.2011)
gandro schrieb:  Fürs Protokoll: Die Portabilität ist ggf. doch nicht so übel wie befürchtet, hab siginfo-ng ohne Änderung im Quellcode statisch kompiliert gekriegt, auf Basis der dietlibc.
soll ich morgen vll mal IRIX 5.3 oder 6.5 probieren so als "proof of portability"?
hätte spontan auch noch Digital UNIX 4.0 und glaub noch irgendnen AIX (4.3.3 oder 5.3) am start
27.07.2010 18:57
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
gandro Offline
Quälgeist

Beiträge: 8.951
Registriert seit: Jul 2008
Beitrag #4
Pre-Release: siginfo-ng 0.2.0pre5 mit Lua-Support (Update: 08.März.2011)
Drittes Pre-Release ist oben (siginfo-ng 0.2.0pre3)
16 files changed, 575 insertions(+), 221 deletions(-)

Es existiert nun ein Plugin-API. Plugins müssen mit using "VAR" bestimmen, welche Template-Variablen sie verwenden wollen, und können diese dann nach belieben auffüllen. Dazu gibt es jetzt vier Helfer-Funktionen: siginfo.ng.loadplugin (einzelnes Plugin laden), siginfo.ng.loadfolder (ganzes Verzeichnis voller Plugins laden), siginfo.ng.readexec (Befehl zu String) und siginfo.ng.readfile (Datei zu String).

Ein bisschen stolz bin ich auf die neue Makefile, mit der man jetzt Lua direkt mit einkompilieren kann, so dass das Binary nicht mehr Abhängigkeiten hat, als 0.1.x. Einfach mit make include-lua bauen, und er saugt sich die Sourcen von Lua mit wget und baut sie.

Dazu gab es weitere Verbesserungen in der Makefile, für Non-GNU-Systeme etc.

Plugins habe ich alle neu geschrieben und paar hinzugefügt, was jetzt allerdings noch fehlt, ist ne Idee wie man das jetzt für die verschiedenen Architekturen machen will mit den Plugins.

Zur Zeit können Plugins zwar ihr Laden verhindern, wenn sie während der Initialisierung ein "false" zurückliefern, aber das könnte unübersichtlich werden.

Ein Plugin sähe dann in etwa so aus:
Code:
--[[
    Beispielplugin
]]

using "GPU"

if __init__ then
     -- überprüfe ob das System überhaupt kompatibel ist
     -- ansonsten 'return false'

     -- einmaliges Setzen einer Variable
     GPU.MODEL = getGPUModel()

     -- ... usw
end


-- diese Variable hingegen wird bei jedem Update durchgeparst,
-- weil nicht im __init__-if drin.
GPU.MEMORY.FREE = getGPUFreeMemory()
03.08.2010 14:10
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
Blue Offline
Seit dem 17.10.2006 dabei!

Beiträge: 21.533
Registriert seit: Jul 2008
Beitrag #5
Pre-Release: siginfo-ng 0.2.0pre5 mit Lua-Support (Update: 08.März.2011)
gandro schrieb:  Ein bisschen stolz bin ich auf die neue Makefile, mit der man jetzt Lua direkt mit einkompilieren kann, so dass das Binary nicht mehr Abhängigkeiten hat, als 0.1.x. Einfach mit make include-lua bauen, und er saugt sich die Sourcen von Lua mit wget und baut sie.
klingt sup0r!
(Dieser Beitrag wurde zuletzt bearbeitet: 05.08.2010 17:50 von DosAmp.)
03.08.2010 22:15
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
oreissig Offline
Maître Modérateur

Beiträge: 12.021
Registriert seit: Jul 2008
Beitrag #6
Pre-Release: siginfo-ng 0.2.0pre5 mit Lua-Support (Update: 08.März.2011)
grml mein wget unter IRIX 5.3 is broken :fresse: aber nu hab ich ja lua
vll bau ich mir nen wrapper für snprintf u.a. einfach mal in die headerdatei vom system ein
03.08.2010 23:08
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
gandro Offline
Quälgeist

Beiträge: 8.951
Registriert seit: Jul 2008
Beitrag #7
Pre-Release: siginfo-ng 0.2.0pre5 mit Lua-Support (Update: 08.März.2011)
Man kann mit LUA_PREFIX das wget'en und entpacken umgehen, in dem man sagt, wo er die entpackten Dateien herkriegt.

make LUA_PREFIX=/pfad/zu/den/lua/sourcen include-lua
03.08.2010 23:11
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
Blue Offline
Seit dem 17.10.2006 dabei!

Beiträge: 21.533
Registriert seit: Jul 2008
Beitrag #8
Pre-Release: siginfo-ng 0.2.0pre5 mit Lua-Support (Update: 08.März.2011)
mit gandro wird das porten zum genuss.. da ist es, bauzeit: 10 minuten , endgeil

#19 ([sparc] testing release) – Siginfo

und wie das so aussieht, seht ihr hier wa:

http://siginfo.de/vcards/showPC/963-ultratux.html
04.08.2010 21:20
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
gandro Offline
Quälgeist

Beiträge: 8.951
Registriert seit: Jul 2008
Beitrag #9
Pre-Release: siginfo-ng 0.2.0pre5 mit Lua-Support (Update: 08.März.2011)
0.2.0pre4 ist oben. Nur wenig neues, einzig das Problem mit plattformabhängigen Plugins sollte jetzt gelöst sein. Das ganze funktioniert so:

Das plugins/ Verzeichnis wird ab sofort von der Makefile erzeugt. Dazu holt es die Plugin im Quelltext aus dem platform/-Verzeichnis und kopiert die nach plugins/ - alle nicht lauffähigen Plugins werden also gar nicht erst kopiert.

Dieses ist wie folgt aufgebaut: platform/OS/ARCH/plugin.lua

OS und ARCH sind hierbei Platzhalter, OS wird mit `uname -s` ersetzt, ARCH mit `uname -m` - wobei ARCH je nach dem etwas normalisiert wird (hab ich ausm Linux-Kernel geklaut, den Code).
Beispiel:
  • Ein Plugin, was nur auf einem 32bittigen x86 Linux läuft, liegt in platform/Linux/i386/ - hierbei ist es egal ob `uname -m` nun i386 oder i686 zurückgibt, die Makefile normalisiert dies.
  • Ein Plugin was nur auf OSX läuft, aber sowohl auf PPC als auch x86, würde dann im Verzeichnis /plattform/Darwin/ liegen.
  • Alle Plugins, welche direkt in platform/ liegen, haben auf jedem POSIX-kompatibel Systen lauffähig zu sein (zur Zeit uname.lua und harddisk.lua).

Anzeigen kann man die normalisierte Architektur (aus mipsel wird mips, aus i686 wird i386) und das Betriebsystem mit "make echo".

Die Werte ARCH und OS können auch innerhalb von siginfo-ng ausgelesen werden, über die Lua-Variablen siginfo.ng.arch und siginfo.ng.os - das bringt bei Plugins was, die bis auf wenige Details auf verschiedenen Plattformen identisch sind. /platform/Linux/cpuinfo.lua ist so ein Fall zur Zeit, da wird zur Laufzeit geschaut ob die Kiste ne x86er oder SPARC-Kiste ist und setzt die Variablen dementsprechend anders. Plugins können nach wie vor ihr Laden zur Laufzeit noch verhindern, in dem sie 'return false' im __init__-Block machen.
05.08.2010 13:51
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
Blue Offline
Seit dem 17.10.2006 dabei!

Beiträge: 21.533
Registriert seit: Jul 2008
Beitrag #10
Pre-Release: siginfo-ng 0.2.0pre5 mit Lua-Support (Update: 08.März.2011)
So Notebook + Desktop von 0.1.4 und 0.2.0pre1 auf 0.2.0pre4 gebracht, läuft bestens :o
06.08.2010 08:38
Alle Beiträge dieses Benutzers finden Diese Nachricht in einer Antwort zitieren
Neue Antwort schreiben 


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste