*seufz*
@Insider2004: 3.1.1 ist einfach nur die neue Versionsnummer von Trunk, sprich was zuvor 2.7.1 war.
Ziemlich verwirrend, wo gerade erst Version 3.0.0.0 raus ist und der Versionswechsel von 2 auf 3 schon erfolgt ist.
Dies wurde nötig, nachdem nun 3.0.0 gebrancht wurde (Branchname
fixes_3_0), welcher in den nächsten Wochen für das Release vorbereitet wird. So gesehen gibt es noch nichts neues, außer dass man nun gezielter mit den Snapshots von 3.0.0 testen kann, ob der eigene Code damit funktioniert.[/quote]
Sehr gute Idee, immer erst mal übersetzen und testen ob der Compiler durchläuft und dann gleich vernünftige Default Einstellungen in die fpc.cfg.
Gibt's wenigstens ne Roadmap oder wird nach wie vor "was zum Release drin is, is drin, was nich, nich" Strategie gefahren?
Was willst du bei einem Projekt, bei dem zwei, drei handvoll Freiwillige in ihrer Freizeit dran arbeiten auch anders machen?
Eben dann doch erst mal für Benutzbarkeit sorgen. Instabilitäten beseitigen, Inkomopatibilitäten beseitigen, ....
Auch andere Benutzer dieser Programmierumgebung progerammieren in der Freizeit und das OHNE Community, man sitzt dann im stillen Kämmerlein und steht im Regen wenn die Übersetzung abbricht ode runter Go32 plötzlich trotz Gigabytes von installiertem Speicher nicht genug Umgebunsgsspeicher zum Kompilierne da ist und dann die Frickelei mit der Speichereinrichtung los geht. So funktioneiert plattformübergreifende Programmierung NICHT.
Warum überhaupt noch die alten DOS Kamellen. Wennschon dann bitte mit Grafik, am besten mit anständiger
GUI Bibliothek obendrauf, mit modernem Fensterstil (Gnome, KDE, AuraGUI,...) und ohne Probleme übersetzbar.
Gut ist dass OpenPTC jetzt auch mit Go32 funktioniert und zur Distribution gehört. Die Demos lassen sich übersetzen und laufen dann auch. Ein dickes Lob dafür!
So sollte das mit allen Bibliotheken, auch mit Fremdbibliotheken laufen, tut es aber nicht.
Und wenn Go32 weg, dann auch alle alten Versionen. Ein PC Freund von mir programmiert noch unter DOS und zwar Spiele unter FreeDOS, die dort mitgelieferte AURA
GUI sieht echt gut aus und baut auf Allegro auf. In C/C++ gibt es da echt klasse
GUI-s. Warum nicht auch in Pascal???
Ich würde ja die Portierung machen, aber bei solchem Gefrickel alleine mit der Übersetzung der Pascal Version der Allegro habe ich keinen Bock dazu.
Das mindeste ist, dass ich die Pascal Version der Allegro übersetzen kann. Warum wird da die DOS Version nicht mehr mit verteilt, ein PC Freund in meinem Wohngebiet hat noch die letzte DOS Version der allegro, und mir den Binärcode der liballeg.a überlassen. Wenn die Übersetzung der Pascalunits statt gegen die alleg44.dll mit der liballeg.a für DOS gelingen würde, wär die allegro auch für GO32 verfügbar. Warum wird das unterbunden, indem die DOS Version nicht mehr bereitgestellt wird, aber DOS nicht aus dem Internet enfernt. Dann wäre das mit der UNterbindung nachvollzihbar und die DOS Progger nehmen dann eben nur das was damals an Software auch schon da war. Aber wenn DOS schon immer nocjh gepflegt wird, dann bitte auch mit Grafik und
GUI Oberfläche, da könnte man EINE funktionierende library hernehmen und die LCL darauf aufsetzen und hätte eine
GUI, die in Lazarus wie gewohnt verwendert werden könnte, AUCH für GO32, wenn DOS schon noch so präsent gehalten wird un d sogar weiter entwickelt wird mit Freedos. Die DOS Fans tauschen sich doch so oder so miteinander aus. AUf der einen Seite wird mit FreeDOS dieses in die Jahre gekommen System neu aufgelegt, auf der anderen Seite vwird man aber im Regen stehen gealssen, wenn man mal was damit machen will. Und in Windows klappt die Allegro Übersetzung aber auch nicht.
Anderereseits verwenden auch die fanatischsten DOS User für
GUI AUfgaben eine Windows Version, dann halt
Win9x. Aber in C/C++ gibt es einige wirklich gute DOS GUIs, die sogar auch unter Windows und Linux laufen. Vielleicht könnte eine dieser GUIs sogar die plattformübergreifende Programmierung vereinfachen, habe im Lazarusforum eine Frage zu Richedit gelesen zu ShellAPI, was ja nun total Windws spezifisch ist. Aber ich bin sicher, dass es in solchen alternativen Guis auch da eine Lösung gibt, die auch den Richedit und dessen Funktionalität abdeckt. Dann einfach so eine
GUI nach Pascal portieren.
Wie gesagt, ich würde die Portierung einer solchen
GUI machen, aber nicht im stillen Kämerlein alleine nur auf die Hilfsbereitschaft der Internetforen angewisesn. Eher höre ich mit Progrmmieren ganz auf, dann können mir solche Unzulänglichkeiten auch ganz und gar egal sein, dann interessiert mich die Programmierphilosophie nicht mehr.
Bissl Mithilfe wäre da ganz nett. Einmal die Woche miteinander kommunizieren um solche Fragen klären zu können. Aber nicht bloß Google und Foren!
[QUOTE=JamesTKirk;1285988]
Und vor lauter Diskussionen ob nen Language feature so oder so oder doch anders auszusehen hat, oder ob mans denn dann überhaupt braucht (anonyme Methoden, hust) kommense gar nicht nich zu Potte
Dann lieber weglassen, die Einarbeitung in jegliche Neuerungen ist auch nicht zu vernachlässigen, ich bin so drauf, dass ich dann lieber auf die Neuerung verzichte, wenn sie im Kompiler verfügbar ist, dann doch nict einsetze, wenn die Einarbeitung zu lange dauert.
Und wenn es ein Feature ist, das aus Delphi bekannt ist, sehe ich nur dann einen Sinn in der Übernahme des Features, wenn auch die Syntax der von Delphi entspricht. Sonst ist Umlerenen und beim Wechsel der
IDE ständig Umdenken nötig, was fehlerträchtig ist und Frust bringt, wenn man mal wieder die Syntax verwechselt hat.
Ich programmiere ganz genau so NUR in meiner Freizeit. Und bin auf die Internetforen angewiesen, wenn es irgendwo hakt. Nix da mit Community, in der man sich auch mal persönlich trifft, in der man sich auch mal alte bereits funktionierende sehr alte Bibliotheken austauscht. Muss ja nicht immer das brandneueste sein, Funktionieren muss das Zeug, auch wenn es nicht auf dem Stand von genau heute ist. Übersetzbar muss es sein, und das OHNE frustrierendes Gefrickel und Spezialeinstellungen, die man erst nach 5 Tagen Doku studieren und von Anfang bis Ende konzentriert durcharbeiten überhaupt erst findet. Is a bissl viel Zeitaufwand wegen einer Compilereinstellung mit EINEM Schalter! Vor allem dann wenn man in seiner Freizeit OHNE GELDEINNAHMEN programmiert.
Und eine Datenbank unter Windows muss zuerst funktionieren, da ist mir das ALter des
DB Serverrs komplett egal. Die Einrichtung desselben muss klappen und ggf. auf einen anderen Rechner portierbar sein. Wenn das klappt, kann der
DB Server von mir aus 40 oder 50 Jahre alt sein. Funktionieren musser halt.
Features, die von Delphi unterstützt werden, kommen auch früher oder später in FPC. Bei manchen dauert's eben länger, da sie umfangreicher sind (Dynamic Packages, anonyme Funktionen, Attribute).
Dynamic Pacages wäre was wirklich sinnvolles. Generics habe ich noch nie gebraucht. Pointer Arithmetik macht die Quellcodes inkompatibel zu Delphi. Anonyme Funktionen habe ich noch nie verwendet. Weiß gar nicht wo die vorteilhaft sind.
Das große Problem bei anonymen Funktionen ist, dass es bisher zwei (externe) Leute gegeben hat, die gesagt haben, dass sie dran arbeiten und bisher kam noch nichts dabei raus... (irgendwann werd's wahrscheinlich ich selbst machen müssen
) Dazu kommt noch, dass die meisten Mitentwickler mit der Syntax auf absoluten Kriegsfuß stehen.
Gruß,
Sven
Die Syntax ist noch eine Sache, die unterscheidet sich teilweise erheblich von der in Delphi, was die Portierung zwischen Delphi und Lazarus zum Frusterlebenis macht.
Damit kann ich aber leben, die Freepascal Syntax ist halt anders und nicht zu Delphi kompatibel. Schöner wäre eine 100% Kompatibilität im Mode Delphi natürlich schon, aber den Glauben an eine zeitsparende Portierbarkeit habe ich da länst begraben. Funktioniert nicht oder nur mit sehr großem Zeitaufwand.
Und wie gesagt, was Anonyme Funktionen sind und wozu die gut sein sollen, erschließt sich mir nicht, ich brauche einen Compiler, der meine UNits übersetzt, damit ich sie verwenden kann und zwar mit ALLEN Betriebssystemen, die der FPC Compiler unterstützt und für welche die Softwarebibliothek geschrieben wurde oder in früheren Zeiten mal verfügbar war.
Hier für mich zuerst mal Windows und gelegnetlich DOS. Die ALlegro gibt es da nur für DJGPP (GO32V2). Wenn schon DOS von FPC noch unterstützt wird, dann ist die Neuerung, dass auch 16 Bit Code übersetzbar sein soll, unbedingt zu begrüßen, denn zu Turbo Pascal Zeiten gab es recht gute Grafikbibliotheken, auch
GUI, die ja durch die Neuerung dann mit Freepascal wieder übersetzbar und nutzbar werden, womit einer meiner Kritikpunkte bezüglich Pascal
GUI entschärft werden könnten, denn letzlich ist es ja egal, wie breit die Register sind, die unter der
GUI die Daten speichern und verarbeiten. AUf jeden Fall wird mit der 16 Bit Unterstützung der Compiler wieder ein Stück Kompatibler. Hoffe ich zumindest, habe das noch nicht getestet.