Mailman 3 August 2011 - python-de

Berliner PUB-/DZUG-Treffen am 17.9. um 19 h im newthinking store
by Dinu Gherman 04 Sep '22

04 Sep '22

Liebe Python-Freunde, diesen Donnerstag, den 17.8.2009 (übermorgen!) findet wieder ein PUB/DZUG-Treffen (Python und Zope User Group in Berlin) statt. Ort und Zeit sind wie immer: 19 Uhr, im newthinking store [1]. Anschließend wird das Treffen wieder im Restaurant Tucholsky [2] fortgesetzt. Zur Planung der Restaurantkapazitäten bitte ich euch ein Häckchen in der Doodle-Umfrage [3] zu machen, wenn ihr an- schließend noch mitkommen wollt. Das Programm muss dieses mal etwas kurzfristig arrangiert werden. Wer also schon immer mal einen kurzen Vortrag halten wollte, z.B. zu einem der Themen im Python-Wiki [4] und diesen womöglich schon in der Schublade hat, der (oder die) ist herzlich dazu eingeladen. Dann bitte bei mir vorher kurz per E-Mail ankündigen! Ansonsten werden einige, die auf der DZUG-Tagung letzte Woche in München waren, locker darüber berichten. Dabei ging es unter an- derem über die kommenden Versionen 4 und 5 von Plone. Sehr wahr- scheinlich wird Veit dazu Prospekte verteilen. Eine weitere Idee besteht darin, locker Buchempfehlungen zu den Themen Python/Zope/Plone auszutauschen, was man am besten macht, indem man das jeweilige Buch auch zum Treffen mitnimmt. Ich werde am Donnerstag das Buch "Python for Linux and Unix System Admini- stration" [5] dabei haben. Liebe Grüße und bis Donnerstag, Dinu PS: Ich übernehme mit Veit bis auf Weiteres die Organisation die- ser Treffen von Stephan, der das bisher vorbildlich gemacht hat, aber nun seinen väterlichen Aufgaben höhere Priorität geben wird. Nochmals vielen Dank, Stephan - ich hoffe, Du kannst trotzdem noch vorbeischauen! [1] newthinking store, Tucholskystr. 48, 10117 Berlin, http://newthinking-store.de [2] Restaurant Tucholsky, Torstraße 189, 10115 Berlin, http://www.restauration-tucholsky.de [3] http://doodle.com/rwqizz6ewxk6iscw [4] http://wiki.python.de/User%20Group%20Berlin [5] http://www.oreilly.de/catalog/9780596515829 ...................................................................... Follow me on Twitter: http://twitter.com/dinugherman

2 1

Re: [Python-de] Zeilengepuffertes r/w
by Ole Streicher 30 Aug '11

30 Aug '11

TOFU repariert. http://de.wikipedia.org/wiki/TOFU Jens Diemer <python_gmane(a)jensdiemer.de> writes: > Am 30.08.2011 13:53, schrieb Ole Streicher: >> wie bekomme ich eine zeilengepufferte Kommunikation zwischen zwei >> Scripten hin? Ich habe folgende zwei Mini-Programme: >> >> Sender: >> ----------------------8<----------------- >> import time >> l = open('myfifo',mode='w',buffering=1) >> [...] >> ----------------------8<----------------- >> >> Empfänger: >> ----------------------8<----------------- >> l = open('myfifo', buffering=1) >> [...] >> ----------------------8<----------------- > > Was ist mit l.flush() ? Es ist nicht die Sender-Seite, die das Problem macht, sondern der Empfänger. Ersetzt man den Empfänger durch "cat myfifo", kommen die Zeilen sofort. Wo sollte man denn beim Empfänger das l.flush() hinsetzen? Ole

4 5

Zeilengepuffertes r/w
by Ole Streicher 30 Aug '11

30 Aug '11

Hallo Gruppe, wie bekomme ich eine zeilengepufferte Kommunikation zwischen zwei Scripten hin? Ich habe folgende zwei Mini-Programme: Sender: ----------------------8<----------------- import time l = open('myfifo',mode='w',buffering=1) while True: s = 'einszweidrei' l.write(s + '\n') print s time.sleep(1) ----------------------8<----------------- Empfänger: ----------------------8<----------------- l = open('myfifo', buffering=1) for line in l: print line ----------------------8<----------------- wobei "myfifo" eine (per mkfifo angelegter) named pipe ist. Lasse ich jetzt die beiden laufen, erscheinen die Ausgaben im zweiten Programm stark verzögert, trotz des "line buffers", welches eingeschaltet war. Warum ist das so und wie kann ich das ändern? Viele Grüße Ole

5 5

Re: [Python-de] Zeilengepuffertes r/w
by Ole Streicher 30 Aug '11

30 Aug '11

Christopher Arndt <chris(a)chrisarndt.de> writes: > On 30.08.11 13:53, Ole Streicher wrote: >> Lasse ich jetzt die beiden laufen, erscheinen die Ausgaben im zweiten >> Programm stark verzögert, trotz des "line buffers", welches >> eingeschaltet war. >> Warum ist das so und wie kann ich das ändern? > Rufe deine Skripte mit "python -u" auf: -u Force stdin, stdout and stderr to be totally unbuffered. On systems where it matters, also put stdin, stdout and stderr in binary mode. "myfifo" ist nicht stdin, stdout oder stderr, daher hat diese Option keinen Einfluss -- wie man auch bei einem Test sieht. Ole

2 1

PyCon DE 2011- Frühbucherrabatt noch bis zum 31.08.2011
by Mike Müller 29 Aug '11

29 Aug '11

PyCon DE 2011 - Noch zwei Tage Frühbucherrabatt =============================================== Der Frühbucherrabatt gilt nur noch bis zum 31.08. Das ist der Link für die Anmeldung zur Konferenz und zu den Tutorials: http://de.pycon.org/2011/tickets/ Es stehen einige Hinweise auf der Seite. Bitte durchlesen. Hier nochmal kurz: * Für jedes Ticket bitte ein Formular ausfüllen. Beispiel: Anmeldung zur Konferenz und für zwei Tutorials macht drei ausgefüllte Formulare. * Die Bestellung geht ausschließlich mit Rechnung, die nach dem Erhalt per Überweisung zu bezahlen ist. Keine Kreditkarten, PayPal oder Ähnliches. Bitte alle Informationen für eine Rechnung eingeben. Das Vortragsprogramm ist hier: http://de.pycon.org/2011/schedule/lists/talks/ Der Zeitplan dazu wird in den nächsten Tagen veröffentlicht. Die erste PyCon DE 2011 findet vom 4. bis 9. Oktober in Leipzig statt. Mehr Information auf der Konferenz-Seite: http://de.pycon.org/2011. Viele Grüße, Mike Müller

1 0

Re: [Python-de] Hat Tornado mit Pypy ein Speicherleck?
by Stefan Scholl 26 Aug '11

26 Aug '11

Thomas Waldmann <tw-public(a)gmx.de> wrote: >> Start bei 24 MB. >> Nach 1.000.000 Requests (10 gleichzeitig): 166 MB >> Nach weiteren 1.000.000 Requests: 277 MB >> Noch einmal 1.000.000 Requests: 389 MB > > Glaub Du solltest nen Bugreport bei tornado einwerfen, das sieht ungut Rund 1 Tag vor meinem Posting in de.comp.lang.python habe ich das auch auf der Mailingliste von Tornado geschrieben. Gab keine Reaktion. Mindestens 1 große Site benutzt diese Kombination: Quora http://www.quora.com/Quora-Infrastructure/Why-did-Quora-choose-Python-for-i… -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/

2 3

Re: [Python-de] Hat Tornado mit Pypy ein Speicherleck?
by Stefan Scholl 26 Aug '11

26 Aug '11

Jens Diemer <python_gmane(a)jensdiemer.de> wrote: > Am 24.08.2011 14:15, schrieb Thomas Waldmann: >>> Start bei 24 MB. >>> Nach 1.000.000 Requests (10 gleichzeitig): 166 MB >>> Nach weiteren 1.000.000 Requests: 277 MB >>> Noch einmal 1.000.000 Requests: 389 MB >> >> Glaub Du solltest nen Bugreport bei tornado einwerfen, das sieht ungut >> aus. Wenn die dann nix selbst Verbrochenes finden (wo sie sich z.B. auf >> cpython-spezifisches Verhalten verlassen) und nen Bug in pypy vermuten, >> koennen sie es ja dann an pypy weiterreichen. > > Wie sieht denn die Sache mit CPython aus? Sind es ähnliche Werte, dann ist es > ein Problem von tornado. Wenn nicht, dann wohl ehr pypy Hatte auch mit CPython 2.6 getestet und es gab kein Problem. Aber wie im Ursprungs-Post gesagt: Andere Frameworks hatten auch Probleme, weil Files nicht mehr geschlossen wurden. Normales CPython hat das gleich erledigt wenn die Files nicht mehr refernziert wurden. Bei Pypy ist alles anders. Hier ist ein Patch (mit Beschreibung) für web2py: http://code.google.com/p/web2py/issues/detail?id=288 -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/

2 1

Könntest Du mein Freund sein?
by Alisa Lenz 25 Aug '11

25 Aug '11

Hallo! Ich bin eine Frau mit Geschlechtskrankheit. Es ist sehr schwer für mich. Könntest Du mein Freund sein? Hier ist mein Info: http://www.positivsingles.de/i/kristine Liebe Grüße Kristine

1 0

Re: [Python-de] Hat Tornado mit Pypy ein Speicherleck?
by Stefan Scholl 24 Aug '11

24 Aug '11

Diez B. Roggisch <deets(a)web.de> wrote: > On Wednesday, August 24, 2011 10:52:13 am Stefan Scholl wrote: >> Diez B. Roggisch <deets(a)web.de> wrote: >> >> ab -n 100000 -c 100 http://127.0.0.1:8888/ >> >> ==> 97m >> > >> > Auch wenn man sich natuerlich gerne fragt wofuer soviel Speicher - ist >> > das wirklich stetig steigend, oder geht es asymptotisch gegen eine >> > Maximalwert? >> > >> > So wie es im Moment aussieht steigt der Speicher pro 100000 Requests um >> > ca. 7-10MB. Bleibt das so? >> >> Werde im Laufe des Tages Ergebnisse mit höheren Request-Zahlen >> nachreichen. Start bei 24 MB. Nach 1.000.000 Requests (10 gleichzeitig): 166 MB Nach weiteren 1.000.000 Requests: 277 MB Noch einmal 1.000.000 Requests: 389 MB (Dazwischen ein paar Minuten Pause, weil händisch.) OK, 1 Mio Requests muss man erst erreichen. Kracht sicher nach 10 Jahren. Aber Leck ist Leck. > Noch eine Frage: warum *mehrere* Tornado-Prozesse? Das macht doch den Sinn des > ganzen etwas fragwuerdig. Oder willst du die an verschiedene Cores binden? Wie auch ohne PyPy: Wegen den mehreren Cores. Ist AFAIK auch empfohlenes Deployment von Tornado. Und wenn doch ein etwas länger blockiernder Request dazwischen kommt hängt nicht alles. Tschüs, Stefan -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/

3 2

Re: [Python-de] Hat Tornado mit Pypy ein Speicherleck?
by Stefan Scholl 24 Aug '11

24 Aug '11

Diez B. Roggisch <deets(a)web.de> wrote: >> ab -n 100000 -c 100 http://127.0.0.1:8888/ >> ==> 97m > > Auch wenn man sich natuerlich gerne fragt wofuer soviel Speicher - ist das > wirklich stetig steigend, oder geht es asymptotisch gegen eine Maximalwert? > > So wie es im Moment aussieht steigt der Speicher pro 100000 Requests um ca. > 7-10MB. Bleibt das so? Habe nicht weiter laufen lassen als bis dahin (bzw. gestern bis knapp über 100 MB, ohne zu notieren). Da Tests mit "--jit off" ebenfalls steigenden Speicherbrauch anzeigen (wenn auch geringer) dürfte es das nicht sein. Es sei denn es sind 2 unterschiedliche Leaks in PyPy selbst. Werde im Laufe des Tages Ergebnisse mit höheren Request-Zahlen nachreichen. Bei 200 MB breche ich es aber ab. Server haben zwar gut Speicher, aber bring's trotzdem nicht übers Herz einen Overhead von 200 MB für ein Mini-Programm zu akzeptieren. Zumal im Einsatz Tornado in mehreren Prozessen laufen wird/sollte. Falls die Geschwindigkeit wirklich benötigt werden sollte, werde ich eine Lösung finden. Bis dahin ist normales Python gut genug. (99 % aller Webprojekte könnten sogar mit lahmen Ruby laufen, ohne Cache und allem. Von daher ist das eher akademisch.) -- Web (en): http://www.no-spoon.de/ -*- Web (de): http://www.frell.de/

2 1