Unit tests für JCL/JVCL

[TurboMagic]

Und hier die nächsten Probleme:

In TestJclMath sind einige leere Testmethoden schon mal deklariert, aber noch nicht ausprogrammiert.
Eine davon konnte ich so wie eine bereits bestehende ausfüllen, aber diese beiden hier wollen nicht
so recht, dummerwise bin ich aber auch kein Mathe-Genie:

Delphi-Quellcode:

procedure TMathTranscendentalTest._ArcCsc;
var
  x: Extended;

begin
  x := -3.98;

  while x < -1 do
  begin
    CheckEquals(Math.ArcCsc(X), JclMath.ArcCsc(X), PrecisionTolerance);
    x := x + 0.1;
  end;

  x := 1.00;

  while x < 4 do
  begin
    CheckEquals(Math.ArcCsc(X), JclMath.ArcCsc(X), PrecisionTolerance);
    x := x + 0.1;
  end;
end;

Die _ArcCsc meckert, dass die Ergebnisse nicht übereinstimmen, obwohl beide verglichenen
Ergebnisse lt. DUnit log-Eintrag identisch sind. Da muss wohl der Fehler noch weiter hinten
in den Nachkommastellen liegen...

PrecisionTolerance: Float = 0.0000001;
Und Log-Meldung: expected: <-0,253977954770906> but was: <0,253977954770906>

Habe jetzt eben erst gesehen, dass das Vorzeichen falsch ist und ein Vergleich von Math.ArcCsc und JclMath.ArcCSc ergibt:
System.Math: Result := ArcSin(1 / X);
JclMath: Result := ArcSec(X / Sqrt(X * X -1));

Wer hat recht?

[TurboMagic]

Und ArcSec Test der analog zum ArcCsc von mir umgesetzt wurde läuft auch auf einen Fehler und hier
wird das auch in System.Math und JclMath unterschiedlich implementiert, wobei JclMath sogar die
Implementation von System.Math benutzt, wenn ein gewisses Define gesetzt ist.

JclMath: FArcTan(Sqrt(X*X - 1)); aber in ASM programmiert
System.Math: Result := ArcCos(1 / X);

Warum ist die Umsetzung in der JCL so anders?

[Rollo62]

Von der Jcl/JVcl bin ich über die Jahre ziemlich weggekommen.
Mein Eindruck war und ist dass dies ein unzusammenhängendes Sammelsurium aus mehr oder weniger Zuverlässigen und Unzuverlässigen Quellen ist.

Das sind ein paar Diamanten drin, aber IMHO auch viel Müll.

Würde es nicht Sinn machen zuerst mal die Spreu vom Weizen zu trennen,
und alte Zöpfe rauszuwerfen, oder zumindest separat zu trennen ?

Ein Neustart der Jedi könnte dem ganzen neues Leben einhauchen, denke ich.

Wer ist denn eigentlich genau zuständig für die Jedis, müssen da nicht Alle zustimmen, oder ist das Projekt schon verwaist ?
wie gesagt, ich hatte das schon seit Jahren ad Akta gelegt.
Sorry für die blöde Frage

[TurboMagic]

Hallo,

die Fragen sind nicht so blöde.

Es gibt noch Maintainer die Pull requests begutachten und commiten und dafür sorgen,
dass es mit der jeweils neuesten Delphi Version immer noch funktioniert.

Nur: wo was abschneiden? Wer nutzt was und was ist wertvoll genug um es aufzuheben?
Wieviel Gemecker gibt es, wenn man irgendwas entfernt, dass jemand benutzt hatte
der nun seinen Code ändern muss?

Also ich wäre schon mal dafür, dass man die mindestens benutzte Delphi Version mal
endlich von D6 "wegbewegt"! Zum Beispiel auf D2009 oder noch besser XE2 oder so,
wo die Generics dann mal anfingen soweit brauchbar zu werden.
Es bräuchte halt dann mehr Leute die sich wirklich dran beteiligen, denn wie du schriebst:
es sind auch ein paar wirklich nützliche Sachen drin!

Grüße
TurboMagic

[Rollo62]

Ich könnte mir vorstellen das man die Jedis splittet,
vielleicht in zwei Projekte.
Eins mit den guten Teilen, und eins darauf aufbauend mit dem Müll.
So können die welche die schlechten Teile nutzen noch weiterarbeiten,
wissen aber das diese nicht mehr viel gepflegt wird.

Während der gute Jedi-Teil dann schlank, aufgeräumt und vielleicht neues Leben bekommt (ist aber nur eine vage Hoffnung).

Ich installiere die z.B. nicht mehr wegen dem ganzen Code-Bloat und der unnützen Kmponenten die man dan immer mit rumschleppt.
Ohne das würde ich mich damit wieder mal beschäftigen wollen.

Vielleicht bin ich der Einzige der so denkt

Anfangen:
Am Besten erstmal die am seltensten gepflegten Komponenten identifizieren, und rauswerfen (ich schätze mal so 40%).
So bleibt schonmal der mehr oder weniger aktive Kern übrig.

[TurboMagic]

Hallo,

deine Idee ist grundsätzlich nicht verkehrt, aktuell bin ich aber ein bisschen an der JCL,
da gibt's ja keine Komponenten.

Ich hab' z. B. vorhin deren Unicode Support auf v13 aktualisiert, aber mich mal wieder in Git
verheddert und somit einen Pullrequest fabriziert, der zuviele Dateien enthält. Keine Ahnung
wie ich die wieder rausbekomme oder ob das einer der Maintainer machen muss...

Grüße
TurboMagic

[Stevie]

Zitat von TurboMagic:

Keine Ahnung wie ich die wieder rausbekomme

Wenn du im Unicode_V13_Support branch bist:

git rebase onto <commit vor dem, den du behalten willst> <commit auf dem dein commit basieren soll>
Sollten die commits, die du behalten willst und die du entfernen möchtest, vermischt sein:
git rebase -i <commit vor dem ersten commit, den du anpassen/entfernen willst>


Dann git push --force

Pullrequest wird automatisch aktualisiert

[TurboMagic]

Zitat von Rollo62:

Während der gute Jedi-Teil dann schlank, aufgeräumt und vielleicht neues Leben bekommt (ist aber nur eine vage Hoffnung).

Ich installiere die z.B. nicht mehr wegen dem ganzen Code-Bloat und der unnützen Kmponenten die man dan immer mit rumschleppt.
Ohne das würde ich mich damit wieder mal beschäftigen wollen.

Anfangen:
Am Besten erstmal die am seltensten gepflegten Komponenten identifizieren, und rauswerfen (ich schätze mal so 40%).
So bleibt schonmal der mehr oder weniger aktive Kern übrig.

So, ich hab da mal was anderen ortes geschrieben:
https://newsportal.delphi-jedi.org/t...p=jedi.general

Es dürfen sich dort gerne alle einbringen, d.h. mitdiskutieren.
Wer's nicht kennt: das oben verlinkte ist das Webinterface zu den klassischen NNTP Style Newsgroup vom JEDI Projekt.

[TurboMagic]

Zitat von Rollo62:

Während der gute Jedi-Teil dann schlank, aufgeräumt und vielleicht neues Leben bekommt (ist aber nur eine vage Hoffnung).

Ich installiere die z.B. nicht mehr wegen dem ganzen Code-Bloat und der unnützen Kmponenten die man dan immer mit rumschleppt.
Ohne das würde ich mich damit wieder mal beschäftigen wollen.

Vielleicht bin ich der Einzige der so denkt

Anfangen:
Am Besten erstmal die am seltensten gepflegten Komponenten identifizieren, und rauswerfen (ich schätze mal so 40%).
So bleibt schonmal der mehr oder weniger aktive Kern übrig.

Es gibt dazu hier inzwischen eine Diskussion:
https://newsportal.delphi-jedi.org/t...p=jedi.general

Ruhig mal teilnehmen, entweder per Newsreader (z. B. Thunderbird, Xananews oder was auch immer) oder über das Web Frontend.