Seite 1 von 1

timer bleibt stehen- nur unter windows

Verfasst: Dienstag 30. März 2010, 10:08
von pPilger
Hallo,
ich habe folgendes Problem.
In meinem Script benutze ich die after-Methode um regelmäßig eine Funktion aufzurufen.
Nun funktioniert es einwandfrei unter linux und unter win, wenn ich es als py-script ausführe.

Ich möchte aber unter win das DOS-Fenster unterdrücken und starte es als pyw.
Bei dieser Variante bleibt das Script einfach nach ca. 370 Durchläufen stehen. Ohne Fehlermeldung.
Starte ich es über IDLE läuft es problemlos.

Entferne ich den einzigen print-Befehl in der Funktion "lets_rock" geht es.

Das richtige script ist natürlich viel umfangreicher. Ich habe es "zurückgebaut" um den Fehler einzugrenzen.

Es nützt in meinem normalen Programm aber nichts dieselbe Zeile zu entfernen, es bleibt trotzdem stehen, nur nach einer anderen Anzahl von Durchläufen.

Ich denke der Code ist hier nicht zuviel!?

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from Tkinter import *
from ScrolledText import ScrolledText
import sys

class po_logging( object ):
    
    def __init__(self):
        # generell
        self.log_counter = 0

class my_form( Frame ):

    def __init__(self, master=None):
        Frame.__init__(self, master)
        self.pack()
        self.createWidgets()

    def createWidgets(self):
        self.textBox = ScrolledText(self, height=5, width=80)
        self.textBox.pack()
        self.textBox.insert(END, "In the Beginning...\n")
        
        self.listenID = self.after( 500, self.lets_rock )

    def lets_rock( self  ):
        print "lets_rock " 
        po.log_counter += 1
    
        self.textBox.delete('1.0', '3.end')
        self.textBox.insert( END, str(po.log_counter) + "\n" )
        
        self.listenID = self.after(100 , self.lets_rock)

if __name__ == "__main__":
    po = po_logging()
    root = Tk()
    mything = my_form(root)
    mything.master.title ( "Timer-Test" )
    root.mainloop()
    sys.exit()

 
Also ich bin neu bei Python und weis mir hier keinen Rat.
Danke für die Hilfe.

Verfasst: Dienstag 30. März 2010, 10:32
von HWK
Das kann ich nachvollziehen (Python 2.6 unter Windows XP). Mit Print bleibt das Skript bei 372 stehen, ohne habe ich das Programm bei deutlich mehr als 1000 abgebrochen. Weshalb verwendest Du übrigens Print, wenn Du die Konsole sowieso unterdrückst?
Habe ich Dich richtig verstanden, dass Dein eigentliches Programm auch ohne Print stehen bleibt? Dann ist Dein Code-Schnipsel aber nicht repräsentativ.
MfG
HWK

Verfasst: Dienstag 30. März 2010, 10:51
von pPilger
HWK hat geschrieben:Das kann ich nachvollziehen (Python 2.6 unter Windows XP). Mit Print bleibt das Skript bei 372 stehen, ohne habe ich das Programm bei deutlich mehr als 1000 abgebrochen. Weshalb verwendest Du übrigens Print, wenn Du die Konsole sowieso unterdrückst?
Habe ich Dich richtig verstanden, dass Dein eigentliches Programm auch ohne Print stehen bleibt? Dann ist Dein Code-Schnipsel aber nicht repräsentativ.
MfG
HWK
Hallo,
die print-Ausgaben sind eigentlich nur fuer mich zur Kontrolle, bzw. zum debug. Ich habe davon natürlich "tausende" in meinen scripten.
Ich kann aber nicht nachvollziehen, weshalb das zum stopp führen soll.

Aber die eigentliche Frage: Was ist repräsentativ?
Ich habe mein script Stück für Stück "zurückgebaut". Also funktion um funktion entfernt. Jedesmal hat sich die Anzahl der Durchläufe verändert, meistens erhöht. Jedesmal dachte ich, ich hätte es, aber es ist halt nur später stehen geblieben. Nun ist halt das übriggeblieben.

Also ich kenn mich mit Python noch nicht aus, rätsle da zur Zeit nur herum. Eine print-ausgabe muss das doch verkraften!
Danke für die Hilfe.

Verfasst: Dienstag 30. März 2010, 17:38
von HWK
Wahrscheinlich werden die Ausgaben irgendwo gespeichert und wenn dieser Speicher voll ist, dann...
Vermeide doch einfach die Ausgaben, wenn Du sie nicht mehr zum Debuggen benötigst. Dazu kannst Du Dir ja eine eigene Print-Funktion schreiben, die z.B. Ausgaben nur macht, wenn ein Debug-Flag gesetzt ist.
MfG
HWK

Verfasst: Dienstag 30. März 2010, 20:46
von BlackJack
Oder einfach mal mit dem `logging`-Modul beschäftigen, denn genau das scheint ja die Absicht zu sein.

Verfasst: Dienstag 30. März 2010, 21:56
von pPilger
HWK hat geschrieben:Wahrscheinlich werden die Ausgaben irgendwo gespeichert und wenn dieser Speicher voll ist, dann...
Vermeide doch einfach die Ausgaben, wenn Du sie nicht mehr zum Debuggen benötigst. Dazu kannst Du Dir ja eine eigene Print-Funktion schreiben, die z.B. Ausgaben nur macht, wenn ein Debug-Flag gesetzt ist.
MfG
HWK
Ja, ich hab inzwischen alle "prints" unschädlich gemacht, und nun läuft es schon einige Stunden ohne zu murren. Aber dort hätte ich den Fehler nie vermutet...
Danke für die Hilfe!