Übersetzung des Lazarus-Wiki

[schnullerbacke]

Schon richtig, hier im Forum sieht man ja auch am Alter einiger Mitglieder, daß das Wissen um PASCAL zwischen Einsteiger und Profi liegt. Gerade der Mix FPC/LAZARUS ist aber für Einsteiger naheliegend, eine professionelle Umgebung wie Delphi (TurboDelphi) kostet ab 400,- € aufwärts und kann schon deshalb nicht vorausgesetzt werden. Damit steht es aber gerade diesem Projekt gut an auch didaktisch tätig zu werden.

Das kann über Tutorien und Einführungen passieren, auf die in den jeweiligen Beiträgen für Profis zumindest verlinkt wird. Ein weiteres Problem sind ganz sicher die Unmengen von Abkürzungen auf die gerade in den Profibeiträgen Bezug genommen wird. Ich kenne davon bestimmt schon ne Menge und muß trotzdem gelegentlich noch googeln. Das ist lästig und läßt auch eine vernünftige Einarbeitung kaum zu. Da helfen Links zu brauchbaren Abhandlungen ganz erheblich weil man eben auch schnell in den Ausgangstext zurückkommt.

Im Übrigen halte ich auch nicht viel von der Einstellung:

"Ich mußte ja auch suchen, sollen die selber sehen wie sie klarkommen."

Turbo-PASCAL war nach dem Erscheinen deswegen so erfolgreich, weil es neben dem günstigen Preis eben auch über eine sehr gute Dokumentation verfügte. Gerade die Tatsache, das es gerade an guten Dokumentationen mehr und mehr mangelt sollte für das FPC/LAZARUS-Projekt Grund genug sein, auch und gerade in diesem Bereich tätig zu werden.

Schließlich ist FPC/LAZARUS von der Anlage her dazu geeignet fast jedes beliebige Projekt professionell zu erstellen. Dazu gehört aber auch eine professionelle Dokumentation sonst wird auch diese Entwicklungsumgebung wie viele andere vorher unter ferner liefen wieder in der Versenkung verschwinden. Das hat aber weder PASCAL noch das vorliegende Projekt verdient, schon deshalb nicht als es auf allen gängigen Plattformen zum Einsatz kommen kann und Cross-Entwicklung damit extrem fördert.

Das alles gibt es sonst nur bei sehr teueren Umgebungen wie z.B. Microfocus COBOL für das man immerhin ca. 10.000,- € je Lizenz hinlegen muß. Mit dem feinen Unterschied, das COBOL standardisiert ist und man damit eben auch auf eine breite Litheraturbasis zugreifen kann.

Da sollten wir aus diesem Forum wo möglich tätig werden. Durchaus denkbar, das dann einige Beiträge aus dem deutschen binnen kurzer Zeit als englische Übersetzung auftauchen. Wir leben ja nun in D-Land nicht unbedingt auf der Insel der "Informatik-Einäugigen", da können wir locker mit den anderen mithalten.

[Christian]

Schnullerbacke es geht hier um die erklärung des Begriffs Thread !
Die gehört einfach nicht in die Dokumentation der Programmiersprache
Das ist das selbe wie wenn im Handbuch deines Autos der Begriff Lenkrad erklärt wird...
Man muss und kann in einer Dokumentation nicht alles erklären dann wird sie so umfangreich das sehr schnell Teile entstehen die unwahrheiten enthalten da sie nicht schnell genug gewartet werden können ausserdem wird sie dann sehr schnell unübersichtlich.

[Euklid]

Christian, ich bin ganz deiner Meinung, wenn es um die Dokumentation für die Profis geht.

Wenn es um einführende Tutorials geht, bin ich der Meinung von schnullerbacke.

Wenn nun jemand mit dem FPC anfängt zu programmieren - wo ist deiner Meinung nach der Richtige Ort, solche Begriffe zu lernen?

Nach meiner Meinung sollte eine erste Einführung diese Begriffe fassen. Damit meine ich aber nicht die Übersetzung, sondern deren Bedeutung innerhalb der Programmierkultur. Aber das soll hier kein Streitpunkt sein. Wenn wir uns nicht einigen können, handhabt es jeder so, wie er es für richtig hält.

Viele Grüße, Euklid

[Christian]

Begriffserklärungen findet man z.b. in der Wikipedia Das hat nichts mit Profi oder Anfänger zu tun bin ich der Meinung. Mc Donalds muss auf Kaffeebecher drauf schreiben das der Inhalt heiss ist, das ist genau son Schwach fug wie in der Dokumentation einer Entwicklungsumgebung grundlegende Begriffe der Computerei zu erklären. Es gibt einfach Sachen ohne die man nicht unbedingt Programmieren muss wenn man eben nicht weiß was ein Thread ist kann man damit nicht Programmieren. Das ist wie wenn man sich ohne Schuhe die Schnürsenkel zubinden will.

[Euklid]

Ich finde z.B. dass Beschreibungen, wie hier gemacht

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

schon ausreichen. Man muss ja keine Romane schreiben.

[mschnell]

Ich finde z.B. dass Beschreibungen, wie hier gemacht

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

schon ausreichen. Man muss ja keine Romane schreiben.

Wie immer wird in da leider nicht beschrieben, dass Delphi (und damit auch FP/Lazarus) völlig unsymmetrisch mit Threads umgeht. Während der Mainthread Ereignis-orientiert programmiert werden muss (außer bei command-line-tools), ist das bei TThreads nicht möglich (sie haben keinen eigenen Event-Scheduler). Das macht das Verständnis von Multithreadded Programmierung schwierig. Ich hatte mir immer ereignisorientierte Programmierung für Threads gewünscht, aber das ist nicht so einfach zu realisieren. Vermutlich muss man dazu sogar den Sprach-Umfang erweitern (z.B. Properties ermöglichen, die neben einer Funktion (also Event) auch eine Definition für einen Thread zulässt mit Hilfe dessen Prozesses dieses Event ge"fired" werden soll.

-Michael

[schnullerbacke]

Wiki ist kein Allheilmittel. Früher haben wir mal aus Büchern (Handbüchern) gelernt, das kann ich jedem nur empfehlen, die werden jedenfalls noch von Lektoren quergelesen und enthalten schon deshalb weniger Fehler. Nun wurden und werden Bücher aber meistens mit EMACS erstellt und enthalten an den den entsprechenden Stellen Querverweise auf die Fundstellen (meistens im gleichen, manchmal in anderen Büchern). HTML ist kaum anders als EMACS, deshalb versteh ich nicht, weshalb sich immer wieder Leute finden denen offensichtlich schon der Hyperlink (z.B. auf das Thema Thread) zuviel ist.

Wer das lesen will weil er eben gerade daran Interesse hat kann ihn nutzen, wer nicht kann es lassen. So wird aber eine Doku für jeden benutzbar. Gerade weil man beim googeln nicht immer gleich auf die richtige Seite gerät sollte das in einer geschlossenen Doku so gehandhabt werden. Der Unterschied zwischen einem Buch und einem elektronischen Buch ist die Zugangsweise. Die Handhabung sollte möglichst die gleiche sein.

Das ist wie wenn man sich ohne Schuhe die Schnürsenkel zubinden will.

Aber die meisten Leute wissen wo sie die Schnürsenkel oder Schuhe herkriegen. Hyperlinks sind nichts anderes als die Angabe wo die "Schnürsenkel", oder eben die "Schuhe", zu finden sind.

[schnullerbacke]

@mschnell

So ein bißchen hätte ich da die Befürchtung, das dein Programm dann schnell im Nirwana landet. Du kannst ja eine Event-Bindung zwischen einem Objekt und einem Thread herstellen. Nur kann der Thread nur an genau ein Event in genau einem Objekt zur Zeit auslösen. Das hindert dich aber auch nicht, je nach eigetretenem Ereignis innerhalb des Threads, jeweils ein anderes Objekt anzusprechen. Ob du das dann sinnvollerweise mit einer Liste verwaltetest oder mit mehreren verschiedenen Events bleibt dir anheim gestellt. Nur die Synchronisation darf man halt nicht vergessen.

Ansonsten kann man ja auch noch Prozesse verwenden. Nur sind Semaphoren auch kaum leichter zu handhaben.

[mschnell]

Du kannst ja eine Event-Bindung zwischen einem Objekt und einem Thread herstellen. ...

Wie würdest Du z.B. vorgehen wenn ein Thread die Events von mehreren Timern (so etwas eie TTimer, aber für den Betrieb mit TThreads) verarbeiten soll ?

-Michael

[theo]

Wie würdest Du z.B. vorgehen wenn ein Thread die Events von mehreren Timern (so etwas eie TTimer, aber für den Betrieb mit TThreads) verarbeiten soll ?
-Michael

Kann nicht ganz folgen. Kannst Du mal erkären, wie du das genau meinst?
Ich denke ich kann innerhalb des Threads durchaus Ereignisse wie z.B Synapse's Sock.OnStatus verarbeiten.

Timer ist natürlich etwas speziell.
Am ehesten würde einem einfallen, in der Thread Execute Methode in einen "Main Loop" zu gehen und von dort aus die Timer-Ereignisse auszulösen.
Oder vielleicht verstehe ich dich auch falsch...

[schnullerbacke]

Ich glauben ich wissen wie meinen diese...

Aber mehrere Timer solltest du mal von vornherein nicht nehmen. Die Dinger belasten den Prozessor ziemlich kräftig und machen mehr Ärger als sie nutzen bringen. Eine Lösung sind da Signalslots a la Qt. Im Anhang ist ein Beispiel, wie man sowas lösen kann. Beide Units müssen beim Programmstart als erste gestartet werden, dann haste deine TimeSignals und kannst sie verteilen.

Ich mach mal nen Thread Signalslots auf und pack den Anhang da rein. Das dürfte für alle interessant sein.

[Christian]

Die Dinger belasten den Prozessor ziemlich kräftig und machen mehr Ärger als sie nutzen bringen.

hä ?
Die implementierung des Timer objekts ist sache des fpc teams und sehr betreibsystem spezifisch. Wo hattest du schon mal Probleme damit ? Und Prozessorlast durch nen Timer ? Quatsch die Lazarus implementierung verwirklicht das über Messages wenn du die Maus bewegst belastete das deinen Prozessor mindestens 100x soviel.

Windows 3x Zeiten sind vorbei wo es nur 16 System Timer gab und die TTimer implementierungen von Borland jewails einen benutzten.

[schnullerbacke]

Und eben weil ich bei Delphi Probleme damit hatte hab ich mir ne eigene Lösung einfallen lassen die zudem noch ein paar andere Vorteile hat.

[knight]

Euer Flehen ist erhört worden!
Das Wiki von FreePascal wird in das Lazarus Wiki integriert. Da es im FPC Wiki bislang noch keine deutschen Übersetzungen gegeben hat bedeutet das, daß es jetzt jede Menge noch zu übersetzende Seiten gibt (mehr als vorher jedenfalls).

knight

PS: Ich werde mich an den Übersetzungen natürlich auch beteiligen.

[mschnell]

Ich mach mal nen Thread Signalslots auf und pack den Anhang da rein. Das dürfte für alle interessant sein.[/quote]

Ich kann anscheinend in diesem Forum keine Anhänge laden

Signals gehen aber wohl nur in Linux. In FP sollten Lösungen aber Betriebssystem-unabhängig organisiert werden.

Übrigens: ein "Main-Loop" das irgendetwas pollt habe ich natürlich nicht im Sinn, weill CPU-Zeit verbraten wird.

-Michael