Nagare: Neues continuation-basiertes Webanwendungsrahmenwerk

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Samstag 27. September 2008, 13:50

Habe gerade http://www.nagare.org/ entdeckt, ein neues Webanwendungsrahmenwerk, welches http://www.seaside.st als Vorbild nennt.

Interessant klingt, dass es den klassischen Request/Response-Kontrollfluss zu einem linearen Programm dreht und das man Python sowohl auf der Server- als auch auf der Clientseite (dort wird es automatisch in JavaScript übersetzt) benutzen kann.

Weniger schön finde ich, dass es http://www.stackless.com und lxml benötigt, sowie 18 (!) weitere Pakete, die man sich möglicherweise alle vorher selbst installieren muss. Das mag für Linux einfach genug sein, auf dem Mac nervt es schon, dass z.B. Stackless Python das existierende Python ersetzen will, was ich nicht möchte. Daher habe ich's (noch) nicht ausprobiert.

Das kanonische Seaside-Beispiel (das ihr vielleicht nicht kennt, aber egal) sieht in Nagare wohl so aus:

Code: Alles auswählen

class Counter:
  v = 0
  def increment(self): self.v += 1
  def decrement(self): self.v -= 1

@presentation.render_for(Counter)
def render(self, h, c, *args):
  return (
    'Value: ', self.v, h.br,
    h.a('++').action(self.increment), '|', h.a('--').action(self.decrement)
  )
Warum die `render`-Methode nicht direkt im Modell definiert wird, erschließt sich mir nicht. Der "h"-Parameter (bei Seaside heißt er html und ist ein HtmlCanvas-Objekt) ist jetzt auch nicht sooo elegant... Das "c" ist die Komponente, wie die sich vom Modell "self" unterscheidet, kann man wohl auch nur aus der Dokumentation ersehen.

Das Tutorial besteht leider nur aus Quelltext mit ein paar Kommentaren - etwas mehr Fließtext hätte ich besser gefunden. Jetzt muss man's sich selbst zusammenreimen.

Dennoch: Spannend.

Stefan
audax
User
Beiträge: 830
Registriert: Mittwoch 19. Dezember 2007, 10:38

Samstag 27. September 2008, 17:25

Stackless Python, weil CPython keine Continuations unterstützt...wegen des Stacks.
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Samstag 27. September 2008, 22:33

Genau das ist der Punkt. Allerdings hat er auch mich bisher davon abgehalten, es mir anzusehen, denn die Idee dahinter fasziniert mich.

Dass es so viele abhängige Pakete sind, ist mir neu. Wenn die alle setuptools unterstützen, ist das aber ein Selbstgänger. Immerhin wird im Tutorial virtualenv verwendet, das finde ich vorbildlich.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Sonntag 28. September 2008, 09:47

audax hat geschrieben:Stackless Python, weil CPython keine Continuations unterstützt...wegen des Stacks.
Das ist mir schon klar. Meine Kritik ist, dass ich Stackless Python nicht parallel auf dem Mac installieren kann, um so gefahrlos das ganze auszuprobieren. Müsste es selbst kompilieren - dafür muss ich mich aber auch selbst um die Abhängigkeiten kümmern, was ich schon mal für Python 3 probiert hatte.

Das virtualenv benutzt wird, lässt mich ja hoffen. Leider wollte stackless auch eben unter Ubuntu nicht bauen... versuche jetzt dort die Abhänigkeiten aufzulösen. Wenn ich mir die VM verkonfiguriere, ist das nicht schlimm.

Habe mir inzwischen ein paar der Beispiele angeschaut. Ich verstehe immer noch nicht, warum die `render`-Methode nicht Teil der Objekte ist, sondern von außen angeflanscht wird. Im Wiki-Beispiel sieht man beispielsweise:

Code: Alles auswählen

class Page:
  def __init__(self, title):
    self.title = title
  def edit(self, comp):
    content = comp.call(PageEditor(self))
    if content: ...speichern...

@presentation.render_for(Page)
def render(self, h, comp, *args):
  page = ...lesen...
  h << h.a('Edit this page').action(lambda: self.edit(comp))
Eine Funktion mit "self"-Parameter außerhalb einer Klasse finde ich gewöhnungsbedürftig - zumal sie sich ja abhängig von `edit` in der Klasse ist. Und das die Seiten aus der Datenbank nochmal andere Objekte sind als das Page-Objekt selbst, finde ich auch nicht gelungen. Wenn das schon sein muss, dann sollte dies bitte die PageComponent oder PageView oder sowas sein.

Was mög eigentlicht "functional variable" sein? Meine Assoziation wäre, eine, die sich nicht ändert. Gemeint ist aber wohl etwas anderes. So sieht `render` von `PageEditor` aus:

Code: Alles auswählen

def render(self, h, comp, *args):
  content = var.Var() # local functional variable
  page = ...lesen...
  h << h.textarea().action(content)
  h << h.input(type='submit', value='Save').action(lambda: comp.answer(content())
  h << h.input(type='submit', value='Cancel').action(comp.answer)
Das missfällt mir mehrfach. Ein Textarea hat eine Action? Ich würde hier eher eine Art gebundene Werte erwarten. Offenbar ist aber `content` eine Funktion, die man mit und ohne Parameter aufrufen kann und die dann jeweils ein Setter oder ein Getter ist. Hm. Auch würde ich mir eine höhere Abstraktion für die beiden Buttons wünschen. Und das auch hier offenbar ausgenutzt wird, dass man `answer` mit und ohne Argument aufrufen kann, ist fehleranfällig.

Bei Seaside würde das übrigens so aussehen (content wäre eine Exemplarvariable, der Button leitet seinen Namen aus dem Selektor ab):

Code: Alles auswählen

renderContentOn: html
  html form: [
    html textArea on: #content of: self.
    html submitButton on: #save of: self.
    html submitButton on: #cancel of: self]

save
  self answer: content

cancel
  self answer: nil
Äquivalentes Python wäre vielleicht dies:

Code: Alles auswählen

def render(self, html):
  with html.form():
    html.textArea().bind_to(self, 'content')
    html.button().bind_to(self.save)
    html.button().bind_to(self.cancel)

def save(self): self.answer(self.content)
def cancel(self): self.answer(None)
Stefan

PS: Warum erkennt BBCode eigentlich with nicht als Schlüsselwort? ;)
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Sonntag 28. September 2008, 10:40

sma hat geschrieben:PS: Warum erkennt BBCode eigentlich with nicht als Schlüsselwort? ;)
Weil das letzte Release von CodeBB älter ist als Python 2.5.

Also das was ich da sehe sieht... hmm, gewöhnungsbedürftig aus. Um ehrlich zu sein, bin ich auch nicht sicher ob Continuationbasierte Systeme das richtige sind. Vielleicht sollte ich mir ja Seaside oder UnCommon Web ansehen.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Montag 29. September 2008, 10:01

Leonidas hat geschrieben:
sma hat geschrieben:PS: Warum erkennt BBCode eigentlich with nicht als Schlüsselwort? ;)
Weil das letzte Release von CodeBB älter ist als Python 2.5.
Meine Bemerkung hätte wohl lauten sollen: Warum habt ihr denn noch nicht "with" zu den Schlüsselworten hinzugefügt?
Leonidas hat geschrieben:Also das was ich da sehe sieht... hmm, gewöhnungsbedürftig aus. Um ehrlich zu sein, bin ich auch nicht sicher ob Continuationbasierte Systeme das richtige sind. Vielleicht sollte ich mir ja Seaside oder UnCommon Web ansehen.
Sie erfordern eine etwas andere herangehensweise, die sich wohl nur bei komplexen Anwendungen, die gleichzeitig nicht unter massiver Last stehen, lohnt. Als Einführung in Smalltalk und Seaside (davor noch ein bisschen was über Maglev und Gemstone) dient vielleicht dieses Video. Der gute Mann hat leider einen einschläfernden Vortragsstil, dennoch ist die Einführung in die Syntax von Smalltalk kurz und korrekt.

Zu Nagare kann ich mittlerweile vermelden, dass nach einem "apt-get install zlib1g-dev libxml2-dev libxslt1-dev" auf einem jungfreulichen Ubuntu 8.04 dann Stackless Python 2.5.2 baut (dazu braucht es zlib, sonst funktioniert nachher setuptools nicht), man easy_install über die Setuptools installieren kann und dann Nagare mit all seinen Abhänigkeiten (lxml braucht die anderen beiden dev-Pakete) installieren kann.

Das funktioniert dann alles erfreulich reibungslos.

Jetzt muss ich nur noch schauen, wie ich gedit ein Highlighting von "with" beibringen kann... Ändern von `/usr/share/gtksourceview-2.0/language-specs/python.lang` hilft.

Stefan
Darii
User
Beiträge: 1177
Registriert: Donnerstag 29. November 2007, 17:02

Montag 29. September 2008, 17:12

Danke für den Hinweis. Mal schauen wie sich das entwickelt. Seaside erscheint mir da z.Zt. noch ausgereifter(z.B. transparente Persistenz in Objektdatenbank), allerdings braucht man dafür Smalltalk und mit Python programmiert es sich einfach angenehmer.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Sonntag 12. Oktober 2008, 08:52

Ich kompiliere gerade Stackless, mal reingucken wie sich Nagare so schlägt.

Edit: virtualenv versucht setuptools 0.6c8 für Python 2.6 zu laden, was es nicht gibt. Ich kann irgendwie im Code nicht erkennen warum es gerade 0.6c8 ist, dort finde ich nur 0.6c9.

Edit: gut, mit virtualenv-trunk geht es, es installiert tatsächlich 23 verschiedene Eggs, zu einem großen Teil sind das diese Mini-Libs von PJE, wo man sich irgendwie auch wünscht, dass die alle einfach Teil von PEAK werden und Ende.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Sonntag 12. Oktober 2008, 16:43

Wenn ich mich nicht irre, habe ich über Smalltalk mal gehört/gelesen, dass man da gleich mal ein paar hundert MB RAM einplanen kann, weil das eine komplette Laufzeitumgebung ist. Oder verwechsle ich das mit Lisp?
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Sonntag 12. Oktober 2008, 16:45

Y0Gi hat geschrieben:Wenn ich mich nicht irre, habe ich über Smalltalk mal gehört/gelesen, dass man da gleich mal ein paar hundert MB RAM einplanen kann, weil das eine komplette Laufzeitumgebung ist. Oder verwechsle ich das mit Lisp?
Sowohl Smalltalk als auch Lisp bieten VMs, die Images ausführen, von daher, ja. Gilt aber für Mono genauso: wenn du es nicht hast, musst du die Runtime installieren.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Sonntag 12. Oktober 2008, 17:20

Ich sag das nur, weil Python da im direkten Vergleich deutlich sparsamer wegkommen dürfte (wenn ich nichts übersehen habe).
BlackJack

Sonntag 12. Oktober 2008, 17:53

Wieso sollte Python da besser wegkommen? Bei CPython hast Du doch auch eine "komplette Laufzeitumgebung" mit virtueller Maschine. Falls Du nicht die Laufzeitumgebung, sondern eine grafische Entwicklungsumgebung meinst, die ist nicht Bestandteil der *Sprache* sondern ein Implementierungsdetail. GNU Smalltalk hat zum Beispiel erst einmal nur eine Shell die man in der Konsole startet, wie beim Python-Interpreter:

Code: Alles auswählen

bj@s8n:~$ gst
GNU Smalltalk ready

st> 10 + 5 !
15
st> 5 squared !
25
st>
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Sonntag 12. Oktober 2008, 21:58

Apropos GNU Smalltalk habe ich heute schon mit Freude festgestellt, dass es inzwischen Seaside unterstützt, ich also nun eine mir persönlich genehme Implementation um das "Vorbild", Seaside auszuprobieren.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Freitag 17. Oktober 2008, 09:20

Y0Gi hat geschrieben:Wenn ich mich nicht irre, habe ich über Smalltalk mal gehört/gelesen, dass man da gleich mal ein paar hundert MB RAM einplanen kann, weil das eine komplette Laufzeitumgebung ist. Oder verwechsle ich das mit Lisp?
Smalltalk hat traditionell eine virtuelle Maschine (da kommt die Idee wie vieles anderes, etwa das WIMP-GUI oder der Bitblit-Algoritmus), die dann ein sogenanntes Image - den Speicherabzug für die virtuelle Maschine - ausführt, bzw. natürlich den Programmcode darin. Der Vorteil ist, dass man das System einfrieren und zu einem anderen Zeitpunkt weiterlaufen lassen kann - wie das heutzutage mit "Ruhezustand" oder ähnlichen Betriebssystemfunktionen geht. Man kann quasi sagen, dass auch die heutigen VisualWorks-Smalltalk-Systeme (aber auch Squeak) seit 30 Jahren laufen ohne jemals neu gestartet worden zu sein.

Lisp kenne ich eher klassisch dateibasiert, allerdings gibt es dort auch Image-basierte Systeme so wie es bei Smalltalk dateibasierte Varianten (etwa GNU-Smalltalk) gibt.

Die ursprünglichen Smalltalk-Systeme waren erschreckend klein (für heutige Verhältnisse). Smalltalk/V kam (inklusive kompletter IDE) mit 1-2 MB auf einem DOS-Rechner aus. Das erste Squeak vor ~12 Jahren brauchte (ebenfalls wieder mit kompletter IDE) vielleicht 5-10 MB. Das aktuelle Squeak-Seaside-Entwickler-Image ist allerdings schon 26 MB groß. Dazu kommen 20 MB Quelltext, die aber nicht im Hauptspeicher stehen. Verglichen mit einer Java-IDE wie Eclipse ist das aber immer noch winzig. Geben wir jetzt noch etwas Speicher für eigene Anwendungen sowie die VM und etwas Platz, damit die automatische Speicherverwaltung auch "atmen" kann, reichen 64 MB. Für meine Java-IDE würde ich locker das 10-fache fordern.
Leonidas hat geschrieben:Apropos GNU Smalltalk habe ich heute schon mit Freude festgestellt, dass es inzwischen Seaside unterstützt, ich also nun eine mir persönlich genehme Implementation um das "Vorbild", Seaside auszuprobieren.
Ich würde dringend zu Squeak oder VisualWorks raten, auch wenn das GUI beim ersten gewöhnungsbedürftig ist und beim zweiten trotz aller Bemühungen des Entwicklungsteams immer noch wie aus dem letzten Jahrtausend stammend aussieht (was es ja auch tun), wenn rein textbasiert ist es einfach kein Smalltalk-System und der IMHO eigentliche Vorteil des Systems geht komplett verloren und alles was bleibt, ist eine komische Syntax.

Ich schreibe vielleicht in näherer Zukunft noch ein bisschen etwas über mein Spielprojekt, einen Smalltalk-Interpreter in Python zu bauen. Da kann ich dann auf die Syntax eingehen...

Stefan
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Freitag 17. Oktober 2008, 12:45

sma hat geschrieben:Lisp kenne ich eher klassisch dateibasiert, allerdings gibt es dort auch Image-basierte Systeme so wie es bei Smalltalk dateibasierte Varianten (etwa GNU-Smalltalk) gibt.
Der Lisp-Code ist auch in Dateien, allerdings unterstützen alle ernsthaften Common Lisp Interpreter Images, also kann man zur Laufzeit dort Code ersetzen, neu laden und den Zustand des Programmes in eine Datei serialisieren. Mich hat das auch überrascht, aber ich bin eher in der Scheme-Ecke Zuhause wo das nicht üblich ist.
sma hat geschrieben:Ich würde dringend zu Squeak oder VisualWorks raten, auch wenn das GUI beim ersten gewöhnungsbedürftig ist und beim zweiten trotz aller Bemühungen des Entwicklungsteams immer noch wie aus dem letzten Jahrtausend stammend aussieht (was es ja auch tun), wenn rein textbasiert ist es einfach kein Smalltalk-System und der IMHO eigentliche Vorteil des Systems geht komplett verloren und alles was bleibt, ist eine komische Syntax.
Nunja, auf einem Server ohne X11 kann ich eine Entwicklungsumgebung nicht gebrauchen und VisualWorks funktioniert bei mir auf x86_64 nicht, da die 64-Bit VM nicht die 32-Bit Images verarbeitet. Nun gab es mal so ein Tool zum konvertieren, aber das ist irgendwie nicht mitgeliefert. Momentan scheint es für mich tatsächlich so zu sein, dass die als kompliziert zu installieren verschrienen Lisp-Frameworks einfacher zum starten zu überreden sind.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Antworten