Eure Anregungen für das DEC 5.3 gebraucht

[Luckie]

Ich hoste es nur. Kann dir aber leider auch nichts dazu sagen.

[MaBuSE]

Zitat von alphaflight83:

Deswegen die Frage: Weiß jemand, ob da noch was geht, oder ist das Projekt wirklich tot, wie MaBuSE schon vermutet hat?
(Nicht dass die Wahrscheinlichkeit ein halbes Jahr nach dieser Vermutung geringer geworden wäre )

Es ist nicht tot. Es schläft

Ich habe mit Assertor auf den DelphiTagen 2011 gesprochen.
Er hat im Moment wenig Zeit, entwickelt aber hin und wieder an dem Projekt.
Es ist im Moment nur nicht in einem Zustand, dass man es veröffentlichen könnte (Baustelle).

Aber ich bin zuversichtlich, dass es irgendwann kommt

[Codehunter]

Ich bin gerade auf diesen Thread aufmerksam geworden. Mich würde interessieren, in welchem Zusammenhang die DEC-Version 5.3 von Assertor zur 5.1 von Hagen Reddmann steht. Ist das eine abgestimmte Weiterentwicklung oder eher ein Fork?

[alphaflight83]

Assertor hat das DEC seit der letzten Version 5.2 in Abstimmung mit Hagen weitergeführt.
Siehe Release-Blogeintrag zu 5.2

Edit: Im Blog ist dann auch ein Eintrag von gestern zu finden, der MaBuSEs Post bestätigt.

Zitat:

If I am able to find some spare time ...

Na, dann wünsche ich schon mal jede Menge Freizeit

[Assertor]

Hallo DP Community,

ich scheine keine Benachrichtigungen mehr für meine (sehr) alten DP Threads zu bekommen, da übersieht man schlicht manche Diskussion. Mea culpa!

Nun zum aktuellen Stand:

Die Kurzfassung
Die DEC ist nicht tot, aber nicht x64-kompatibel.

Die Langfassung
Wie richtig erahnt wurde, kamen andere Dinge dazwischen. Nennen wir es Leben, vorrangig aber Arbeit. Ich bin eben nicht in einer Position, wie z.B. angestellte Entwickler, die nach einem 8-10 Stunden Arbeitstag in einer 5 Tage-Woche sich Ihren Interessen widmen können, sondern stehe als Selbständiger immer an vorderster Front.

Seit Eröffnung dieses Threads ist viel Zeit vergangen. Ich habe das damalige Feedback aufgegriffen und experimentell an der DEC weitergearbeitet. Dies bezieht sich auf Umstrukturierung, neue Kompatibilitätsansätze zu alten Versionen und einer besseren Unicode Unterstützung, insbesondere durch extensive Nutzung von Bytes statt Chars, wo immer möglich.

Diese ganzen Änderungen hatten noch nichts spezifisch mit Delphi 2010, XE oder XE2 zu tun. Nun kam das absehbare XE2 Release. Wie einige von mir wissen, bin ich hauptsächlich im Indy Project aktiv. Wer jetzt die Verbindung und Abhängigkeit von Indy und Delphi kennt, kann 1 und 1 zusammenzählen und sich denken, was vor dem XE2 Release bei Indy los war. Ergo blieb weniger als keine Zeit, um mich zeitnah um die DEC zu kümmern.

@Codehunter: Ich habe es so aufgefasst, dass ich das Projekt übernommen habe, in Übereinstimmung und mit Hagens Segen - ohne das für Ihn hieraus Verpflichtungen oder Aufwand entstehen. Es ist also eine Weiterentwicklung, kein Fork. Wir standen hierfür auch - bei Diskussionsbedarf - über dieses Forum hinaus in Kontakt.

Es steht natürlich jedem Frei, einen eigenen Fork anzulegen. Besser wäre imo aber in diesem Fall eine Beteiligung an diesem Projekt!

Der Zukunftsplan

1. Schritt: Ich muss meine experimentellen Änderungen von Mai 2010 wieder aufgreifen, ein Diff/Merge auf den 5.2 Source fahren, um zu sehen, wo ich genau war und was mich aufhielt. Dieser Source wird hoffentlich zeitnah in einem XE2 x32 Release mit einigen Fehlerbereinigungen, verbesserter Unicode-Unterstützung und Kompatibilitätspatches münden. Alte D5-D7 DCUs-only von Hagen fliegen raus, ASN1/CPU Unit wahrscheinlich ebenfalls.

Das ganze am liebsten garniert mit Unittests (u.a. Monte Carlo Tests für AES) und einem besonderem Bonbon an dem ich arbeitete. Ich hab dieses Subprojekt DEC CryptoLab getauft.

Das ganze kann leider noch etwas dauern, da ich bis Ende März vollständig "ausgebucht" bin und sich schon das nächste Großprojekt anbahnt.

2. Schritt: Ich muss prüfen, *ob* sich der ASM Source in den notwendigen Bereichen zu PurePascal portieren lässt. Dies ist nicht ohne weiteres möglich.

Als gute Analogie denke man an Komponenten/Tools wie Tb2k/SpTBXLib, madExcept etc.pp., diese sind aktuell ebenfalls nicht x64-fähig. Teilweise gibt es auch keine Zeitpläne von kommerziellen Komponentenherstellern!

Der Umfang einer Portierung in diesem Bereich ist ungleich größer gegenüber der Unicode Portierung von D2009. Jeder der in einem Produktivsystem einen Wechsel über die D2007/2009-Barriere vollziehen durfte, weiß welche Probleme es gab. Dies ist im Vergleich zum jetzigen Umstellungsaufwand "Pille-Palle" (TM).

Ich werde es mir ansehen und mein möglichstes tun. Es soll aber jeder, der Druck macht, sich diese ganze Umstände nocheinmal verinnerlichen. Ich erhalte zu diesem Thema viele Mails, die wegen der x64 DEC fragen - und das bereits wenige Tage nach dem offziellen XE2 Release.

Fakt: Es ist OpenSource, ich arbeite alleine an diesem Projekt, ich habe wenig Freizeit. Der Delphi x64 Compiler unterstützt nur x64 ASM oder Pascal, kein Mixed-Mode, wie in x32. Und Andreas Hausladen (jbg) hat auch kürzlich hier in einem Thread ein ASM Bug im x64 Compiler bestätigt, der mich ebenfalls nerven wird. Schöne neue Welt.

Gerade die DEC muss nunmal eben mit Vorsicht gepflegt werden, da hier schnell kleine Fehler zu großen Problemen führen. Qualität dauert eben länger, ich will nicht jedes Jahr im August ein neues DEC Release raushauen, nur um die Versionsnummern zu erhöhen und mit Compilerherstellern gleich zu ziehen

Ich würde aber jedem empfehlen, den Einsatz von x64 immer an gute Unittests zu koppeln

Also getreu dem etwas angepassten Motto "le DEC est mort, vive le DEC", wird es weitergehen. Nur nicht als DEC 5.3, sondern als DEC 6.0. Falls mich jemand unterstützen möchte, z.B. beim PurePascal Port, Freiwillige vor! Dies würde ja auch z.B. der FPC-Kompatibilität helfen.

Auf jedenfall danke ich mabuse für die korrekte Weitergabe der Info von den DT 2011 Der 20er sollte aber keine Bestechung hierfür sein

@alphaflight83: Danke Mehr Freizeit wünsch ich mir selbst auch immer

Viele Grüße
Assertor

P.S: @Luckie - Das ist mein offizielles Statement

Offizielle Downloadseite: http://dec.michael-puff.de

[blackdrake]

Ein sehr großer Wunsch von mir war ja immer die Asynchrone Verschlüsselung zu Implementieren. Ich bin deswegen sogar von Delphi abgedriftet, da es für OpenSource Projekte keine PKI Implementierungen gibt. In Java kann man mit 5 Quelltextzeilen eine asynchrone Verschlüsselung hinbekommen.

Einen Bug, den ich damals fand war, dass der Shark Cipher nicht funktioniert. Beim Ver- und Entschlüsseln kommen unterschiedliche Ergebnisse raus.

Gruß
blackdrake

[Codehunter]

@Assertor:

Zuerstmal ein gesundes und erfolgreiches neues Jahr!

Falls du meine Frage als Kritik aufgefasst haben solltest, es war nicht als solches gemeint. Ich bin schon lange Anwender der 5.2er und damit mehr als zufrieden. Dass es überhaupt eine Weiterentwicklung gab/gibt hat mich ehrlich gesagt ein wenig überrascht, ich verfolge die DP ja auch nicht in allen Einzelheiten und bin eben eher zufällig über den Thread hier gestolpert.

Warum ich nach einem Fork bzw. Nicht-Fork fragte hat einen aktuellen Grund: Open-Libre-Office. Als Anwender (!!!) weiß man nicht, in welche Richtung man schwenken soll. Libre ist besser, Open ist populärer. Inzwischen gibt es die ersten Inkompatibilitäten.

Übertragen auf DEC muss man als Anwender dann damit rechnen, dass Anwendungen der älteren 5.2er, die ja nach wie vor in der weiten Welt genutzt werden, möglicherweise nicht mit Anwendungen basierend auf einem neueren DEC arbeiten würden. Da frage ich lieber vorab mal genauer nach.

Betreffs x64: Ich sehe das mit gemischten Gefühlen. Einerseits ist x64 ein Verkaufsargument, andererseits ist der Portierungsaufwand generell schon teils erheblich. Verschläft man den Punkt X kanns passieren dass einem die Konkurrenz irgendwann mit x64-Produkten das Wasser abgräbt. Ist man aber vorzeitig dabei, verschenkt man unnütz Portierungsaufwand.

Im Moment ist in der Delphi-Szene noch nicht viel zu reißen mit x64. Die größeren Komponentenanbieter sind auch noch nicht am Start und wenn dann mit Teilmengen der Komponenten oder mit Pre-Alphas. Für manche Projekte bringt x64 auch schlicht keine Vorteile (z.B. weil man nicht so viel RAM braucht). Da ist inzwischen Multithreading fast interessanter als 64 Bit.

[Assertor]

Hallo Codehunter,

danke, Dir (und allen anderen) auch ein frohes, gesundes Neues Jahr!

Nein, kein Problem - ich hab das nicht als Kritik aufgefasst. Meine Forumulierung war um die Uhrzeit nicht mehr ideal. Ich weiß, dass hier im Forum z.B. ein FPC Portierungsversuch läuft. Das wäre dann ein Fork, von meinem Standpunkt aus.

Zur Kompatibilität:
Ich werde den Source der DEC 6 so kompatibel wie möglich machen. Als Ziel habe ich mir 99% vorgenommen. Es wird sich bei der Identitybase nicht vermeiden lassen, etwas zu ändern, da mein 5.2 Port hier fehlerhaft war. Ich stelle also dort die Kompatibilität zur DEC 5.1 wieder her und führe ein neues Schema parallel dazu ein.

Der ältere 5.2 Port war ja auch schon von mir.

Zu x64: Deine Einschätzung teile ich in vielen Punkten. Gerade Multithreading ist ein großer Nachteil in Delphi - ohne externe C Libraries kommt man häufig nicht auf die gewünschte Geschwindigkeit. Als Intel Technology Partner weiß ich, dass Delphi Kompilate hier in der Regel gnadenlos versagen (z.B. im SAT Concurrency Checker) und Ergebnisse liefern, die in der Nähe von VB 6 und RealBasic sind.

Aber das ist auch alles lösbar, wie gesagt z.B. mit geeigneten Referenzbibliotheken aus c.

Meine Entwicklungs-VM für die DEC läuft nun wieder, ihr habt mich nun etwas motiviert Vielleicht packe ich auch auf die Google Code Seite einen PayPal Button. Ich weiß nicht, ob sich sowas in der Delphi Szene lohnen würde. Helfen auf jeden Fall, dann kann ich auch mal Tage der DEC widmen, an denen ich sonst anderweitig Geld verdienen müsste.

Jetzt zur Daily Info:

Ich fange jetzt ganz unten neu an. TDD, also Unit Tests für die neue DEC Utils. PurePascal Port für die Bit/Byte Swaps und XOR.

Ich konnte heute bei SwapBits() die Geschwindigkeit um den Faktor 35 verbessern, obwohl in PurePascal und nicht ASM. Dadurch läuft dieser Teil schonmal auf x32 und x64. Referenz war die heute übliche, bekannte Info von Bit Twiddling Hacks, in diesem Fall eine Lookup-Table.

Mein (unverbindliches) persönliches Ziel wäre PurePascal mit ASM wo nötig und möglich, jeweils für x32 und x64, für Delphi und C++ Builder ab Version 7/2007 bis XE2 sowie FPC/Lazerus (in FPC ohne CryptoLib und Unittests, da ich Delphi nutze).

Nun denn, schauen wir mal, wie weit ich dieses mal komme

Viele Grüße
Assertor

[Codehunter]

Die Diskussion mit dem Multithreading hatte ich anderweitig auch schon mal. Native API-Programmierung ging wohl so halbwegs was Performance betrifft, die VCL-Klassen-Implementierung (TThread) stinkt wohl gnadenlos ab.

Vielleicht sollten sich die Leute die seinerzeit Bibliotheken wie z.B. FastMM4, DEC, Indy, Graphics32, VirtualTree etc. gebaut haben, mal zusammensetzen und schauen ob man eine gute performante Multithreading-Klassenbibliothek gebaut bekommen, die für die "einfacher gestrickten" Entwickler (zu denen ich mich auch zähle) auch bedienbar bleibt. MT ist an sich schon ein schwieriges Thema. Synchronisierung, Variablenlokalisierung etc. Da bekommt man anfangs schon Hirnverwurschtelung Die Entwicklung bei den Prozessoren in den letzten Jahren ging jedenfalls in diese Richtung und Delphi hats - simpel gesprochen - verschlafen.

Ich halte mich jedenfalls nicht für ausreichend qualifiziert, solche Basisbibliotheken oder eben auch DEC zu entwickeln, deshalb halte ich mich mit Forderungen auch sehr zurück. Was ich aber sehe ist dass Embarcadero Delphi in eine Richtung versucht zu entwickeln, für die es nicht gut geeignet ist, dabei häufig Richtungswechsel vollzieht und die Pflege der Basisbibliotheken ein wenig vernachlässigt. Inzwischen haben wir ein gefühltes Dutzend mitgelieferter, zueinander inkompatibler Frameworks.

So, Schluss mit dem kleinen Offtopic

[Zacherl]

Lebt das Projekt noch? Habe jetzt mal kurz das DEC 5.2 auf XE4 angetestet und bekomme jede Menge Compilerwarnungen. Wollte nur wissen, ob es sich lohnt das mal alles zu fixen, oder ob man in nächster Zeit mit DEC 6 rechnen kann.