[ORP] Diskussion der Import-Klasse

[Mithrandir]

(Prolog: Wie einige von euch sicher wissen, arbeite ich momentan an einem Routenplaner auf Basis der Daten von OpenStreetMap. Um Threads zu kennzeichnen, die sich speziell mit diesem Projekt beschäftigen, nutze ich die Zeichenfolge "[ORP]". ("Orp, orp..." :stupid: )

Hi ihr,

es ist soweit. Der erste Teilschritt auf dem Weg zum Routenplaner ist geschafft. Dabei handelt es sich um die Klasse, die die XML-Datei verarbeitet, die Daten für die Datenbank aufbereitet und in eine Firebird-Datenbank schreibt.

Da mein letztes Delphi-Programm ja schon etwas her ist (tjaja...), wäre es mir ganz lieb, wenn ihr einen Blick auf meine Klassenimplementation werfen könntet.

Ich bekommen, wenn ich den Import abbreche (einfach das Programm schließen) eine Exception, außerdem steigt der Speicherverbrauch aus welchen Gründen auch immer während des Imports exorbitant an. Vermutlich gibt es irgendwo ein oder mehrere Speicherlecks, die ich einfach übersehe. Ich habe mich schon mit MemCheck abgemüht, aber nicht wirklich Erfolg gehabt. Vielleicht kann einer von euch damit besser umgehen?

Um euch das Testen einfacher zu machen, befindet sich im Anhang eine OSM-Testdatei, die ich ein wenig zusammengestaucht habe. Die Originaldatei ist 25 MB groß, diese nur noch 1,5 MB, beinhaltet aber alles, was man zum Testen brauch'. Außerdem würde die Datenbank eigentlich im Anwendungsdatenverzeichnis des akutellen Nutzers liegen. Für Testzwecke liegt sie jetzt aber im Programmverzeichnis, damit ihr nicht erst durch alle Verzeichnisse springen müsst.

Ebenfalls mit dabei ist der Firebird Embedded in der Version 2.1.

Zum erfolgreichen kompillieren benötigt ihr noch die ZEOSLib, der Download dazu findet sich hier [Sourceforge, 1.6 MB]

Das Projekt hat ebenfalls schon einen "richtigen" Namen bekommen: OpenRoutePlanner. Einen entsprechenden Blog dazu gibt es auch schon.

Ich weiß, dass da noch ein riesiger Berg an Arbeit vor mir liegt, aber mit eurer Hilfe klappt das schon... ;)

Noch ein kleiner Hinweis: Die Eingabemaske prüft nicht, ob der eingegebene Pfad korrekt ist. Außerdem wird der Starten-Button nicht deaktiviert. Ich hoffe, ich habe sonst alles beachtet. :stupid:

[DP-Maintenance]

Dieses Thema wurde von "mkinzler" von "Object-Pascal / Delphi-Language" nach "Open-Source" verschoben.
Ist ja ein Projekt, dass im Source vorliegt

[oki]

Hi,

ich glaube, deine Schutzverletzung beim Beenden kommt daher:

Delphi-Quellcode:

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  if Assigned(OSMParser) then
    OSMParser.Destroy;
end;

Ich dächte, dass ist sicherer sollte der Thread noch immer da sein:

Delphi-Quellcode:

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  if Assigned(OSMParser) then begin
    OSMParser.Terminate;
    OSMParser.WaitFor;
    FreeAndNil(OSMParser);
  end;
end;

Mehr hab ich nich nicht durchgesehen. Compiling ging auch noch nicht. Bei mir werden die Units ZConnection, ZDataSet angemeckert.

Gruß oki

[alzaimar]

Speicherlecks und ähnliche Missgeschicke findet man zuverlässig mit FastMM.

[Mithrandir]

Zitat:

Zitat von oki

Ich dächte, dass ist sicherer sollte der Thread noch immer da sein:

Delphi-Quellcode:

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  if Assigned(OSMParser) then begin
    OSMParser.Terminate;
    OSMParser.WaitFor;
    FreeAndNil(OSMParser);
  end;
end;

Ok, das habe ich jetzt mal so umgesetzt. Musste gleichzeitig noch ne andere Schleife anpassen. Jetzt meldet mir FastMM immer noch eine Verletzung...

Zitat:

Zitat von oki

Mehr hab ich nich nicht durchgesehen. Compiling ging auch noch nicht. Bei mir werden die Units ZConnection, ZDataSet angemeckert.

Argh. Mein Fehler. Die beiden angemeckerten Units gehören zur ZEOSLib, download findet sich hier[@Sourceforge, 1.6 MB].

Das Speicherleck konnte ich nicht komplett beheben, der Speicherverbrauch steigt zwar nicht mehr in den riesen Schritten wie vorher, aber er steigt halt immer noch.

Folgende Änderungen habe ich gemacht:

ORP_Extractor.pas, Zeile 538, folgendes hinzugefügt:

Delphi-Quellcode:

FreeAndNil(fRegAttrExpr);

ORP_Extractor.pas, Zeile 219, folgendes hinzugefügt:

Delphi-Quellcode:

  FreeAndNil(fRegEx);

ORP_Extractor.pas, Zeile 202, folgendes kursiv hinzugefügt

Delphi-Quellcode:

 while (fRegEx.MatchAgain) and (dwLenStr - dwCurPos > 20) [i]and not Terminated[/i] do

Ich lade oben gleich mal die neue Version hoch. Was mir beim FastMM-Log aufgefallen ist, ist dass der Trace Stack auch über die Funktionen der ZeosLib rüberläuft. :gruebel: Ich hänge den Log mal hier mit an...

[himitsu]

hab jetzt noch nicht seht weit reingesehn, aber schon in der ersten Datei ...

Delphi-Quellcode:

procedure TForm1.UpdateProgressbar(Sender: TObject; Cur: Integer; Max: Int64);
begin
  ProgressBar1.Max := 100;
  ProgressBar1.Position := Round((Cur / Max)*100);
  Form1.Caption := IntToStr(ProgressBar1.Position) + ' % ' + Format('Speed: %3.3f Sec.', [(GetTickCount - Tick)/1000]);
end;

Delphi-Quellcode:

// warum war Cur als Integer und Max als Int64?
// bei Dateien über 2 GB wäre Cur wohl etwas überlastet
procedure TForm1.UpdateProgressbar(Sender: TObject; const Cur, Max: Int64);
begin
  // kann man auch einmal direkt im OI zuweisen
  //ProgressBar1.Max := 100;

  // weiß jetzt nur nicht was schneller ist,
  // aber vermutlich doch die in der FPU, als emulierten 64-Bit-Operationen ...
  // hab also nix gesagt ._.
  ProgressBar1.Position := (Cur * 100) div Max * 100;

  // wenn eh schon Format da ist, warum nicht gleich weiternutzen ;)
  Form1.Caption := Format('%d%% Speed: %3.3f Sec.', [ProgressBar1.Position, (GetTickCount - Tick) / 1000]);
end;

[Mithrandir]

Zitat:

Zitat von himitsu

Delphi-Quellcode:

// warum war Cur als Integer und Max als Int64?
// bei Dateien über 2 GB wäre Cur wohl etwas überlastet

Dit war noch aus dem ersten Versuch, als ich Max und Position die Werte direkt zugewiesen habe und nicht über die Prozentrechnung gegangen bin... wird gefix... :oops:

Zitat:

Zitat von himitsu

Delphi-Quellcode:

  // wenn eh schon Format da ist, warum nicht gleich weiternutzen ;)
  Form1.Caption := Format('%d%% Speed: %3.3f Sec.', [ProgressBar1.Position, (GetTickCount - Tick) / 1000]);
end;

Wird auch noch angepasst, wobei man ja dazu sagen muss, dass das Fehler sind, die die Unit nicht direkt betreffen. :stupid: Das Testprogramm nutze ich nachher ja nicht weiter...

[himitsu]

Also die Definition der Callbackprozedur ist schon 'ne Sache aus der Unit. :nerd:

[Mithrandir]

Zitat:

Zitat von himitsu

Also die Definition der Callbackprozedur ist schon 'ne Sache aus der Unit. :nerd:

*knirsch* Stümmt... :oops:

[hazard999]

Form1.Caption := Format('%d%% Speed: %3.3f Sec.', [ProgressBar1.Position, (GetTickCount - Tick) / 1000]);

wenn ich sowas schon seh *argh*

Caption := Format('%d%% Speed: %3.3f Sec.', [ProgressBar1.Position, (GetTickCount - Tick) / 1000]);

self.Caption := Format('%d%% Speed: %3.3f Sec.', [ProgressBar1.Position, (GetTickCount - Tick) / 1000]);

was besser gefällt

aber ja nicht Form1...


warum verwendest du das Testprogramm nicht weiter?

super Vorlage für einen Unit-Test oder ein Demo.