FPC 2.4.2 ist da!

[marcov]

Hello,

we have placed a new major release of the Free Pascal
Compiler, version 2.4.2 on our ftp-servers.

Changes that may break backwards compatibility are documented at:
http://wiki.freepascal.org/User_Changes_2.4.2" onclick="window.open(this.href);return false;

Downloads are available at:

the main FTP server at

ftp://ftp.freepascal.org/pub/fpc/dist/2.4.2/" onclick="window.open(this.href);return false;

and mirrors like

ftp://freepascal.stack.nl/pub/fpc/dist/2.4.2/" onclick="window.open(this.href);return false;
ftp://ftp.hu.freepascal.org/pub/fpc/dist/2.4.2/" onclick="window.open(this.href);return false;

and sourceforge.

Enjoy!

The Free Pascal Compiler Team

Free Pascal Compiler

Version 2.4.2

******************************************************************************
What's New in 2.4.2
******************************************************************************

Free Pascal 2.4.2 contains many fixes and a few new features. Most bugfixes
in the RTL and packages before june 2010 have been merged.

Please also see http://wiki.freepascal.org/User_Changes_2.4.2" onclick="window.open(this.href);return false; for a list
of changes which may affect the behaviour of previously working code, and
how to cope with these changes.

Some highlights are:

Compiler:
* Support D2006+ FOR..IN, with some FPC specific enhancements. Refer to
http://wiki.freepascal.org/for-in_loop" onclick="window.open(this.href);return false; for more information
* Support for sealed and abstract classes.

Packages:
* Many improvements to the XML units
* Many improvements to the database units
* Many improvemnets to the chm units

Platforms:
* Long term bug in OS/2 implementation of unit Video finally fixed which
among others allows inclusion of the text-mode IDE (without debugger)
for this platform as part of the distribution again.

See http://bugs.freepascal.org/changelog_page.php" onclick="window.open(this.href);return false; for the list of reported
bugs which have been fixed in this release.

[Euklid]

Danke für Eure Arbeit!

Die neue for-in-Schleife klingt spannend...

[mschnell]

Die neue for-in-Schleife klingt spannend...

In der Englischen wurden dann natürlich sofort die Probleme bei for-in für UTF-8 codierte Strings diskutiert....

-Michael

[theo]

In der Englischen wurden dann natürlich sofort die Probleme bei for-in für UTF-8 codierte Strings diskutiert....

Mein alter UTF8Scanner macht was ähnliches.
Nur heisst es dort nicht "for..in" sondern:

Code: Alles auswählen

repeat 
 DoSth(s.Next);
until s.Done;

http://wiki.lazarus.freepascal.org/Theodp" onclick="window.open(this.href);return false;

[carli]

In der Englischen wurden dann natürlich sofort die Probleme bei for-in für UTF-8 codierte Strings diskutiert....

Mein alter UTF8Scanner macht was ähnliches.
Nur heisst es dort nicht "for..in" sondern:

Code: Alles auswählen

repeat 
 DoSth(s.Next);
until s.Done;

http://wiki.lazarus.freepascal.org/Theodp" onclick="window.open(this.href);return false;

for .. in ist auch nur eine Abkürzung o.g. Iterator-Patterns.
Man kann auch für for..in selber Iteratoren implementieren, wenn ich z.B. etwas für alle Primzahlen bis 100 haben will.

[Bora4d]

FPC 2.4.2 ? Ich benutze dank Lazarus-Snapshot seit Monaten 2.4.3 Das wäre ja Rückschritt
Anstatt nicht notwendige neue Delphi-Freatures nachzumachen hätten die besser die Zeit für Optimierung genutzt. Die exe-Größen unter Linux ist ja kaum ertragbar.
Einfache LCL-Anwendung ist min. 4 MB auch mit Strip!
Und fpgui-Anwendung 1 MB
Und jetzt kommts einfache GKT2 Anwendung ist 531 KB. Das gleiche GTK2-Programm ist unter Windows nur 148 KB groß.

[MAC]

Die exe-Größen unter Linux

kein Kommentar

[Socke]

Anstatt nicht notwendige neue Delphi-Freatures nachzumachen hätten die besser die Zeit für Optimierung genutzt. Die exe-Größen unter Linux ist ja kaum ertragbar.

Ich bin der Meinung, dass die Code-Größe durch den Free Pascal Compiler auf ein vollkommen annehmbares Maß reduziert werden kann! In der Regel muss der Lazarus(!)-Anwender nämlich seine (!) Einstellungen optimieren.

Einfache LCL-Anwendung ist min. 4 MB auch mit Strip!
Und fpgui-Anwendung 1 MB
Und jetzt kommts einfache GKT2 Anwendung ist 531 KB. Das gleiche GTK2-Programm ist unter Windows nur 148 KB groß.

Ein nicht ganz triviales Programm kann ich unter Linux/GTK2 auf 2.35 MiB zusammenkürzen. Strip kann nur Debuggingsymbole entfernen. Bei weniger Code gibts natürlich auch davon weniger, aber die größte Ursache dieser Symbole ist der Debugger und nicht der FPC oder Lazarus (FPC erstellt sie für den Debugger).
Ein wenig ausführlicher wird http://wiki.lazarus.freepascal.org/Size_Matters/de, welches du unbedingt gelesen haben solltest. 4 MB für eine triviale LCL-Anwendung (Form+Button) sprechen für unzureichende Optimierung der Compiler-Einstellungen und unzureichenden Gebrauch selbiger.

Edit:

Die exe-Größen unter Linux

kein Kommentar

Ich schätze, hier kommt WINE zum Einsatz

[Bora4d]

Die exe-Größen unter Linux

kein Kommentar

Executables > exe
Entschuldige, dass ich mich nicht klar ausgedrückt habe.

@Socke
Den Text habe ich vor Jahren gelesen. Aber damals hatte Smartlink nicht viel gebracht. Jetzt habe ich GTK2-Demo mit Smartlink (-XX) kompiliert und siehe von 531 Kb auf 73 Kb geschrumpft.
Ich kompiliere mal meine Programme noch mal mit Smartlink.

[Socke]

Den Text habe ich vor Jahren gelesen. Aber damals hatte Smartlink nicht viel gebracht. Jetzt habe ich GTK2-Demo mit Smartlink (-XX) kompiliert und siehe von 531 Kb auf 73 Kb geschrumpft.
Ich kompiliere mal meine Programme noch mal mit Smartlink.

Es reicht natürlich nicht aus, nur deine Units mit Smartlinking (-CX -> Erzeugung entsprechend linkbaren Codes) zu übersetzen und dann das Projekt ebenfalls mit Smartlinking (-CX -> Anwendung dessen) zu erstellen. Man muss alle verwendeten Units (RTL, FCL, LCL, Packages, eigene Units) so erstellen, damit der Effekt maximal zum Tragen kommt.

[Bora4d]

Socke
Bei LCL-Anwendungen ist es immer noch 4,5 MB. Ich kompiliere mal die Bibliotheken wie du es gesagt hast neu.
Ich denke die LCL ist zu ineffizient programmiert. Da ist viel zu viel unnötige Code enthalten.
Wenigstens direkte GKT2 und Win32 Anwendungen sind jetzt klein.

[marcov]

Socke
Bei LCL-Anwendungen ist es immer noch 4,5 MB. Ich kompiliere mal die Bibliotheken wie du es gesagt hast neu.

Da machst du etwas falsch. Lese noch einmal Size Matters (den ich original geschrieben habe), es enthalt große Magnituden, und 4.5 MB fuer ein einfache Anwendung ist zu viel. ich wurde 1MB erwarten.
Hast du ein RTL und LCL die mit smartlinking kompiliert ist?

Ich denke die LCL ist zu ineffizient programmiert. Da ist viel zu viel unnötige Code enthalten.

Man kann sich ueber "zu" streiten, das ist alles Relativ.

Wenigstens direkte GKT2 und Win32 Anwendungen sind jetzt klein.

Handcodieren ist immer kleiner, aber oft um mehr als denselben Faktor aufwendiger. Und nicht in erster Magnitude portabel.

Mit Terabyte Festplatten Speicher unter Euro 100 kann man etwas lockerer sein.

[Euklid]

Bei LCL-Anwendungen ist es immer noch 4,5 MB. Ich kompiliere mal die Bibliotheken wie du es gesagt hast neu.

Bora4d: Ich meine, ich hätte Dir in einem anderen Thread schonmal folgenden Link geschickt? http://www.lazarusforum.de//viewtopic.php?f=51&t=1878" onclick="window.open(this.href);return false;
Dabei handelt es sich um eine Anleitung, mit welchen Lazarus-Einstellungen die Größe der Binärdateien schrumpfen - auch ohne upx auf Werte um 1 MB.

- Euklid

[Bora4d]

Bei LCL-Anwendungen ist es immer noch 4,5 MB. Ich kompiliere mal die Bibliotheken wie du es gesagt hast neu.

Bora4d: Ich meine, ich hätte Dir in einem anderen Thread schonmal folgenden Link geschickt? http://www.lazarusforum.de//viewtopic.php?f=51&t=1878" onclick="window.open(this.href);return false;
Dabei handelt es sich um eine Anleitung, mit welchen Lazarus-Einstellungen die Größe der Binärdateien schrumpfen - auch ohne upx auf Werte um 1 MB.

- Euklid

Ich habe auch unter Windows Dateigröße von ca. 1,5 MB ohne UPX. Was ich meinte war Linux da habe ich immer 4 MB. Villeicht mache ich etwas falsch. Ich folge mal die Anleitung Schritt für Schritt.
Die Dateigröße von Lazarus ist nicht so schlimm. Ich habe mich am Freitag mit Qt-C++ Programmierung beschäftigt, da beanspruchen ganz einfache QT-Programme unter Windows Hauptspeicher von ca. 17 MB.
Und die einfachen leeren WxWidgets Programme haben Dateigröße von ca 2,5 MB.

[pluto]

a beanspruchen ganz einfache QT-Programme unter Windows Hauptspeicher von ca. 17 MB.

Siehst du, also noch schlimmer als Lazarus.