Seite 3 von 3 ErsteErste 123
Ergebnis 31 bis 38 von 38

Thema: PyLint

  1. #31
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896
    Ich habe die Beschreibung jetzt noch mal aktualisiert und die bereits bekannte Beschreibung, wie ich Pylint installierte, eingefügt.
    Außerdem habe ich ein Batch-Skript beigelegt, dass Pylint so aufrufen würde, wie ich es mir gedacht hätte.

    Mein einziger Ratschlag, den ich jetzt noch habe: Pylint deinstallieren und es noch mal über meinen Weg installieren (Wäre dann Version 1.7.X). Getestet habe ich es auf einem Windows 7-System, wo der Fehler mit den Imports dann nicht auftritt.

  2. #32
    Registrierter Benutzer
    Registriert seit
    21.03.12
    Beiträge
    22.397
    Welche Pythonversion nutzt du dafür? Python2.4 haut mir direkt das get-pip um die Ohren:

    PHP-Code:
      File "get-pip.py"line 43
        _b85alphabet 
    = (b"0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"
                                                              
    ^
    SyntaxErrorinvalid syntax 
    Ansonsten hab ich nen Haufen kleiner Bugfixes und Formatierung gepusht.

  3. #33
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896
    Python 2.7

    Mit Python 2.4 geht es leider nicht mehr. Da kommt man nur noch von einem Problem zum nächsten.
    Du kannst es wahrscheinlich auch mit deiner Python3-Version nutzen. Ist es so eingerichtet, dass du dafür nur python3 statt python eintippen musst?

  4. #34
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896
    Zitat Zitat von Flunky Beitrag anzeigen
    Ansonsten hab ich nen Haufen kleiner Bugfixes und Formatierung gepusht.
    Guter Hinweis, merge ich

  5. #35
    Registrierter Benutzer
    Registriert seit
    21.03.12
    Beiträge
    22.397
    Findet alles soweit.

  6. #36
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896

    Neue Debug-Features

    Ich will noch keinen neuen Thread aufmachen, aber habe noch zwei neue Ideen für ein verbessertes Debugging im Git gepusht (Achtung, im CvEventManager habe ich meine Test-Exception 'x=1/0' im Rundenwechsel-Callback vergessen. ).

    1. Erweiterung der Exception-Fehlermeldungen durch Auflistung aller lokalen Variablen.
    2. Ein Debugger-Interface wie pdb, aber übers Netzwerk. (Ähnlich zu meiner anderen Idee (Civ4ShellBackend.py), aber unabhänig davon.)

    Vermutlich leidet die Performance zu stark, wenn man 1. aktiviert. Aber probieren wir es erst einmal aus.
    (Das kann ich auf meinen alten Kisten schlecht testen, da da eh alles sehr langsam läuft…)


    Für 1. habe ich den Funktions-Handler CvUtil.myExceptHook durch einen eigenen ersetzt: ExtendedDebug.extendedExceptHook

    Damit ich in der Exception an die Variablen komme muss ich diese zwischenspeichern, da der Kontext der Variablen normalerweise schon nicht mehr vorhanden ist. Dafür habe ich per sys.settrace einen Hook eingesetzt, was Python nat. ziemlich ausbremmst. Mit den Daten kann ich die lokalen Variaben dann mit ausgeben, Beispiel:
    Bild


    Für 2. habe ich das Modul remtote_pdb.py auf Python 2.4 zurückportiert. Wenn man die Variable ExtendedDebug._USE_REMOTE auf True setzt, stoppt das Programm und man kann einen Debugger per Telnet oder Netcat anhängen:
    Code:
    telnet 127.0.0.1 4444  # oder
    nc -C 127.0.0.1 4444

    Flunky, was meinst du? Ist das für dich, ggf. mit ein paar Anpassungen brauchbar?
    Habe es im Git gepusht, wobei die neuen Datein in Extras zu finden sind. Da habe ich auch die Civ4Shell-Datei hin verschoben.
    Angehängte Grafiken Angehängte Grafiken

  7. #37
    Registrierter Benutzer
    Registriert seit
    21.03.12
    Beiträge
    22.397
    Das ist mir grad zu hoch Die Ausgabe sieht klasse aus, aber bis auf die elenden "unidentifiable C++ exception" und CtDs war die Lokalisation der Fehler bislang kein Problem. Die schwierigen Fehler zeichnen sich ja gerade dadurch aus, in Python nichts zu werfen.

  8. #38
    ε•ω=1 Avatar von Ramkhamhaeng
    Registriert seit
    19.07.10
    Ort
    Aralkum
    Beiträge
    9.896
    Bei der Ausgabe hatte ich gehofft, dass die Screenshots der Fehlermeldungen uns gleich die Variable anzeigen, die -1/None ist

    Zitat Zitat von Flunky Beitrag anzeigen
    Die schwierigen Fehler zeichnen sich ja gerade dadurch aus, in Python nichts zu werfen.
    Das die Schwierigen nix werfen stimmt im dümmsten Fall kann man mit der Debug-DLL nicht einmal nen Breakpoint setzen, da an der Crashstelle das Kind schon in den Brunnen gefallen ist (Kein ordentlicher Funktionen-Stack mehr vorhanden. )

    Wenn du die zugehörige kritische Stelle im Code schon kennst, könnest du nun aber zumindest kurz vorher ein
    RemotePdb('127.0.0.1', 4444).set_trace() einfügen und dann die Python Variablen/Argumente, etc. vor dem Crash remote untersuchen.
    Gebe aber zu, dass die Bedienung gewöhnungsbedürftig ist, falls du noch nie mit dem gdb/pdb gearbeitet hast. Dann lasse es erst mal links liegen

    Ich würde vorschlagen, die erweitete Fehlermeldung aber mal testweise vor dem Release zu aktivieren.

Seite 3 von 3 ErsteErste 123

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •