PureBasic 4.20 Beta - All OS

[al90]

Und ich hab mich schon immer gewundert warum ich während des codens derart schwitze.

Nein im ernst, muss ich mir gleich mal anschauen.
Danke auch von mir an das PB-Team.

[al90]

Hier noch ne umsetzung des FC übersetzers. Da sie etwas anders als Falo's
übersetzung ausfällt, kann man sie nun beide kombinieren um etwas mehr aus
dem ganzen zu verstehen.

Hier ist die fünfte Betafreigabe der bevorstehenden 4,20 Version von PureBasic. Es wird länger, wie erwartet, und wir möchten einige Zeit verbringen, warum zu erklären. Schnellen Sie nicht aus, es wird wahrscheinlich das letzte Beta sein, wenn alles gut geht. Hier ist die Geschichte:

Zuerst wurde 4,20 dazu bestimmt zu sein ein und nur Befehl EW ' freigeben. Also wurden keine großen Probleme vorausgesehen, wie wir nicht am Compiler oder Debugger arbeiten. Besser wurden die meisten neuen Bibliotheken schon geschrieben, wie wir oft zusätzliche interresting Arbeit machen, wenn wir Fehler in Ordnung bringen, wird zu langweilig (wir beziehen die neue Bibliothek nicht in den Freigabebaum ein, so die Bibliothek kann maturate pacefully). So gut, dass so weit 2 Monate nach der 4,10 Freigabe ein neues Beta die Erde schlug. Und jetzt wurden Dinge ein bisschen komplexer.

Wir stoßen wieder ein LccWin32 weist Fehler auf/Beschränkung so wir entschieden, dass es Zeit war, in VisualC ++ 2005 umzustellen. Diese Auswahl wurde für serveral zu Gründen gemacht:

1) es ist der 'offizielle' C/C++ Compiler auf Windows
2) es ist frei (wir verwenden die ausgezeichnete 'ausdrückliche' Auflage)
3) es produzieren sehr guten Code (viel besser als lcc - manche, in denen libs 50-100 % gewann, sausen gerade und tauschen den Compiler)
4) es hat eine X64 Version auch, so dass wir trinken einen direkten Anschluss zu 64 Bits Fenster ohne zu viel Theater (wenigstens für die Bibliotheken)
5) aufweisen Fehler frei (wenigstens auf der Compilerseite)

So dass wir begannen so mit Migration all der Bibliotheken und Compilerbibliotheken (SystemBase, StringManager, usw..) Einige von ihnen verwendeten lcc Inline-ASM, so brauchten eine ziemliche Arbeit, um sie zur Arbeit zu haben. VC ++ ist auch pingeliger und Tonnen von Achtung erscheint und brauchte eine Korrektur. Außerdem aktivierten wir die 64 Bits Übertragbarkeitsprüfung und unsere Konsole wurden bestimmt überflutet. Denken Sie, als, wenn wir die ganze commandset, es Auswirkung tousand von Dateien alle umstellen, die das makefiles braucht, um usw. bearbeitet zu werden, außer, wie Sie können, zu verstehen, es für die Besten ist. Wir brachten mehrere Wochen später alles dazu, gut aufzubauen, und, da Sie es rieten, waren die 64 kompilierenden Bits (fast), auch arbeitend. Es war die Basis, die Arbeit für den berühmten X64 Compiler zu beginnen.

Wir, obwohl wir, waren mit diesem fertig, aber eine fremde VC8 Optimierung beeinflusste die Art, wie PureBasic Zeichenfolgenfunktionen aufrief, (PureBasic nahm an, als die auf dem Stapel für die Funktionen übermittelten Argumente nie von einer Funktion C modifiziert würden (und es der Fall mit lcc und gcc ist). Aber es keine klaren Informationen über dieses gibt, und VC8 verwenden die Stapelparameter tatsächlich als Aushilfssekretärinnenbereich, wenn erforderlich). So wurde eine Compileränderung gebraucht, um das in Ordnung zu bringen, nach vielen investiigation (wir bekamen wahlfreie Systemabstürze auf einigen Funktionen).

Ein zwischen, wir sahen uns mit einigen Regressionen konfrontiert, so dass wir viel mehr einheitliche Tests geschrieben haben, um das commandset zu Änderungen robuster zu machen. Diese laufen mit Hilfe des 'PureUnit' von Timo (Fr34k) entwickelten Hilfsprogramms, das wird, bald zu seinem Weg im offiziellen PB Paket gemacht, da es wirklich eine große Hilfe ist, sicherzustellen, dass sich ein Modul verhält, wie auf jedem plateform erwartet.

Nun, da all die Bibliotheken und Hilfeprogramme mit VC8 kompiliert wurden, konnten wir den Compiler selbst nicht mit Hilfe von Lcc lassen. Also begannen wir mit der Migration auch. Die Gewinne für das kompilieren Zeit war gut (10-30%ig), aber wir mussten ein bisschen hereinlegen VC8, um eine alte VC Laufzeit dll (MSVCRT.dll) statt die neuen VC8 eins zu verwenden, da ihm die Box nicht ausgehen würde, ohne die VC8 Laufzeiten auszuliefern. Google half hier.

Auf einem anderen Thema färbt CVS und ersetzte überall durch SVN. Wir stellten das libs Repository vor einiger Zeit um, aber der Compiler und interne Hilfsprogramme verwendeten immer noch dieses alte alte CVS. Die Migration war nicht sehr glatt, da das CVS Repository auf einem NT war, basierter Computer, während das Script die Migration machen musste, war auf Linux. Nach einigen Drehungen funktionierte es schließlich. So SVN überall. Und es ist Weg besser ehrlich.

Timo wollte dem IDE einen Porträtierer hinzufügen, so dass er es tat. Und er machte es gut. So es remainded ich, als ich es nicht tat, porträtierte den Compiler, da eine Weile und es ziemlich lustig sein konnten, zu tun. Ich versuchte, einen guten Porträtierer auf Windows (irgendjemandem) zu finden, aber nur die Kostspieligen zu gründen, quantifizieren (und die Demoversion zeigte sogar nur API-Aufruf mit VC8 ablauffähig, dunno wenn es auf Absicht ist oder wenn es ein Fehler ist). So dass ich es schoss meine Linux Box und mein gebrauchtes gprof und der Linux Compiler. Ich verwendete den IDE Quellencode als Vergleichspunkt (60 000 Zeilen.) Und hier, die Katastrophe: 23 millions stricmp Aufruf, der beim Suchen eines Tokens (wie Konstante, Struktur, Prozedur, Funktionen, Makrousw.) aufgerufen wird. Scheint, wie meine alten Suchtabellen hier leiden. Sicher die Bewohner haben fast 8000 Konstanten, und die Suchtabelle war Weg zu klein. Ich beschloss, das mit wirklicher Hashübersicht zu ändern. Der Gewinn war beeindruckend, jetzt sind nur 500 000 Aufrufe zu stricmp gemacht. Die ganze Verarbeitungszeit des Quellencodefalls von 3500 ms zu 500 ms auf meinem Computer herunter. Diese Optimierung ist verfügbar im Beta 5, so wenn Sie ein großes Projekt haben, Sie können den Differenzoperator fühlen.

Wir wollten die meisten wichtigen übrigen Fehler auch seit der letzten 4,10 Version (und sogar zuvor) angehen, so dass wir verbringen einige ziemliche Zeit, auf diese Art (auf den 3 OSes) festzumachen. Dies führte mich dazu, das 'QuadUnit' zu überarbeiten, welches wird verwendet, um basierten Innenhof zu manipulieren und auszuführen, Betrieb. Die für PB 4,00 entwickelte war gut, aber Weg zu komplex, und ein Fall war wirklich schwer zu bearbeiten. So dass ich das ganze Design vereinfachte und wieder codierte einzeln gibt Teil ein. Diese Änderung ist auch in Beta 5, so zögert nicht, Fehler aufzulisten, wenn vorhanden. Wenigstens werden Fehler alle, von denen der Innenhof berichtete, jetzt in Ordnung gebracht. Es sollte Nein haben oder sehr wenig Regression, wie alle fixierten Fehler sind, Teil der Compilereinheit testet (jed in Ordnung gebrachte Compilerfehler bekommen einen neuen Eintrag in der Regressionstestsuite).

In der Tat fügten wir hinzu, dass zu viel für einen Alleinstehenden Version, aber hey befiehlt, wir sind Größenwahnsinnige. Auf diese Art wir bekommenes plently macht fehlerhaft Berichte über diese (logisch da diese neuen Bibliotheken nicht trivials waren). Dank an Sie an alle für die Berichte und die Geduld.

Wie wir nicht aufhören können, wenn wir an einigen frischen Materialien arbeiten müssen, begannen wir mit den 64 Bits Version von PureBasic und die MacOS X x86 Version. Man konnte denken, als die MacOS X x86 Version nur eine Angelegenheit wäre, ein Kompilieren, aber Sie konnten nicht so falsch haben. OS X x86 ABI ist einfach fürchterlich und muss eigentliches strick alignement überall in den Puffer stellen (auf 16 Byte Grenzen) welchem die Windows/Linux Version tut nicht requiers. Wenn der Stapel falsch ausgerichtet ist, es manchmal arbeitet, manchmal nicht, sehr schwer führen, um Fehler zu verfolgen. So ist der Compiler überarbeitet worden, um Stapelausrichtung alles über dem Code zu bearbeiten. Außerdem ist FASM nicht auf OS X x86 verfügbar, so dass wir beschlossen, all die Baugruppenbibliotheken (verbundene Liste, misc usw.) auf NASM umzustellen. Wirklich ist der Compiler modifiziert worden, um NASM kompatiblen Code statt FASM auszugeben. Auf die x64 Seite, die Arbeit ist noch härter gewesen, da die Baugruppe selbst nicht das Gleiche ist. Nun, sind beide, ziemlich gut zu kommen, und der öffentliche Test kommen bald.

Die Letzten, aber nicht die wenigsten, vielsten neuesten Befehle bedeutet viel Dokument zu schreiben. Dies braucht viel Zeit, wie wir es in 3 Sprachen tun, wie Sie wissen. Das Beta 5 kommt mit dem Dokument in 3 langages für alle neuen Befehle.

Genehmigt, so dass Sie das Beta 5 auf Ihrem Konto ergreifen und es testen können. Das Beta für Linux und OS X sind bereit auch, aber wir warten ein bisschen, bevor wir sie veröffentlichen, (zu sehen, ob es keine größeren Marotten gibt. Und btw überprüfen, wenn Sie das Beta 4 verwendeten, Ihr 'Aushilfssekretärin' Verzeichnis, wie ein böser Fehler nicht die ganze PB Aushilfssekretärin entfernte, die dirs und es einer Stelle nehmen konnten.

[Kurzer]

Wow, eine neue Beta. Klasse. Auch das Statement von Fred war sehr interessant.

Schade, daß ich wegen privatem GAU derzeit nicht zum coden komme.

Was mir aber nach der Installation bzgl. Helpfile aufgefallen ist: Das Beispiel SerialPort.pb ist in der Hilfe nicht aufrufbar: "Die Seite kann nicht angezeigt werden". Evtl. wurde vergessen die Datei in die chm zu compilieren oder Pfad ist falsch? Zumindest ist die Datei unter den Examples zu finden, was ja erstmal reicht.

Gruß Kurzer

[NicTheQuick]

Hab mal ein bisschen von Hand übersetzt. Für die roten Teile war ich aber
grad zu faul.

Hallo,
Hier ist das fünfte Beta Release der bevorstehenden 4.20-er Version von PureBasic. Es hat länger gedauert als erwartet, und wir würden uns gerne ein bisschen Zeit nehmen den Grund dafür zu erklären. Nicht ausflippen, es wird wohl die letzte Beta sein, wenn alles gut läuft. Hier ist die Geschichte:

Zunächst war 4.20 dazu gedacht ein reines "nur neue Befehle"-Release zu werden. Also wurden keine großen Probleme vorhergesehen, zumal wir nicht am Compiler oder Debugger arbeiten wollten. Besser die neuen Bibliotheken sind bereits geschrieben als dass wir extra interessante Arbeit beim Bugs finden tun, die langweilig wird (Wir bauen die neue Bibliothek nicht ins Release ein, damit sie sicher 'reifen' kann). So weit, so gut, zwei Monate nach dem 4.10 Release, hat eine neue Beta das Licht der Welt erblickt. Und nun werden die Dinge ein bisschen komplexer.

Wir begegneten wieder einem LccWin32 Fehler und Limitierungen, also haben wir entschieden, dass es Zeit ist zu VisualC++ 2005 zu migrieren. Diese Wahl wurde aus verschiedenen Gründen getroffen:

1) Es ist der 'ofizielle' C/C++ Compiler unter Windows
2) Es ist konstenlos (wir nutzen die exzellente 'Express' Edition)
3) Es produziert sehr guten Code (viel besser als lcc - einige Libraries gewannen 50-100% Geschwindigkeit nur durch die Umstellung des Compilers)
4) Es hat auch eine X64 Version, womit wir ohne viel Ärgern einen direkten Port zu 64 Bit Windows haben (zumindest für die Libraries)
5) Fehler frei (bug free) (zumindest auf der Compiler Seite)

Also haben wir eine Umstellung aller Bibliotheken und Compilerbibliotheken (SystemBase, StringManager, etc.) durchgeführt. Einige von ihnen nutzten lcc inline ASM, wodurch es recht viel zu tun gab, damit alles lief. VC++ ist auch wählerischer und Tonnen von Warnmeldungen brauchten eine Korrektion. Überdies aktivierten wir den 64 Bit Portabilität Check und unsere Konsole wurde endgültig geflutet. Denk dran, wenn wir das ganze Befehlsset ändern, betrifft das tausende Dateien, alle Makefiles müssen angepasst werden, usw. Aber wie du weißt, ist es für das Beste. Einige Wochen später haben wir alles richtig gebaut und wie du schon ahnst läuft 64 Bit Compiling (meistens) gut. Es war die Grundlage für den Beginn der Arbeiten am berühmten X64 Compiler.

Wir dachten wir wären damit fertig, aber eine merkwürdige VC8 Optimierung beinflusste die Art wie PureBasic String-Funktionen aufrief (PureBasic setzte voraus, dass die Argumente auf dem Stack für die Funktionen niemals von einer C-Funktion geändert werden würden (und das ist der Fall mit lcc und gcc). Aber es gibt keine klaren Informationen dafür und VC8 nutzt die Stack-Parameter als temporären Bereich, falls erforderlich). Also war nach langen Nachforschungen eine Compiler-Modifizierung nötig um das zu beheben (wir bekamen zufällige Abstürze bei manchen Funktionen).

In der Zwischenzeit gingen wir einige Rückschritte an, also schrieben wir viel mehr einheitliche Tests um das Befehlssets robuster gegen Veränderungen zu machen. Diese laufen mittels dem 'PureUnit'-Tool von Timo (Fr34k), das seinen Weg bald in das offizielle PB-Paket nehmen wird, da es eine große Hilfe ist sicherzugehen, dass ein Modul sich wie erwartet verhält, auf jeder Plattform.

Jetzt, da alle Bibliotheken und Helfer mit VC8 kompiliert wurden, konnten wir den Compiler selbst nicht Lcc nutzen lassen. Also starteten wir die Umstellung ebenso. Der Nutzen für die Kompilierungszeit waqr gut (10-30%), aber wir mussten VC8 ein bisschen austricksen um eine alte VC Runtime DLL (MSVCRT.dll) anstatt der neuen nutzen zu können, da es sonst nicht hervorragend laufen würde ohne die VC8 Runtimes beizupacken. Google hilft da .

In einem anderen Thema ist CVS gestorben und überall durch SVN ersetzt worden. Wir stellten das Bibliothekenlager schon vor einiger Zeit um, aber der Compiler und die internen Tools nutzen immer noch das gealterte CVS. Die Umstellung verlief nicht sehr reibungslos, da das CVS Repository auf einem NT basierten Computer war während das Skript zum Umstellen auf Linux war. Nach ein paar Problemchen lief endlich alles. Also überall SVN. Und es ist besser, ehrlich.

Timo wollte einen Profiler zur IDE hinzufügen, also tat er es. Und er tat es gut. So it remainded me than i didn't profiled the compiler since a while and it could be quite fun to do. I tried to find a good profiler on Windows (anyone ?) but only found the costly Quantify (and even, the demo version showed only API call with VC8 executable, dunno if it's on purpose or if it's a bug). So i fired it my linux box and used gprof and the linux compiler. I used the IDE source code as benchmark (60 000 lines). And here, the disaster: 23 millions of stricmp() call - called when looking for a token (like constant, structure, procedure, functions, macro etc.). Seems like my old lookup tables are suffering here. For sure, the residents have almost 8000 constants and the lookup table was way too small. I decided to change that with real hash map. The gain was impressive, now only 500 000 calls to stricmp() are done. The whole processing time of the source code fall down from 3500 ms to 500 ms on my computer. This optimisation is available in the Beta 5, so if you have a big project, you may feel the difference.

We also wanted to tackle most of the important remaining bugs since the last 4.10 version (and even before), so we spend quite some time to fix thus (on the 3 OSes). This led me to rework the 'QuadUnit', which is used to manipulate and execute quad based operation. The one developped for PB 4.00 was good but way too complex and some case were really hard to handle. So i simplified the whole design and recoded several key part. This change is also in Beta 5, so don't hesitate to report bugs if any. At least, all the quad reported bugs are now fixed. It should have no or very few regression as all fixed bugs are part of the compiler unit tests (every compiler bugs fixed get a new entry in the regression test suite).

In der Tat fügten wir zu viele Befehle für eine einzelne Version hinzu, aber hey, wir sind größenwahnsinnig. Folglich bekamen wir reichlich Fehlerberichte auf diese (logischerweise, da die neuen Bibliotheken nicht trivial waren). Danke an euch alle für die Berichte und Geduld.


As we can't stop, when we need to work on some fresh stuffs, we started the 64 bits version of PureBasic and the MacOS X x86 version. One could think than the MacOS X x86 version would be just a matter a recompiling, but you couldn't be that wrong. OS X x86 ABI is just horrible and need very strick stack alignement everywhere (on 16 bytes boundaries) which the Windows/Linux version doesn't requiers. If the stack is misaligned, it sometimes work, sometimes not, leading to very hard to track bugs. So, the compiler has been reworked to handle stack alignment all over the code. Moreover, FASM is not available on OS X x86, so we decided to migrate all the assembly libraries (linked list, misc etc.) on NASM. Indeed the compiler has been modified to output NASM compatible code instead of FASM. On the x64 side, the work has been even harder as the assembly itself isn't the same. Well, both are coming quite nicely, and the public test will come soon.

Nicht zuletzt bedeuten viel neue Befehle viel zu schreibende Dokumentation. Das nimmt viel Zeit auf sich, da wir es in 3 Sprachen tun, wie du weißt. Die Beta 5 kommt mit der Dokumentation in 3 Sprachen, für alle neue Befehle.

Ok, du kannst dir die Beta 5 von deinem Account laden und testen. die Beta für Linux und OS X sind ebenso bereit, aber wir wollen ein bisschen warten bevor wir sie veröffentlichen (um zu sehen, dass es keine größeren Mucken gibt. Und nebenbei, wenn du die Beta 4 nutzt, schau in dein 'Temp' Verzeichnis, da ein gemeiner Bug nicht alle temporären PB-Verzeichnisse löscht und es Platz verbrauchen könnte)

Hab Spaß!

Das Fantaisie Software Team

[ts-soft]

New beta versions are availables for all OS.

http://www.purebasic.fr/english/viewtop ... 319#243319

[mardanny71]

Beta 6 bzw beta 2 für Linux .

Das ging ja jetzt schnell .
Weiter so.
Danke.

gruss
mardanny71

[rolaf]

Wie ich gerade festgestellt habe werden die EXEs mit der Beta 5 doch um einiges fetter. Ein knapp 800 Zeilen Code der vorher mit der 4.1 kompiliert 104 KB belegte wird mit der 4.2 Beta 5 auf 138 KB "aufgeblasen". Hmmmm 34 KB (oder 33%) mehr...

Edit:
Vergesst es, mit der Final werden die EXEs sogar kleiner.

[Andre]

das wohl wichtigste in diesem Board:
Deutsche Hilfe enthalten

Ja, ja - die hatte ich grade vor diesem Beta-Release fertig bekommen. Auch wenn ich recht wenig Zeit habe, mich hier auch als Autor im Forum zu betätigen, so lese ich doch regelmäßig mit.

Und an der PB-Hilfe arbeite ich natürlich auch. Die Hilfe für die "PB4.20" ist nun auch fertig - die "Final" kann also kommen....

[ts-soft]

- die "Final" kann also kommen....

[Andre]

der Countdown läuft....
(wieviel Stunden oder Minuten verrate ich aber nicht... )