Freepascal - v3.1.1 im Trunk

[Patito]

Zitat von JamesTKirk:

Bei uns weiß man eben nicht wirklich was als nächstes kommt. Da kommt es immer darauf an, woran jemand gerade Lust hat rumzubasteln (Beispiel: mein lauffähig machen des m68k Backends vor zwei Jahren).

Also zumindest unter den Kernentwicklern herrscht Einigkeit, dass die Funktionalität gut ist. Die Syntax jedoch... (und ja, ich bin auch kein Fan der Syntax, aber das trifft bei vielen der post-Delphi-2009 Features zu... )

Das ist so eines der Hauptprobleme von Pascal zur Zeit.
Pascal lebt eigentlich davon, dass es eine klare und einfach verständliche Syntax hat (oder hatte).
(es hatte sogar mal einen einfach verständlichen String-Typ...)

Es wäre in den letzten Jahren wesentlich besser gewesen, wenn die Compiler-Entwickler bei Delphi
den Ball flacher gehalten hätten. Für sinnvolle Änderungen an der Syntax mangelt es dort einfach ein wenig an Verantwortungsbewusstsein und Kompetenz.

Das dann alles als Fingerübung in Free Pascal zu integrieren ist zwar sicher spannend, aber
letztenendes für Pascal schlecht.

Wenn man immer mehr Syntax draufpackt und in wichtige Libraries integriert fliegt
in ein paar Jahren einfach alles auseinander und neue Compiler haben dann auch keine
echte Chance sich in eine kompatible Richtung zu entwickeln.

[DualCoreCpu]

Kann ich bestätigen mit der mangelnden Kompatibilität.

Muss in FPC 3.0.0 feststellen, dass ich die Allegro 4.4.5 nicht übersetzen kann weil Fehlermeldung

constructorname must be init!!!!

Bei Klassen. Warum Zum Teufen muss der Konstruktoname unbedingt INIT sein. Könnt Ihr Entwickler das nicht frei stellen???

Habe schon in fpc.cfg geguckt.

#-Ss

Sollte somit dort ausgeschaltet sein. Oder hat das '#' Zeichen eine andere Bedeutung.

Bin grad echt frustriert.

Werder Lazarus somit noch sehr lange in Version 1.2.6 mit FPC 2.6.4 verwenden. Lazarus dieser Version findet die ALlegro Units nicht obwohl ich den Quellfad korrekt in

PROJEKTOPTIONEN->PFADE->ANDERE QUELLCODEDATEIEN

angegeben habe.

Habe dann die Textmode IDE verwendet, die bringt die Fehlermeldung mit dem resrtriktiven Kontruktornamen.

Hier habe ich die Allegro her geholt und will auch genau diese verwenden. Wenn ich nämlich das hier in diesem Thread lese erhöht das die Motivation, doch die nächsthöhere Version zu verwenden in keinster Weise!

Waum nicht einfach eine FPC Version die zu allererst alle alten Bibliotheken klaglos übersetzt?

Von den ach so tollen Neuerungen habe ich so absolut gar nix, ich will erst mal irgendeine library auch übersetzen können, ohne Frickelei. Sollte bei OpenSource nicht zu viel verlangt sein. Unter GPL darf ich laut Lizenz eine Bibliothek unter dieser Lizenz zu JEDEM BELIEBIGEN Zweck verwenden. Also auch übersetzen, um dann damit eigene Software auf Basis dieser Bibliothek zu schreiben.

http://allegro-pas.sourceforge.net/downloads.php

Ist allegro 4.4.5, die Pascal Version! Die C/C++ Versionen gibt es nur im Quelltext und bei der Frickelei alleine schon auf der Pascal Seite will ich mir den C/C++ Teil gar nicht erst antun! Schließlich gibt es in meinem Paket eine alleg44.dll, die mir unbedarften User suggeriert, diese Dll enthalte den Binärcode der Allegro.

[DualCoreCpu]

Zitat von JamesTKirk:

*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.

Zitat von JamesTKirk:

Zitat von Stevie:

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]

Zitat von Stevie:

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.

Zitat von JamesTKirk:

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.

Zitat von JamesTKirk:

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.

[warschonweg]

[QUOTE=Sherlock;1286082]

Zitat von bernhard_LA:

TIOBE ist...vorsichtig ausgedrückt...ganz großer Bullshit.

Zumindest ist die Ermittlung der Werte unprofessionell. Aber gibt es denn einen besseren Index?