Unit-Abhängigkeiten visualisieren

[grizzly]

Danke für den intensiven Test! Das ist ja in der Tat ein sonderbares Verhalten.
Vielleicht habe ich aus unserem Firmentool vor Freigabe als "Freeware" doch zu viel rausgeschnitten (ich mußte einige firmeninterne Konstrukte und Analysen ausbauen).
Leider kann ich mir das erst heute abend ansehen.
Diese Parserei...

Dank und Gruß
Michael

[grizzly]

Zitat:

Welche Komponente zum anzeigen der Grafik verwendest Du denn ?
Bestimmt nicht TImage von Delphi, oder?

Doch. Ganz zu Anfang konnte man ja noch nicht im Graphen rumklicken und browsen. Da war das das bequemste, und es läuft ja noch immer...

Ich veranlasse dot.exe ja nicht ein JPEG oder ein GIF oder so etwas auszugeben. Ich verwende den Parameter -Tplain-ext. Die Datei temp.txt, die dabei erzeugt wird, beinhaltet alle Infos die ich brauche, um den Graphen selber zu zeichnen (Somit habe ich keine Probleme mit dem Skalieren oder dem Export als Vektor-Grafik). Gezeichnet wird natürlich auf ein separates Bitmap, welches nach fertigstellung ins Image kopiert wird.

Das mit dem selber-zeichnen ging auch nur, nachdem ich entdeckt habe, daß ich die zig Koordinaten, welche für die krummen Pfeile ausgegeben werden, mittels Canvas.PolyBezier identisch wie dot.exe ausgeben kann.


So, nu muß ich zurück an die Arbeit.
Bug-Hunting heute abend...

Gruß
Michael

[MaBuSE]

Zitat:

Zitat von grizzly

Bug-Hunting heute abend...

Und? Was gefunden?
:coder:

[grizzly]

Leider noch nicht, durfte bis kurz vor 23:00 bei 31° im Büro Überstunden schieben. Im Office mal wieder Hektik, Deadlines etc. Aber das kennt ihr ja alle ;)

Montag abend sollte ich hoffentlich dazu kommen.


Gruß
Michael

[grizzly]

So, nun hatte ich Zeit mir das mal anzusehen...

Das Problem ist:
Um die Liste der verwendeten Units aus dem Code zu lesen, verwende ich ein kleines Stückchen Code, welches aus einem Pascal-Source sämtliche Kommentare, strings und toten Code (wg. Compiler-Direktiven) rauswirft. Was bleibt, ist purer reiner Pascal Code. Und wenn ich da drin ein "Uses" finde, dann ist es das ein "echtes" (und keines in strings, Kommentaren etc.).

Nun ist dieser Code-Teil etwas alt. Der hat beispielsweise Probleme mit {$IF ..} und anderem neumodischen Kram.
Und in einer der Delphi Units kommt im Assemblerteil ein string in folgendem Format vor: "'". Wußte bis letzte Woche gar nicht, daß man das im asm Teil machen darf.
(Habe gerade gesehen, daß im Browser das >> "'" << gar nicht richtig zu erkennen ist. Also, das ist: Gänsefüßchen, Apostroph, Gänsefüßchen)

Lange Rede, kurzer Sinn: Weil ich es in absehbarer Zeit eh nicht schaffe, auf all' diese Konstrukte Rücksicht zu nehmen, wird UnitUsage bis auf weiteres Source-Code, bei dem es Probleme gab, nur noch ohne "Child" Units anzeigen. Nicht toll, aber wenigstens nicht so falsch wie vorher;)
Einige simplere neue Direktiven werden aber nun abgefangen, es bleiben somit nicht mehr allzuviele unbehandelte Units übrig.

Die 0.43 liegt nun im ersten Eintrag zu diesem Thread zum Download bereit.

Zusätzlich neu ist die Möglichkeit der Angabe eines Suchpfades. (Dann braucht man sich die RTL nicht mehr mit in das Source-Verzeichnis kopieren).
Außerdem habe ich begonnen einen Viewer mit einzubauen, aber dieses verd... TRichEdit ist dermaßen träge, daß damit niemand sowas wie windows.pas aufmachen sollte. Das dauert Minuten, bis das angezeigt wird!


Gruß
Michael

[himitsu]

Zitat:

Zitat von grizzly

Und in einer der Delphi Units kommt im Assemblerteil ein string in folgendem Format vor: "'". Wußte bis letzte Woche gar nicht, daß man das im asm Teil machen darf.
(Habe gerade gesehen, daß im Browser das >> "'" << gar nicht richtig zu erkennen ist. Also, das ist: Gänsefüßchen, Apostroph, Gänsefüßchen)

Wenn du wüstest, was alles möglich ist :lol:

wenn ich mal die Gelegenheit finde, stell ich dir mal ein paar meiner Units zusammen ... ich gehe ja öfters mal "unortodoxe" Wege und daher ist der entstehende Code ... nun ja, sagen wir mal gut für Testzwecke :stupid:

ich glaub MaBuSE (oder von wem das andere Programm dieser Art ist) war von sowas wie dem hier dodal geschockt und wunderte sich, dat dieses wirklich läuft.

Delphi-Quellcode:

Unit TestU;

Interface       
  {$INCLUDE FNS_VersionsCheck.inc}

  Uses Classes, Controls, Forms, StdCtrls, ExtCtrls, Math, PSAPI, Windows, SysUtils,

    FNS_Consts, FNS_Types, FNS_Memory, FNS_System,
    FNS_Messages, FNS_Languages, FNS_Forms,
    FNS_MathB, FNS_Log,

    FNS_Binary{, FNS_Colors{, FNS_DateTime}, FNS_Debug{, FNS_Files{, FNS_Hash{, FNS_Hints}, FNS_MemoryUT{, FNS_MemoryUT2}, FNS_Security, FNS_Strings{, FNS_Sys}, FNS_Unicode{,
    MSC_WinError}, FNS_ValueConvert, FNS_Thread{, FNS_SpeedZip{, FNS_XPStyle};

Mehrfach verschachtelte Kommentare sind echt witzig.
Und soein {$INCLUDE ...} an den unpassensten Stellen kommt bestimmt och geil. :roll:

[MaBuSE]

Zitat:

Zitat von himitsu

ich glaub MaBuSE (oder von wem das andere Programm dieser Art ist) war von sowas wie dem hier dodal geschockt und wunderte sich, dat dieses wirklich läuft.

Mich schockt nix mehr :-)

Das das läuft war mir klar, das es Programmier gibt, die so was auch wirklich machen, nicht :shock:

[himitsu]

Hey, dat is aus 'nem Testprogramm und da ändert sich ständig was an der Unitzusammenstellen (selbst die Prozeduren/Funktionen in dem Programm leben manchmal nichtmal 'ne Stunde lang) und da hab ich halt keine Lust ständig die Unitnamen neu einzugeben, sondern kommentiere halt Nichtbenötigtes aus.

Die Verschachtelung von { } und (* *) is och genial, wenn man mal kurzzeitig mehr, oder weniger radikal Code loswerden muß ._.

Und wie schön man speichersparend die selbe lokale Variable rekursiv in mehreren Prozeduren verwenden kann, könntest du dir ja hier ansehen.
> GetVolumePathNamesForVolume > speziell ResultBuffer :roll:

[grizzly]

Jaja, künstlerisch verstrickter Code zeigt die Schwächen der Parser am schnellsten. Wobei UnitUsage leider noch weit davon entfernt ist, sich nur noch an heimtückischen Codeteilchen zu verschlucken.
Ich denke allerdings, daß die verschachtelten Kommentare und das {$include ..} von UnitUsage mittlerweile ohne Schluckauf verdaut werden sollten. Aber ich hab' schon öfters geträumt, daß irgendwas eigentlich funktionieren sollte...

Die nächsten zwei Wochen werde ich nicht dazu kommen, UnitUsage aufzurüsten. Aber wenn ich dann mal den Parser etwas besser durchtrainiert habe, teste ich ihn gern an "unorthodoxen" Code-Beispielen ;)

Ob der Parser die Kommentare und die per conditional defines trocken gelegten Code Teile richtig erkannt hat, sieht man in UnitUsage mittlerweile über das View-Kommando (Rechter Mausklick auf Unit, egal ob Graph oder Liste). Solcher Text wird ausgegraut (cond. defines) oder blau/kursiv (Kommentare) dargestellt. Doch wie schon oben erwähnt: Blos keine großen Source-Codes damit ansehen. TRichEdit lädt sich zu Tode...


Gruß
Michael

[Gruber_Hans_12345]

also wirklich genial das teil, wäre cool, wenn du das mal opensource machen würdest ;)

• Wenn der Parser an ein File kommt, das ein anderer Prozess sperrt, zeigt er dieses zwar richtig an, aber nachher lässt sich auf der Oberfläche nichts mehr bedienen, und man muß den Prozess rauswerfen
• ein zoom und so wäre für den Graph ganz nett, man kann zwar exportieren, aber da kann man dann nicht so schön suchen ...
• da das erzeugen des graphen bei vielen units teils extrem lange dauert, wäre es vielleicht ne option, zuerst mal alle Units deselektieren, dann wenn man im tree eine unit selektiert, sollte in der Statusleiste auch die Infos angezeigt werden (genau so wie wenn man die unit im graphen selektiert)
• ich verwende in {$I DEFAULT.INC} und dieses Default.inc enthält nur eine einzige {$DEFINE DEBUG} ... die Sources was diese DEfault.inc einbinden kann er nicht parsen (ExceptionHandling.pas parsing error: " ExceptionHandling.pas Line 3: Unexpected end of file in comment started on line 4")