Einfache Freepascal IDE

[schöni]

Hallo!

Jetzt möchte ich Euch mal ein kleines Projekt vorstellen. Es handelt sich um eine sehr einfach gehaltene IDE für den Freepascal Compiler.

Zu diesem Projekt motiviert wurde ich einerseits durch den Umstand, das der Freepascal Compiler, von Lazarus abgesehen, noch immer mit der etwas angestaubten Turbo Vision IDE geliefert wird, obwohl es leistungsfähige Windowas Entwicklungsumgebungen gibt. Wenn das Freepascal Team von dem einige, wie ich den Eindruck gewonnen habe, auch hier in der DP angemeldet sind, bereit ist, diese IDE an Stelle der alten, mit FreeVision geschriebenen zu verteilen, werde ich den Debugger noch versuchen, nachzurüsten und ebenso die Codevervollständigung. In diesem Fall wird diese IDE OpenSource.

Andererseits fasziniert mich der Formulardesigner von Delphi. Weil es da zahlreiche Nachbauten gibt, die ich gerne nachvollziehen möchte und außerdem mir eine Lösung hirfür unter Nutzung von Quellcode aus der DP und aus dem sonstigen Internet zusammengestellt habe, brauche ich vollständigkeitshalber eine IDE, in die ich diesen Designer einbauen kann. In der vorliegenden Version der IDE ist jedoch kein Form-Designer eingebaut.

In dieser Version gibt es noch keinen intergrierten Debugger, obwohl die Menüeinträge dafür bereits vorhanden sind. Auch gibt es noch keine Codevervollständigung, obwohl auch hier die Menüeinträge dafür vorhanden sind. Werden die betreffenden Menüeinträge ausgewählt, passiert nichts, außer dem Schließen des Menüs.

Auch funktioniert der Aufruf des Konsolenfensters noch nicht im Menü "Datei->DOS aufrufen".
Die integrierte Hilfe, folgt, wenn die IDE fertig ist. Das ist der Fall, wenn alle Funktionen, die im Menü sichtbar sind, auch alle funktionieren.

Der Freepascalcompiler muss über das Menü "Tools->Tools einrichten" in die IDE integriert werden.
Das funktioniert exakt so, wie das mit dem Einrichtungsdialog der Delphi IDE funktioniert. Ich habe diesen Dialog so gestaltet, wie er bis Delphi 7 gestaltet war. Alternativ kann der Programmpfad Eures Freepascal Compilers auch in die Datei "fp.tls" eingetragen werden. Ich habe vor den Pfad dort das Wort "Compiler" gesetzt, welches im Menü "Tools" erscheint, wenn der Compiler in der IDE bekannt ist. Nach einem Leerzeichen folgt der Compilerpfad.

ACHTUNG:
----------------------------------------------------------------

Der Aufruf des Compilers muss über das Menü Compiler erfolgen!

Bei Aufruf über das Tools Menü wird eine Exception ausgelöst!

----------------------------------------------------------------

Wer das gute alte Turbo Pascal noch kennt oder bereits mit der Textmode IDE von Freepascal gearbeitet hat, sollte mit dieser IDE auf Anhieb zurecht kommen.

Getestet habe ich das Design mit Registern für den Quelltexteditor, wie das aus der Delphi IDE bekannt ist. Die MDI Variante ist noch fehlerhaft und deshalb empfehle ich dieses Design nicht.

Unterhalb des Quelltexteditors gibt es 4 Fenster in Registern angeordnet. Diese sind:

-Compiler-Ausgaben
-Debugger Ausgaben(derzeit noch uninteressant)
-Ausgaben Ihrer Anwendung
-Meldungen

Compiler Ausgaben:

Hier erscheinen alle Meldungen des Compilers während der Übersetzung.



Ausgaben Ihrer Anwendung

Hierhin schreibt das übersetzte Programm alle Ausgaben. Unter "Optionen->Umgebungseinstellungen->Vorgaben kann dieses Verhalten so geändert werden, das die Programmausgaben in die Windowsconsole umgeleitet werden.


Meldungen

Hier sollen Fehlermeldungen der Anwendung sichtbar werden.

Jetzt warte ich auf Eure möglichst konstruktive Kritik.

[fkerber]

Hi!

Ein Screenshot wäre klasse, damit man nicht die Katze - äh IDE - im Sack runterlädt ;)


Grüße, Frederic

[schöni]

Hallo fkerber!

Screenshot ist nun dabei.

Ich werde mich jetzt erst mal mit der Codevervollständigung beschäftigen, die ich gerne noch nachrüsten möchte.

[schöni]

Hallo,

Hier ist ein Update der IDE.

Neu ist:

-Speichern aller Dateien
-Speichern der geänderten Datei -> Anfrage vor Beenden
-Korrektes Umschalten der Editor im Registerkartenstil (Siehe Delphi IDE) funktioniert nun auch vom Menü Fenster->Fensterliste
-Dateiname der aktuellen Editordatei ist jetzt immer korrekt.

Diese Dinge waren bei der alten Version noch fehlerhaft, was ich jedoch erst nach intensiverem Test festgestellt habe. Deswegen jetzt erst das Update. Bitte um Entschuldigung.

[mimi]

Warum nutzt du kein Lazarus ? oder MSIDE das währen Wunderbare IDE'S.

[mkinzler]

Zitat:

Zitat von mimi

Warum nutzt du kein Lazarus ? oder MSIDE das währen Wunderbare IDE'S.

Und warum du nicht Delphi, VS oder Eclipse? :zwinker:

[mimi]

Weil, Delphi läuft nur Eingeschränkt unter Linux und Delphi ist nicht Kostenlos bzw. die Kostenlosen Versionen sind nur bedingt nutzbar bzw. sinnvoll. Eclipse bekomme ich nicht zum laufen bzw. ich kann mich da nicht einarbeiten, weil es einfach zu viele Funktionen gibt, VS kenne ich nicht *G*...

[mkinzler]

Aber hat sich entschlossen, eine eigene kleine IDE zu schreiben, welchen geanu seinen Bedürfnissen entspricht.

[schöni]

Zitat:

Zitat von mkinzler

Zitat:

Zitat von mimi

Warum nutzt du kein Lazarus ? oder MSIDE das währen Wunderbare IDE'S.

Und warum du nicht Delphi, VS oder Eclipse? :zwinker:

MSEIDE gefällt mir von der Optik und dem Aufbau her nicht. AUßerdem fehlt die Syntaxhervorhebung. Lazarus ist da schon besser.

An Delphi habe ich mich mittlerweile gewöhnt und so ist mir auch der Pascaldialekt von Delphi am geläufigsten. VS und Eclipse hab ich nocht nicht getestet. Hab aber da kein Vertrauen, weil die modernen IDE's auch immer mehr Rechnerressourcen brauchen.


Lazarus:? Da habe ich die Version 0.9.24 installiert.

Allerdings dauert das Übersetzen merklich länger, als bei Delphi. Für Delphi gibt es eine größere Anzahl Drittanbierterkomponenten.

Manche Komponenten, die es auch für Delphi gibt, sind für Lazarus weniger komfortabel. Bei Synedit fehlt in Lazarus zum Beispiel die SearchEngine, mit der ich im Editor Text suchen kann oder auch die Komponente SynCompletionProposal, mit der ich die Methodenergänzung mittels Auswahlliste implementieren kann.

Hinzu kommt der persönliche Ehrgeiz, mal selber eine verwendbare IDE zu bauen. Außerdem fasziniert mich der Formular Designer. Hatte mal zu Turbo Pascal Zeiten ein konfigurierbares Menü gebaut, mit dem der programmierer problemlos Menüs, wie heute in jeder Anwendung üblich, mit geeigneten Routinen bauen konnte. Dann kam Visual Basic, später Delphi. Da hatte ich Lust, mal so was nachzubauen.

Nun gibt es inzwischen Lösungen für einen FormDesigner im Internet. Da ich die Quelltexte einer solchen Lösung besitze (habe die diesbezüglichen Diskussionen hier in der DP verfolgt, auch wenn ich mich da nicht immer eingeloggt habe), will ich diese in eine eigens geschribene IDE einbauen.

Damit das auch sinnvoll ist, sollte die IDE jedoch zunächst ein brauchbares Niveau für den zukünftigen Anwender (Programmierer) besitzen. Derzeit kämpfe ich um einen Parser, damit ich die Codeergänzung per Auswahlliste realisieren kann. Klassenbezeichner + '.' schreiben, dann erscheint in Delphi eine Auswahlliste der möglichen Eigenschaften und Methoden, von denen ich dann in der Liste eine auswähle.

Diese IDE soll später auf andere Programmiersprachen erweitert werden, wobei ich natürlich darauf achte, das der Ressourcenverbrauch sich im Vergleich zu den großen Vorbildern Eclipse, Aktuellen Delphi Versionen... möglichst in Grenzen hält, damit die IDE schnell genug startet.

Delphi nutze ich auch als Entwicklungssystem für die IDE.

Zitat:

Zitat von mkinzler

Aber hat sich entschlossen, eine eigene kleine IDE zu schreiben, welchen geanu seinen Bedürfnissen entspricht.

Richtig! Deshalb baue ich da auch nur jene Funktionen ein, die ich für meine Programmierarbeit wirklich haben will und wirklich auch regelmäßig benutze.

[mimi]

Zitat:

Außerdem fasziniert mich der Formular Designer.

Ja, dass ist ein Punkt, den Lazarus nicht so toll gelöst habe. Hier habe ich auch schon überlegt, selbst was zu entwickeln. Weil der From Desiner ist alles andere als Gut.

Zitat:

Derzeit kämpfe ich um einen Parser, damit ich die Codeergänzung per Auswahlliste realisieren kann.

Die Code-Tools von Lazarus sind offen, vielleicht kannst du da rein schauen.

Gegen die allgemeine Idee, ist auch nichts einzusetzen, ich habe auch vor, was zu entwickeln, was es schon gibt. Aber nach den Gründen zu fragen ist doch nie verkehrt oder ?

[schöni]

Zitat:

Zitat von mimi

Zitat:

Außerdem fasziniert mich der Formular Designer.

Ja, dass ist ein Punkt, den Lazarus nicht so toll gelöst habe. Hier habe ich auch schon überlegt, selbst was zu entwickeln. Weil der From Desiner ist alles andere als Gut.

Zitat:

Derzeit kämpfe ich um einen Parser, damit ich die Codeergänzung per Auswahlliste realisieren kann.

Die Code-Tools von Lazarus sind offen, vielleicht kannst du da rein schauen.

Werde ich nicht machen, weil ich da bereits schlechte Erfahrungen gemacht habe, sobald ich irgendwas nicht verstehe und nachfragen muss. Habe das mit dem Debugger von Lazarus erlebt. Viele patzige Antworten gekriegt.

Habe dann letzlich ne eigene Lösung erarbeitet, die sich in der IDE auch nierderschlagen wird. Es ist ja auch das Beispielprogramm zum Debuggertest offen. Von dort erhalte ich alle Informationen, die ich brauche, um sie über Named Pipes in meine IDE zu übernehmen. Habe mir dazu per Suchbegriff "Named Pipes" einige DP Beiträge zum Thema angeschaut und werde mir daraus eine Lösung für mein Problem bauen.

Bezüglich Codevervollständigung werde ich den Parser bauen müssen. Werde sehen, wie ich da weiter komme. Ist ne gute Gelegenheit, sich mal mit LEX und YACC zu beschäftigen.

In der aktuellen Version klappt schon mal die Vervollständigung mit "Code Templates".

Eine Template, zum Beispiel "ifb" auswählen und "Strg+J" drücken.

Zitat:

Zitat von mimi

Gegen die allgemeine Idee, ist auch nichts einzusetzen, ich habe auch vor, was zu entwickeln, was es schon gibt. Aber nach den Gründen zu fragen ist doch nie verkehrt oder ?

Nach den Gründen zu fragen ist nicht falsch. Die hab ich ja oben schon genannt. Bei den vorhandenen IDE's stört mich da zum Teil auch die dahinter stehende Ideologie:

-Bei Lazarus werden Fehler totgeschwiegen, statt sie zu beseitigen und die IDE somit besser zu machen.

-Freepascal liefert trotz Windows und DevPascal auch für Windows noch immer die alte Free Vision IDE aus, statt einer modernen Windows IDE.

-Als ich einst bei der Weiterentwicklung der alten Free Vision IDE mit helfen wollte, hab ich ähnlich patzige Antworten erhalten, wie bei meinen Fragen zum Lazarus Debugger. Man hatte mir die aktuellen Quellen, mit denen die FVIsion IDE ohne Aufwand compilierbar gewesen wäre, nicht zukommen lassen, damals mit der Begründung, Borland hätte die Quellen noch nicht frei gegeben. Man hat aber dennoch diese Objektbibliothek im Textmode entwickelt, obwohl, wenn es wirklich an der Lizensierung gelegen hätte, ebenso gut eine voll grafische Objektbibliothek dieser Art für DOS hätte entwickeln können, die dann auch wirklich eine eigene Implementierung enthalten hätte und dazu noch besser gewesen wäre als das Original. Abe rman wollte ja unbedingt den alten Textmodus haben, obwohl heutige Rechner auch richtige Grafik beherrschen.

-Lazarus und Freepascal sind noch immer 2 getrennte Entwicklungszweige, statt da man die Entwicklerkapazitäten bündelt und so schneller zu einem besseren Produkt gelangt. Dann könnte man ja auf der DOS Seite die alte Free Vision IDE mitliefern, auf der Windows Seite dann Lazarus und evtl. alternativ für Entwickler, die den Designer nicht benötigen, eben DevPascal.

-Lazarus hat inzwischen eine Komplexität erreicht, die es mir unmöglich macht, in vertretbarer Zeit die Quelltexte ohne fremde Hilfe so tief zu verstehen, das ich danach effektiv an der Weiterentwicklung der IDE mitarbeiten könnte.
Abgesehen davon ist der Quelltext durchaus nützlich, um zu schauen, wie die Profis das eine oder andere Problem gelöst haben.

[mimi]

Zitat:

-Bei Lazarus werden Fehler totgeschwiegen, statt sie zu beseitigen und die IDE somit besser zu machen.

Ansicht werden sie sofort bzw. so schnell wie Möglich behoben. Wenn sie gemeldet wurden sind und auch reproduziert werden können.

Zitat:

-Freepascal liefert trotz Windows und DevPascal auch für Windows noch immer die alte Free Vision IDE aus, statt einer modernen Windows IDE.

Die Moderne Windows IDE ist Lazarus.

Zitat:

-Lazarus und Freepascal sind noch immer 2 getrennte Entwicklungszweige, statt da man die Entwicklerkapazitäten bündelt und so schneller zu einem besseren Produkt gelangt

Das hat schon einen Grund. Es sind auch zwei Projekte. Lazarus nutzt FPC.

Zitat:

Abgesehen davon ist der Quelltext durchaus nützlich, um zu schauen, wie die Profis das eine oder andere Problem gelöst haben.

Mir hat der Quelltext schon einige Male geholfen. Z.B. bei Fragen mit der RTTI.

Der FromDesiner von Lazarus ist einfach total schlecht gemacht. Selbst unter Linux gibt es bessere. Da kann man noch einiges besser machen. Das Praktische ist halt die Objekt Bibliothek von Lazarus.

[Delphi-Laie]

Zitat:

Zitat von mimi

Zitat:

-Bei Lazarus werden Fehler totgeschwiegen, statt sie zu beseitigen und die IDE somit besser zu machen.

Ansicht werden sie sofort bzw. so schnell wie Möglich behoben. Wenn sie gemeldet wurden sind und auch reproduziert werden können.

So schnell wie möglich, wenn sie gemeldet wurden und reproduziert werden können?!

Und was ist mit DIESEM Fehler?

[Mithrandir]

Das Thema hat in diesem Thread nichts mehr zu suchen! Bitte respektiert das endlich! :warn:

[mse1]

Zitat:

Zitat von schöni

MSEIDE gefällt mir von der Optik und dem Aufbau her nicht. AUßerdem fehlt die Syntaxhervorhebung.

???
Ich vermute mal, lediglich das Binary heruntergeladen und README.TXT nicht gelesen? Na?

Martin

[mkinzler]

Manchemal habe ich das Gefühl, dass das Team hier chinesisch spricht oder es eine geheime Ausblendfunktion für Beiträge für Teammitglieder gibt.

Bitte diskutiert in diesem Thread mur Schöni's IDE!
Über Fehler/Lücken/Vorteile/... anderer IDEs könnt ihr in sepatarten Threads diskutieren!

[mse1]

Zitat:

Zitat von mkinzler

Bitte diskutiert in diesem Thread mur Schöni's IDE!

Habe nicht alles gelesen sorry.
Ich reagiere lediglich allergisch, wenn ich sehe, dass Leute von MSEide+MSEgui nur die IDE-binary herunterladen, auf das Paket mit der Entwicklungsumgebung verzichten, obwohl dessen Notwendigkeit überall erwähnt wird, README.TXT nicht lesen und dann behaupten, MSEide habe kein syntax highlighting.
Nun ist ja mit mse1 ein Experte zur Runde gestossen. ;-)
Ich habe genau das was schöni vorhat bereits durchgestanden.

Wenn ich richtig verstanden habe, möchte schöni seine IDE als Ersatz der mit Free Pascal mitgelieferten fp IDE anbieten.
Um dieses Ziel zu erreichen, müsste schöniIDE auf allen oder wenigstens auf den wichtigsten Plattformen, welche von FPC unterstützt werden, laufen. Delphi kommt daher als Entwicklungsumgebung nicht in Frage.
fp wird von den Free Pascal Entwicklern auch deshalb geschätzt, da es mittels SSH ausgezeichnet auf externen Rechnern betrieben werden kann. Auch dies müsste von Anfang an berücksichtigt werden, wenn schöniIDE als Ersatz für fp dienen sollte.

Martin

[Hisoka]

hmm, ich weiß nicht ẃas ich von diesem Projekt halten soll. Ansich ist es ja ganz nett wenn jemand mal versucht was besseres als Lazarus zu entwickeln, aber hier fehlen mir die Grundgedanken von Free Pascal. Denn die Anwendung ist weder offen noch für mehrere Plattformen gedacht. Auch ist es sehr merkwürdig das man eine IDE in einer anderen Sprache schreibt als der Zielsprache. Denn es sollte doch immer das Ziel sein das man irgendwann die IDE in der IDE entwickeln kann.

Naja also diese ist nichts für mich. Windows Only Anwendungen sind nicht mein fall.

[BUG]

Ach Leute,

schöni möchte nur eine mal eine IDE für den Eigenbedarf entwickeln und ist so freundlich, uns am Ergebnis teilhaben zu lasse bzw. bittet uns um das Testen.
Ich glaube nicht, das das eine Teilnahme am [blink]Ultimate IDE Showdown Of Doom[/blink] sein Ziel ist.

Guck euch zB. mal den Java-Editor an.
In einer anderen Sprache geschrieben (vermutlich sogar Delphi), nicht plattformunabhängig, bietet nur einen Bruchteil von Funktionalität anderer Java-IDEs ...
Trotzdem habe ich ihn gerne für ein Programmierpraktikum im Studium (Java-Einführung) benutzt, da man ohne das man großartig mit Projektdateien herumfuchtelten mal schnell ein billiges ein-Klassen-Javaprogramm herunterschreiben kann.

Wenn euch die IDE nicht gefällt bzw. ihr sie unpraktisch findet: niemand zwingt euch dazu sie zu benutzten/testen/darüber nachzudenken.

Macht nicht so ein Politikum daraus.

Sorry, ist zwar auch OT, aber musste mal raus.

[Florian Hämmerle]

Ja also ich bin auch der Meinung, dass man jetzt hier nicht auf Aussagen herumhacken sollte, sondern lieber konstruktive Kritik an der IDE anbringen sollte.

Also mir gefällt die IDE sehr gut. Das einzige was mich etwas stört sind die Fremdkomponenten (Toolbar97 etc.) die verwendet werden. So ist es nicht möglich, den Source zu kompiliere ohne die Komponenten zu installieren.

Das Argument, dass man die IDE möglichst in der Zielsprache schreiben sollte hat schon seine Berechtigung, aber ist nicht nötig. Oder wurde Phase 5 in HTML geschrieben xD oder verwendet Delphi Prism nicht VS?...

Also an schöni: Mein Lob, weiter so!

[mse1]

Zitat:

Zitat von Florian Hämmerle

Ja also ich bin auch der Meinung, dass man jetzt hier nicht auf Aussagen herumhacken sollte, sondern lieber konstruktive Kritik an der IDE anbringen sollte.

Die Hinweise bezogen sich auf:

Zitat:

Zitat von schöni

Wenn das Freepascal Team von dem einige, wie ich den Eindruck gewonnen habe, auch hier in der DP angemeldet sind, bereit ist, diese IDE an Stelle der alten, mit FreeVision geschriebenen zu verteilen, werde ich den Debugger noch versuchen, nachzurüsten und ebenso die Codevervollständigung. In diesem Fall wird diese IDE OpenSource.

und sollen schöni helfen, sein Ziel zu erreichen.

[schöni]

Hallo Ihr alle!

Danke zuerst für Euer Interesse an der IDE und vorab für die kritischen Hinweise!

Zitat:

Zitat von mse1

Ich reagiere lediglich allergisch, wenn ich sehe, dass Leute von MSEide+MSEgui nur die IDE-binary herunterladen, auf das Paket mit der Entwicklungsumgebung verzichten, obwohl dessen Notwendigkeit überall erwähnt wird, README.TXT nicht lesen und dann behaupten, MSEide habe kein syntax highlighting.

Und ich reagiere allergisch, wenn Eigenschaften bei einem Programm zugesichert werden, die dann fehlen. In der Grundeinstellung, wenn ich die mseIDE zu ersten Mal starte, sehe ich nur ein Hauptfenster mit dem Menü und der Werkzeugleiste+Komponentenpalette, sonst nichts, und das auch noch mit viel zu kleiner Schrift. Wäre nett vom Entwicklungsteam, da mal defaultmäßig Nutzerfreundlichere Einstellungen vorzunehmen. Wer die OPtik dann wieder so haben will, wie sie jetzt ist, kann ja die Readme Datei studieren und gemäß den dortigen Anweisungen die Einstellungen anpassen.

In Lazarus erscheint auch Quelltexteditor und Formdesigner bereits beim Start und das Syntaxhighlighting ist defaultmäßig eingeschaltet, auch dann, wenn ich es versäumt habe, die Readme zu lesen. Die Quelltexte sind inzwischen so umfangreich, das ich, um das Verhalten der IDE zu ändern ebenso lange brauche um die Quelltexte im erforderlichen Umfang zu verstehen, wie ich brauche, um meine IDE auf diesen Entwicklungsstand zu bringen.

Weil wir gerade bei zugesicherten Eigenschaften sind, Der User Insider2004, der auch in der DP Mitglied ist, hat im Thread "Lazarus Konkurrenz zu Delphi 2005?" behauptet, das im neuen Lazarus 0.9.29 Delphi Quellcode ohne Änderung nach Lazarus portierbar sei. Wenn dem wirklicxh so wäre, dann könnte doch mal einer der dieses Lazarus zum Laufen gebracht hat, die Quelltexte nach Lazarus portieren. Vorher Toolbar 2000- und SpTBX Komponenten enfernen, das mach ich dann vorher. Dann wäre die IDE von heute auf morgen portiert. Selbstverständlich erhält derjenige, der die Portierung machen kann, dann auch die Quelltexte. Einfach PN an mich. Die portierten Quelltexte werden dann automatisch Open Source. Dann müsste allerdings noch die GPL zum Paket hinzugefügt werden.

Einfach PN an mich von demjenigen, der die Portierung machen kann.

Sollte ja gehen, wenn das brandneue Freepascal wirklich so kompatibel zu Delphi ist.

Zitat:

Zitat von mse1

Wenn ich richtig verstanden habe, möchte schöni seine IDE als Ersatz der mit Free Pascal mitgelieferten fp IDE anbieten.

Ja, das Angebot steht.

Zitat:

Zitat von mse1

Um dieses Ziel zu erreichen, müsste schöniIDE auf allen oder wenigstens auf den wichtigsten Plattformen, welche von FPC unterstützt werden, laufen. Delphi kommt daher als Entwicklungsumgebung nicht in Frage.
fp wird von den Free Pascal Entwicklern auch deshalb geschätzt, da es mittels SSH ausgezeichnet auf externen Rechnern betrieben werden kann. Auch dies müsste von Anfang an berücksichtigt werden, wenn schöniIDE als Ersatz für fp dienen sollte.

Danke für die Hinweise!

Hmmm, ich habe versucht, mit Lazarus zu entwickeln, aber die Synedit Komponenten sind dort nicht so gut ausgebaut. Das fängt mit der SearchEngine an, die nicht nur für die Funktion "Gehe zu Zeile X", sondern auch für den Debugger zum Auffinden der aktuellen Quellcodezeile gebraucht wird. Um da einen Workaround zu schreiben, brauche ich zu viel Zeit, die ich bei Verwendung der Delphi Synedit Kompos für anderes verwenden kann.

Außerdem, hat nicht jemand Kylix, um die IDE wenigstens für linux zu übersetzen? Im Zweifelsfall müsste ich die SpTBX- und Toolbar-2000 KOmponenten aus der IDE entfernen. Toolbars gibt es ja auch von der IDE her. Wie sieht es mit Delphi auf den anderen Plattformen aus? Gibt es das wirklich nur für Windows?

Und wie steht es mit WINE, dem Windoes Emulator auf Linux? Was wäre, wenn die IDE dort liefe?
Dann wäre sie schon mal für Linux verfügbar. Ist zwar vom Design her dann nicht so schön, wie wenn die IDE direkt auf Linux läuft, aber ist doch erst mal egal, wie das Betriebssystem die Software zum Laufen kriegt. Sofern die Performance nicht wesentlich darunter leidet.

Ok, dann würde die IDE für Linux verwendbar sein, falls sie auf WINE läuft. Aber auf ARM, MAC...?


Was heißt "die IDE auf externen Rechnern" betreiben?

Statt SSH spreche ich den Debugger über die Message WM_COPYDATA an. Ich gebe dann einen String mit.
Von der IDE zum Debugger enthält dieser String die Kommandos für den Debugger, Vom Debugger zur IDE kommen die ERgebnisse der Ausdruckauswertungen, Name der aktuellen Quelldatei, Quellcodezeile, Funktionsname...

Ich muss die Lazarus Version des Debuggers verwenden, wegen der Portabilitätsprobleme und wegen des
von Embarcadero verschiedenen Debuginfo Formates.

Wie umfangreich werden da die Änderungen, um die Übertragung der Botschaften statt mit Windows Messages mit SSH zu machen?

Das ist in der aktuell downloadbaren Version noch nicht enthalten, ein Update der IDE folgt, sobald der Debugger funzt.

Die Debuggerquellen nach Delphi portieren scheitert an den Unterschieden in den beiden Pascal Dialekten.

Wie könnte ich das mit SSH erreichen?

Zitat:

Zitat von Hisoka

aber hier fehlen mir die Grundgedanken von Free Pascal. Denn die Anwendung ist weder offen noch für mehrere Plattformen gedacht.

Wenn die IDE für Freepascal übernommen wird, wird sie Open Source. Windows Only liegt an der mangelnden Portabilität des Pascal Codes.
Bezüglich Synedit-Kompos hat es sicher einen Grund, warum die auf Lazarus nicht so umfangreich sind.
Oben hab ich schon gesagt, was mir da fehlt. Wenn jemand versucht, die IDE für Lazarus zu übersetzen, dürfte er, wenn ich die verwendeten Fremdkomponenten entferne, an genau dieser Stelle scheitern.

Außerdem habe ich in der IDE für den Directory Dialog das ShellTreeView eingesetzt, weil kein fertiger Directory-Auswahldialog in Delphi da ist. Den gibt es aber wiederum in Lazarus.

[Mithrandir]

Zitat:

Zitat von schöni

Und wie steht es mit WINE, dem Windoes Emulator auf Linux? Was wäre, wenn die IDE dort liefe?
Dann wäre sie schon mal für Linux verfügbar. Ist zwar vom Design her dann nicht so schön, wie wenn die IDE direkt auf Linux läuft, aber ist doch erst mal egal, wie das Betriebssystem die Software zum Laufen kriegt. Sofern die Performance nicht wesentlich darunter leidet.

Ok, dann würde die IDE für Linux verwendbar sein, falls sie auf WINE läuft. Aber auf ARM, MAC...?

Wenn du die IDE aber unter Wine laufen lässt, dann kannst du keine Programme für Linux kompilieren. Und unter Windows für Linux kompillieren ist quasi kaum (oder nur schwer) möglich.

[schöni]

Zitat:

Zitat von Daniel G

Zitat:

Zitat von schöni

Und wie steht es mit WINE, dem Windoes Emulator auf Linux? Was wäre, wenn die IDE dort liefe?
Dann wäre sie schon mal für Linux verfügbar. Ist zwar vom Design her dann nicht so schön, wie wenn die IDE direkt auf Linux läuft, aber ist doch erst mal egal, wie das Betriebssystem die Software zum Laufen kriegt. Sofern die Performance nicht wesentlich darunter leidet.

Ok, dann würde die IDE für Linux verwendbar sein, falls sie auf WINE läuft. Aber auf ARM, MAC...?

Wenn du die IDE aber unter Wine laufen lässt, dann kannst du keine Programme für Linux kompilieren. Und unter Windows für Linux kompillieren ist quasi kaum (oder nur schwer) möglich.

Wieso nicht für Linux kompilieren? Kann die IDE auf der Linuxseite nicht entweder, wie man es unter Windows machen würde, für die Linux Plattform übersetzen? Oder gleich den auf der Linux Plattform installierten Freepascal Compiler aufrufen. Die IDE bietet einen Toolsdialog an, der die Einrichtung des Compilers für die IDE erlaubt. Die IDE verwendet den Kommandozeilencompiler. Und wenn da derjenige auf der Linux-Plattform im Toolsdialog verfügbar gemacht wird. Im Menüpunkt "Compilieren" gibt es die Option "Zielplattform". Dort zum Beispiel "Linux" einstellen und fertig. Wüsste nicht, warum das nicht klappen sollte. Aus allen gesetzten Optionen baut die IDE eine Kommandozeile, die dem Compiler übergeben wird. Und wenn da als Zielplattform Linux eingestellt ist und noch dazu zwar die IDE auf WINE liefe, diese aber den FPC Compiler der Linuxplattform einbindet?

Wer die downloadbare IDE auf seinen Rechner lädt, muss zuerst seinen Freepascal Compiler in der IDE als Tool einrichten. Der Dialog dazu ist genau so aufgebaut, wie der in Delphi eingebaute.

[Mithrandir]

Hm, ok, ich hab gedacht, WINE sei ein Emulator. Erst jetzt habe ich gelesen, was der Name "WINE" eigentlich bedeutet. :mrgreen:

[Hisoka]

Der Name Hinter WINE sagt nicht alles. Aber der wichtige Punkt ist, niemand will eine halb funktionierende IDE und erst recht will niemand ein Windows Programm unter Linux laufen lassen wenn es nicht notwendig ist. Da sich WINE Anwendungen nicht ins System einpflegen und da die WinAPI nur teilweise funktioniert, ist eine solche Lösung nie optimal.


Also so würde es wohl kein ersatz werden. Auch glaube das die Free Pascal Entwickler keine IDE wollen würden die nicht portabel ist. Denn viele der Lazarus/FPC Entwickler stammen aus dem Linux Lager und dort will man native Anwendungen.


Ich glaube ich Spreche für viele Linux Nutzer wenn ich sage: Ich nutze lieber VIM zum Entwickeln als eine IDE die WINE nutzt. Gerade im Delphi Bereich dürften die Linuxnutzer immer noch ein Trauma von Kylix haben, denn das war genau das was du versuchst und es wurde schlecht akzeptiert.


Zur IDE selbst:
sie startet zumindest unter WINE, aber wirklich toll ist sie nicht. Also selbst der Lazarus Code Editor scheint besser zu sein. Da muss also noch etwas nach gebessert werden.(Tabs funktionieren nicht)
dazu können "X" zum schließen von Tabs nicht schaden.
Auch frage ich mich was die Leiste unten soll. Sie nimmt Platz weg und bringt nichts oder?
Für später wären Programmvorlagen vielleicht nicht schlecht.

Ansonsten ein netter Anfang aber wie schon erwähnt nichts für mich. Ich mag es wenn die Anwendungen in meinem System einheitlich sind.

[Daniel]

:gruebel:

Also eigentlich hat das Thema damit begonnen, dass Schöni eine auf seine Bedürfnisse zugeschnittene IDE erstellen wollte. Der Spaß und die Freude am Projekt dürften da wohl mit ein nennenswerter Aspekt in der Motivation gewesen sein. Ich hatte nicht den Eindruck, dass dieses Projekt jegliche Bedürfnisse befriedigen soll oder gar in Konkurrenz zu Projekten wie Lazarus, Eclipse oder dem VisualStudio treten soll.

[mse1]

Zitat:

Zitat von schöni

Wäre nett vom Entwicklungsteam, da mal defaultmäßig Nutzerfreundlichere Einstellungen vorzunehmen. Wer die OPtik dann wieder so haben will, wie sie jetzt ist, kann ja die Readme Datei studieren und gemäß den dortigen Anweisungen die Einstellungen anpassen.

Die relevanten Zeilen lauten:

Zitat:

4. Run 'yourdirectory/bin/mseide' on linux or
'yourdirectory\bin\mseide.exe' on windows.
5. In 'Settings'-'Configure MSEide'-'${MSEDIR}' select 'yourdirectory/msegui'.
6. In 'Project'-'Open' select 'yourdirectory/msegui/apps/demo/demo.prj'.
7. 'Target'-'Continue'.

5. ist unter anderem darum notwendig, damit MSEide die Syntax-Definitionsdateien findet.
MSEide kann nämlich nicht nur Pascal Texte auszeichnen, sondern mit entsprechenden Definitionsdateien beliebige Programmiersprachen. Mitgeliefert werden Definitionen für Pascal, C/C++ und SQL, weitere kannst du selbst schreiben, es ist einfacher ASCII-Text. Aber eben, diese Dateien befinden sich im Entwicklungsumgebungs-Paket und sind nicht nicht im exe eingebaut.
Das exe hat auch keine vollständige Fenster Einstellungen, diese befinden sich in anpassbaren Projekt-Templates welche ebenfalls im Entwicklungsumgebungspaket enthalten sind.

Zitat:

In Lazarus erscheint auch Quelltexteditor und Formdesigner bereits beim Start und das Syntaxhighlighting ist defaultmäßig eingeschaltet, auch dann, wenn ich es versäumt habe, die Readme zu lesen.

MSEide wird nicht nur zur Entwicklung von MSEgui-Pascal Programmen verwendet, sondern zum Beispiel auch für embedded Projekte mit AVR32 in C, wo der Formulardesigner keinen Sinn macht.

Zitat:

Die Quelltexte sind inzwischen so umfangreich, das ich, um das Verhalten der IDE zu ändern ebenso lange brauche um die Quelltexte im erforderlichen Umfang zu verstehen, wie ich brauche, um meine IDE auf diesen Entwicklungsstand zu bringen.

Das bezweifle ich. Der Entwicklunsaufwand für MSEide+MSEgui betrug etwa 14'000 Stunden bis zur vollen Funktionalität.
Für eine einfache IDE mit integriertem debugger (gdb) musst du mit etwa 2000 Stunden rechnen. Inklusive Formulardesigner und entsprechendem Widgetset geht es kaum unter 10'000 Stunden.

Zitat:

Was heißt "die IDE auf externen Rechnern" betreiben?

Statt SSH spreche ich den Debugger über die Message WM_COPYDATA an. Ich gebe dann einen String mit.
Von der IDE zum Debugger enthält dieser String die Kommandos für den Debugger, Vom Debugger zur IDE kommen die ERgebnisse der Ausdruckauswertungen, Name der aktuellen Quelldatei, Quellcodezeile, Funktionsname...

Das heisst, dass IDE, Compiler und Debugger auf einem fremden System unter möglicherweise anderem Betriebssystem laufen. Lediglich die Anzeige läuft auf dem lokalen Computer.
Da fp in einem Textterminal angezeigt wird, sind die Anforderungen an die Übertragungskapazität vom/zum entfernten Rechner niedrig.

Zitat:

Ich muss die Lazarus Version des Debuggers verwenden, wegen der Portabilitätsprobleme und wegen des
von Embarcadero verschiedenen Debuginfo Formates.

Wie umfangreich werden da die Änderungen, um die Übertragung der Botschaften statt mit Windows Messages mit SSH zu machen?

Das wäre dann gdb. Die Dokumentation ist hier:
http://sourceware.org/gdb/current/onlinedocs/gdb/
Beachte vor allem den Bereich GDB/MI.
Bei Remote-Debugging läuft lediglich ein Teil des Debuggers (gdbserver) und das zu testende Programm auf dem entfernten Rechner. Die Verbindung von gdb (läuft auf dem lokalen Rechner) und gdbserver (läuft auf dem entfernten Rechner) geschieht dabei z.B. mit TCP/IP und passiert gdb intern, darum musst du dich nicht kümmern.

Martin

[mse1]

Zitat:

Zitat von Daniel

:gruebel:

Also eigentlich hat das Thema damit begonnen, dass Schöni eine auf seine Bedürfnisse zugeschnittene IDE erstellen wollte.

schöni möchte, dass das FPC-Team die textbasierte fp IDE durch seine graphische IDE ersetzt. Damit dies möglich wird, sind einige Grundvoraussetzungen notwendig.

[mkinzler]

Bitte macht ein eigene Thema für MSE und Co. auf. Diese(s) könnt ihr dann hier verlinken.
Hier sollte es nur um die IDE von Schöni gehen!

[schöni]

Hallo!

Zitat:

Das heisst, dass IDE, Compiler und Debugger auf einem fremden System unter möglicherweise anderem Betriebssystem laufen. Lediglich die Anzeige läuft auf dem lokalen Computer.
Da fp in einem Textterminal angezeigt wird, sind die Anforderungen an die Übertragungskapazität vom/zum entfernten Rechner niedrig.

Zitat:

Ich muss die Lazarus Version des Debuggers verwenden, wegen der Portabilitätsprobleme und wegen des
von Embarcadero verschiedenen Debuginfo Formates.

Wie umfangreich werden da die Änderungen, um die Übertragung der Botschaften statt mit Windows Messages mit SSH zu machen?

Das wäre dann gdb. Die Dokumentation ist hier:
http://sourceware.org/gdb/current/onlinedocs/gdb/
Beachte vor allem den Bereich GDB/MI.
Bei Remote-Debugging läuft lediglich ein Teil des Debuggers (gdbserver) und das zu testende Programm auf dem entfernten Rechner. Die Verbindung von gdb (läuft auf dem lokalen Rechner) und gdbserver (läuft auf dem entfernten Rechner) geschieht dabei z.B. mit TCP/IP und passiert gdb intern, darum musst du dich nicht kümmern.

Martin

Aber, wo kriege ich die Quelltexte des Debugservers her. Habe soeben im Lazarus Verzeichnis danach gesucht und nur die Binärdatei desselben gefunden. Für GDB/MI gibt es die Klasse TGDBMIDebugger, die im Quelltext dabei ist. Ich kämpfe noch immer um den Erhalt der relevanten Debuginfo.

Falls die gedbServer und Cvdwarf Quellen nur in c verfügbar sind, ist die Interfacebeschreibung wichtiger. In c kennen ich mich nicht so gut aus, das ich von den Quellen allzu viel profitiere.

Habe deshalb das Beispielprojekt "debugtest.lpr" im Verzeichnis "<lw:/Programme/lazarus/debugger/test"

Dort erhalte ich die Exception EConverterror, deren Stelle ich im Quelltext noch nicht gefunden habe. Der Fehler liegt nicht im Testprogramm, das vom Debugger untersucht wird, sondern definitiv im Debuggerinterface selber.

Ich würd gerne diese Teil als Debugserver verwenden, weil ich da, so das fehlerfrei arbeitet, alle wichtigen Debuginfos bereits erhalte. Im debugtest-Beispielprogramm werden alle Ausgaben in ein Textfenster geschrieben. Unter Windows kann ich dieses Programm so starten, das es beim Start der IDE unsichtbar bleibt, so das ich nur einen Mechanismus implementieren muss, der die Debuginfo zur IDE überträgt.

Aber vielleicht ist ja das Interface des gdbServer und Cvdwarf wirklich günstiger.

Ich habe in einem zweiten Tab meines Mozilla Browsers die oben genannte GDB Dokumentation geöffnet.

In welchem Abschnitt derselben finde ich die relevanten Informationen gdbServer und Cvdwarf. Ich brauche: Name der aktuell untersuchten Quelldatei, Zeilennummer, Name der Funktion/Prozedur/Methode und evtl. die aktuelle Adresse im Binärcode. In der Unit Debugger.pp gibt es den Typ TGDBLocationRec, der diese Information bereit stellt.

AUßerdem brauche ich den Verlauf des Aufruf Stack und ggf. die Liste der Haltepunkte.

Ne richtige standardiesierte Schnittstelle zum bereits vorhandenen Debugger ist ja allemal besser, als irgendeine zuasammengefrickelte eigene Lösung.

Bei der Textmode-IDE habe ich die Units gdbInt.pp und gdbCon.pp gefunden, die aber nicht vollständig implementiert sind, Das wird erst später in einer anderen aif die IDE bezogenen Unit nachgeholt. Lazarus nutzt wiederum ein anders aufgebautes Debuggerinterface.

MinGW-Verzeichnis von Lazarus hab ich nur die Binärdateien. Im FPC Verzeicnis gibt es noch debugsvr.pp im Verzeichnis debudSvr oder ähnlich. Die dort befindlichen Units setzen aber die Unit Linux voraus. Damit scheiden die auf der Windows Plattform aus.

[schöni]

Zitat:

Zitat von Hisoka

Der Name Hinter WINE sagt nicht alles. Aber der wichtige Punkt ist, niemand will eine halb funktionierende IDE

Ok, die IDE ist auch noch nicht richtig fertig. Da gibt es noch ordentlich Arbeit für mich.

Zitat:

Zitat von Hisoka

und erst recht will niemand ein Windows Programm unter Linux laufen lassen wenn es nicht notwendig ist. Da sich WINE Anwendungen nicht ins System einpflegen und da die WinAPI nur teilweise funktioniert, ist eine solche Lösung nie optimal.

Hmmm! Unten in Deinem Beitrag sagst Du ja auch, das zum Beispiel die Tabs dort nicht funktionieren.
Das ist natürlich ein schlagendes Argument für Native Anwendungen! Ok!

Zitat:

Zitat von Hisoka

Also so würde es wohl kein ersatz werden. Auch glaube das die Free Pascal Entwickler keine IDE wollen würden die nicht portabel ist. Denn viele der Lazarus/FPC Entwickler stammen aus dem Linux Lager und dort will man native Anwendungen.

Verständlich! Schade, das sich die Pascal Dialekte von Delphi und Lazarus unterscheiden, sonst wäre eine Portierung möglich.

Zitat:

Zitat von Hisoka

Ich glaube ich Spreche für viele Linux Nutzer wenn ich sage: Ich nutze lieber VIM zum Entwickeln als eine IDE die WINE nutzt. Gerade im Delphi Bereich dürften die Linuxnutzer immer noch ein Trauma von Kylix haben, denn das war genau das was du versuchst und es wurde schlecht akzeptiert.

VIM kenne ich nicht. Ich kenne den Editor VI. Der ist mir aber zu kryptisch.

Zitat:

Zitat von Hisoka

Zur IDE selbst:
sie startet zumindest unter WINE, aber wirklich toll ist sie nicht. Also selbst der Lazarus Code Editor scheint besser zu sein. Da muss also noch etwas nach gebessert werden.(Tabs funktionieren nicht)

Hmmmm, da haben wir's. Da ist eine Native Anwendung wirklich besser. Wie gut funktioniert MDI? Oder wäre dann, wenn schon WINE, SDI das Konzept der Wahl?

Zitat:

Zitat von Hisoka

dazu können "X" zum schließen von Tabs nicht schaden.

Das ist ein ganzes Stück schwieriger zu realisieren, denn bei der PageControl Komponente fehlen die "X" oder ich habe die passende Einstellung noch nicht gefunden. Einen TSpeedbutton auf das Tabregister setzen? Hab ich noch nicht probiert. Kann ich aber mal testen.

Bei den SpTBX Komponenten gibt es ein PageControl, das diese "X" auf jedem Tab standardmäßig bereit stellt. Aber der Test auf WINE hat ja mit der bisher von mir verwendeten PageControl Komponente schon mal ergeben, das dann die Tabs nicht funktionieren. Um die Tabs aus dem SpTBX PageControl zu testen müsste ich einen Dummy Applikation bauen, die diese Page Control verwendet. Die müsste dann auf WINE getestet werden.

Das dürfte aber dann nicht mehr auf Freepascal zu portieren sein, es sei denn die nueu Freepascal Version kann wirklich Delphi Quelltext ohne Änderung übersetzen, wie das schon behauptet wurde.
Allerdings weiß ich nicht, ob diese Komponenten auch für Linux verfügbar sind.

Zitat:

Zitat von Hisoka

Auch frage ich mich was die Leiste unten soll. Sie nimmt Platz weg und bringt nichts oder?

Die Leiste wird in der nächsten Version nicht mehr sichtbar sein! Die hatte ich eingebaut, weil sie in der Textmode IDE vorhanden ist. Das die Liste nix bringt, kannst Du nicht so sagen, denn die Buttons sind mit der angegebenen Funktionalität hinterlegt. Entweder die angegebene Funktionstaste drücken oder den Button mit der Maus anklicken. Außer F1. Die Hilfe folgt erst noch.

Zitat:

Zitat von Hisoka

Für später wären Programmvorlagen vielleicht nicht schlecht.

Ok, werde ich berücksichtigen. Hab ich eh vor, einzubauen!

Zitat:

Zitat von Hisoka

Ansonsten ein netter Anfang aber wie schon erwähnt nichts für mich. Ich mag es wenn die Anwendungen in meinem System einheitlich sind.

Das ist subjektiv. Mit gefällt dafür VI nicht.

[mse1]

Zitat:

Zitat von schöni

Ich brauche: Name der aktuell untersuchten Quelldatei, Zeilennummer, Name der Funktion/Prozedur/Methode und evtl. die aktuelle Adresse im Binärcode.

In GDB/MI.
Zur Kommunikation mit gdb gibt es mehrere Möglichkeiten. Eine erste IDE (die ich nicht erwähnen darf) benützt die Library libgdb, zwei andere IDE's (die ich ebenfalls nicht erwähnen darf) benutzen pipes zur gdb Applikation. Ersteres ist problematisch, da libgdb nicht mehr zum Lieferumfang der gdb Distribution gehört.

Zitat:

Habe deshalb das Beispielprojekt "debugtest.lpr" im Verzeichnis "<lw:/Programme/lazarus/debugger/test"

Dort erhalte ich die Exception EConverterror, deren Stelle ich im Quelltext noch nicht gefunden habe. Der Fehler liegt nicht im Testprogramm, das vom Debugger untersucht wird, sondern definitiv im Debuggerinterface selber.

Ich würd gerne diese Teil als Debugserver verwenden, ...

Dieser Code ist möglicherweise GPL was bedeutet, dass du den gesamten Quelltext veröffentlichen musst, falls du dein Produkt weitergibst. Möglicherweise auch den Code der Delphi units was durch die Delphi Lizenz verboten wird.
Das ist natürlich auch wieder OT, sorry.

[mkinzler]

Man darf andere hier schon nennen, aber hier bitte nicht deren Fehler usw diskutieren

[schöni]

Zitat:

Zitat von mse1

Zitat:

Zitat von schöni

Ich brauche: Name der aktuell untersuchten Quelldatei, Zeilennummer, Name der Funktion/Prozedur/Methode und evtl. die aktuelle Adresse im Binärcode.

In GDB/MI.
Zur Kommunikation mit gdb gibt es mehrere Möglichkeiten. Eine erste IDE (die ich nicht erwähnen darf) benützt die Library libgdb, zwei andere IDE's (die ich ebenfalls nicht erwähnen darf) benutzen pipes zur gdb Applikation. Ersteres ist problematisch, da libgdb nicht mehr zum Lieferumfang der gdb Distribution gehört.

Am liebsten wäre mir auf der IDE Seite ein einheitliches Interface, das so beschaffen ist, das ich später auch einen Embarcadero Debugger anschließen kann, wenn ich mit einem Delphi Compiler VCL Code übersetzt habe. Dann könnte mir einfallen, die IDE auf Visual C++ zu erweitern und brauche vielleicht einen Microsoft Debugger, wegen der unterschidlichen Formate der Debuginformationen.

Solch einheitliches Interface hab ich für zukünftige Versionen der IDE eh geplant und zwar so, das ich, während ich jetzt Klassen anspreche, die mir meine Aufgabe erledigen, stattdessen ein geeignetes Interface baue und dann anspreche, wobei die Implentation als Plugin realisiert wird. Mehere .dll mit der Funktionalität. Kommt aber erst später, wenn die Basisfunktionen der IDE alle drin sind.

Gibt es dieses einheitliche Debuggerinterface oder ist es da geschickter, 3 verschidene Interfaces zu bauen? Die Erkennung des aktuell auszuwählenden Interfaces könnte über eine Kennung in der .exe erfolgen, ob dwarf, omf oder coff Format. Oder an Hand des Compilernamens. fpc.exe -> dwarf; gcc.exe->dwarf; bcc*.exe->omf; dcc*exe,oxygen.exe->omf vcc.exe->omf.

Warum darfst Du die IDEs nicht erwähnen? Das Du mir davon den Quellcode nicht unbedingt zugänglich machen darfst, verstehe ich. Aber die IDE verschweigen?

Mit Pipes hab ich experimentiert. Problem ist dort, das ich bei Informationsaustausch nicht weiß, was für ein Ereignis da den Empfang von Daten signalisiert. Sobald ich aber Windows Messages verwende, bin ich Plattformabhängig.

Habe dann ein DP Beispiel zu named pipes mit Formularen angeguckt. Da kann ich einen Datensatz senden. Der Emfänger sinalisiert den Emfang der Daten jedoch durch ButtoClick. Ich brauch aber ein Ereignis, das den Datenempfang signalisiert und bei Auftreten des Ereignisses die Daten anzeigt.
Gibt es da was in den Tiefen der VCL?

Dann bin ich auf WM_CopyData gestoßen, was aber wieder eine Windows Botschaft ist und damit plattformabhängig.

Ich könnte mir vorstellen, das die Namenskonvention für Pipes plattformübergreifend gültig ist. Aber das Öffnen der Pipe? Es ließe sich natürlich eine Schnittstelle mit eigenen Aufrufroutinen- oder Methoden bauen.

Zitat:

Habe deshalb das Beispielprojekt "debugtest.lpr" im Verzeichnis "<lw:/Programme/lazarus/debugger/test"

Dort erhalte ich die Exception EConverterror, deren Stelle ich im Quelltext noch nicht gefunden habe. Der Fehler liegt nicht im Testprogramm, das vom Debugger untersucht wird, sondern definitiv im Debuggerinterface selber.

Ich würd gerne diese Teil als Debugserver verwenden, ...

Dieser Code ist möglicherweise GPL was bedeutet, dass du den gesamten Quelltext veröffentlichen musst, falls du dein Produkt weitergibst. Möglicherweise auch den Code der Delphi units was durch die Delphi Lizenz verboten wird.
Das ist natürlich auch wieder OT, sorry.[/quote]

So weit wie ich die GPL verstanden habe, dürfte ich nur verpflichtet sein, den Quelltext der GPL Teile weiter zu geben. Das wäre dann das angepasste Programm des Debuggerbeispiels. Für den Rest dürfte die Nennung einer Bezugsquelle ausreichen. Dabei berufe ich mich auf Lazarus 0.9.22, da dort der aktuelle EConverterror nicht aufgetreten ist, den ich in der 0.0.24er Lazarus Version erhalte, sobald ich nach der Initialisierung des Debuggers den ersten Programmschritt ausführe.

Quelltext den ich dann auf jeden Fall weitegeben muss, wäre wie gasgt mein verändetes Programm. Konkret betrifft das die Unit DebugtestForm. Werde wohl dann das geänderte Programm samt seinem Quellcode der IDE beilegen. Zum erneuten Übersetzen sind dann halt noch die von mir nicht veränderten Dabuggerunits nötig, die dann nicht Bestandteil meiner IDE werden, sondern im Lazarus Projekt zu finden sind.

Werde sehen, welchen Workaround ich für den EConvertError finde. Vielleicht sollte ich mir Lazarus 0.0.22 wieder installieren. Dann müsste ich auf jeden Fall nur das von mir geänderte Beispielprogramm weiter geben.

Bei der Suche nach dem EConvertError verlangt der Lazarus Debugger nämlich ständig neue .inc Dateien, die ich dann mühsam suchen muss, um sie ins Projekt einzubinden, damit ich mich zur Fehlerstelle vortasten kann. Eh ich mich da verpflichte diese .inc Dateien mit weiter zu geben, weil da vielleicht Änderungen nötig werden, installier ich mir eheer wieder die vorangegangene Lazarus Version. Mit der gab es den EConvertError nicht. Dann muss ich auch keine geänderten .inc Dateien weiter geben.

Andere Quellen, die ich genutzt habe, hab ich ja nicht verändert und sind daher im Lazarus Projekt einzusehen. Ich weiß, das ich, statt die Quelltexte selber weiter zu geben, auch eine Quelle nennen kann, wo die Quelltexte zu erhalten sind. Wenn die IDE nicht Bestandteil von Freepascal wird, werden die von mir nicht veänderten Quellcodes auch nicht zum Übersetzen gebraucht.

Das hier habe ich soeben in der Wikipedia zur GPL gefunden:

Zitat:

Alle abgeleiteten Programme eines unter der GPL stehenden Werkes dürfen von Lizenznehmern nur dann verbreitet werden, wenn sie von diesen ebenfalls zu den Bedingungen der GPL lizenziert werden.

Der Debugserver wäre dann das abgeleitete Programm, das aus dem Testbeispiel hervorgegangen ist. Die IDE greift darauf nur zu. Das passiert mit Nachrichten. Als .dll einbinden dürfte am Binärformat scheitern. Hab da scon mal Versuchre gemacht. Statisch in die IDE einbinden klappt somit auch nicht. Habe Versuche sowohl mit LoadLibrary() als auch mit DLL-Interfaceunit gemacht. Hat beides nicht funktioniert. Und mit Delphi die Debuggerteile übersetzen scheitert an den Unterschieden im Pascaldialikt. So bleibt der Debugserver ein selbständiges Programm, womit ich bei der IDE weitehin volle Entscheidungsfreiheit bezüglich der Lizenz haben dürfte.

Anders wäre es, wenn ich als Quellcodeeditor den aus Lazarus verwenden würde. Dann wäre auch die IDE unter GPL zu stellen.

[schöni]

Zitat:

Zitat von Florian Hämmerle

Ja also ich bin auch der Meinung, dass man jetzt hier nicht auf Aussagen herumhacken sollte, sondern lieber konstruktive Kritik an der IDE anbringen sollte.

Also mir gefällt die IDE sehr gut. Das einzige was mich etwas stört sind die Fremdkomponenten (Toolbar97 etc.) die verwendet werden. So ist es nicht möglich, den Source zu kompiliere ohne die Komponenten zu installieren.

Werd mal versuchen, die Toolbar, die ich mittels der Toolbar 2000 Komponenten gebaut habe, so zur Laufzeit zu Instantiieren, das die Kompos nicht mehr installiert sein müssen. SpTbx macht noch nix weiter, ist zur Laufzeit unsichtbar. Die Bezüge dazu in der .dfm Datei können daher bedekenlos entfernt werden. Werde das mal in meiner IDE auch für Toolbar 2000 probieren und dann die Toolbar komplett zur Laufzeit erzeugen. Das gleiche habe ich mit den Sysnedit KOmpos auch vor, da ich hier wegen der Codevervollständigung eh einen neuen Syntaxeditor ableiten will. Den kann ich dann auch gleich so in die IDE einpflegen, das alles nötige zur Laufzeit passiert.

Zitat:

Also an schöni: Mein Lob, weiter so!

Danke!

[cookie22]

Zitat:

Zitat von schöni

Zitat:

Zitat von Florian Hämmerle

Ja also ich bin auch der Meinung, dass man jetzt hier nicht auf Aussagen herumhacken sollte, sondern lieber konstruktive Kritik an der IDE anbringen sollte.

Also mir gefällt die IDE sehr gut. Das einzige was mich etwas stört sind die Fremdkomponenten (Toolbar97 etc.) die verwendet werden. So ist es nicht möglich, den Source zu kompiliere ohne die Komponenten zu installieren.

Werd mal versuchen, die Toolbar, die ich mittels der Toolbar 2000 Komponenten gebaut habe, so zur Laufzeit zu Instantiieren, das die Kompos nicht mehr installiert sein müssen. SpTbx macht noch nix weiter, ist zur Laufzeit unsichtbar. Die Bezüge dazu in der .dfm Datei können daher bedekenlos entfernt werden. Werde das mal in meiner IDE auch für Toolbar 2000 probieren und dann die Toolbar komplett zur Laufzeit erzeugen. Das gleiche habe ich mit den Sysnedit KOmpos auch vor, da ich hier wegen der Codevervollständigung eh einen neuen Syntaxeditor ableiten will. Den kann ich dann auch gleich so in die IDE einpflegen, das alles nötige zur Laufzeit passiert.

Zitat:

Also an schöni: Mein Lob, weiter so!

Danke!

was ist an toolbar 2000 schlecht, ausser das man sie installieren muss. durch sptbx kannst du dein programm halbwegs professionell aussehen lassen warum willst du auf sowas verzichten.

[schöni]

Zitat:

Zitat von cookie22

Zitat:

Zitat von schöni

Zitat:

Zitat von Florian Hämmerle

Ja also ich bin auch der Meinung, dass man jetzt hier nicht auf Aussagen herumhacken sollte, sondern lieber konstruktive Kritik an der IDE anbringen sollte.

Also mir gefällt die IDE sehr gut. Das einzige was mich etwas stört sind die Fremdkomponenten (Toolbar97 etc.) die verwendet werden. So ist es nicht möglich, den Source zu kompiliere ohne die Komponenten zu installieren.

Werd mal versuchen, die Toolbar, die ich mittels der Toolbar 2000 Komponenten gebaut habe, so zur Laufzeit zu Instantiieren, das die Kompos nicht mehr installiert sein müssen. SpTbx macht noch nix weiter, ist zur Laufzeit unsichtbar. Die Bezüge dazu in der .dfm Datei können daher bedekenlos entfernt werden. Werde das mal in meiner IDE auch für Toolbar 2000 probieren und dann die Toolbar komplett zur Laufzeit erzeugen. Das gleiche habe ich mit den Sysnedit KOmpos auch vor, da ich hier wegen der Codevervollständigung eh einen neuen Syntaxeditor ableiten will. Den kann ich dann auch gleich so in die IDE einpflegen, das alles nötige zur Laufzeit passiert.

Zitat:

Also an schöni: Mein Lob, weiter so!

Danke!

was ist an toolbar 2000 schlecht, ausser das man sie installieren muss. durch sptbx kannst du dein programm halbwegs professionell aussehen lassen warum willst du auf sowas verzichten.

Gar nicht. Werde ein Interface bauen, das solche Toolbars oder das PageControl von SpTBX aber auch PageControl wahlweise verwenden kann. Sollte ja mit Interfaces gehen. Wem dann die Toolbar2000 KOmpos oder die SpTBX nicht gefallen, kann ja andere verwenden.

Ist allerdings noch ein Stück Arbeit. Will erst mal Debugger + Codevervollständigung abschließen.

Zitat:

Zitat von ein anderer DP User

Das heisst, dass IDE, Compiler und Debugger auf einem fremden System unter möglicherweise anderem Betriebssystem laufen. Lediglich die Anzeige läuft auf dem lokalen Computer.
Da fp in einem Textterminal angezeigt wird, sind die Anforderungen an die Übertragungskapazität vom/zum entfernten Rechner niedrig.

Stimmt natürlich, wenn die IDE auf dem entfernten Rechner läuft. Das spräche für den Textmode. Wie aber wäre es, wenn die IDE so konfiguriert wäre, das sie wie ein Internetbrowser die Quelldateien von Server holt und am lokalen Rechner anzeigt und bearbeitet? Das Kommando zum Übersetzen müsste natürlich dann abgesetzt werden, das sind aber nicht allzu viele Bytes, es sei denn, der Compiler könnte den geänderten Quelltext von meinem lokalen Rechner übersetzen, obwohl der Compiler auf dem entfernten Rechner liegt. Dann müssten natürlich nahezu alle IDE Kommandos als Netzwerkanforderungen ausgelegt werden. Wäre ein anderes, aber hochinteressantes Konzept. Dann könnte die IDE auf dem lokalen Rechner grafisch sein, weil ja über Netz nur Kommandos übertragen werden. :gruebel:

Werd aber erst mal mein bisheriges Konzept weiter verfolgen. Erweiterungen folgen später.

Hmmm, werd mir mal die Compilerfarm auf Sourceforge angucken. Hab mich bisher immer davor gedrückt. :gruebel:


Kleiner Nachtrag:

Werde mir bezüglich Debugger ne ganz andere Lösung einfallen lassen müssen. Lazarus spinnt mit der Fehlermeldung "MyDBGprg.lpr(15,1) Error:Can't create object file: MyDBGprg.exe"

ALs Folgefehler kommt natürlich die Meldung, das die .exe nicht erzeugt werden kann. Keine Ahnung, was da wieder schief läuft. Aber ich bleibe dran. Allerdings wird der Debugger unter diesen Umständen auf jeden Fall Closed Source. Anderenfalls brauch ich wirksame Hilfe.

FR. 12.02.2010:
Hab aber heute Morgen eine Lösung mit Schnittstelle gefunden. Die ist aber eh nich plattformunabhängig. Der gdbServer sieht allerdings viel versprechend aus. Mal schauen..

[Florian Hämmerle]

Hi

Ich wollte mal fragen wie weit die Entwicklung schon vorangeschritten ist?

mfg Florian

[schöni]

Zitat:

Zitat von Florian Hämmerle

Hi

Ich wollte mal fragen wie weit die Entwicklung schon vorangeschritten ist?

mfg Florian

Nun ja, ich habe die Optik bissl verbessert und kämpfe noch mit der Debuggerschnittstelle.

Die neue Optik, (nur geringfügig verändert), kann hier schon mal bewundert werden. Will sie nicht an den Threadanfang stellen, da die Änderungen marginal sind. Nur die Werkzeugleiste bissl erweitert. Das sind jetzt auch nur 2 Screenshots, weil der Debugger noch nicht enthalten ist. Die Schnittstelle arbeitet noch nicht korrekt. Deshalb gebe ich die neue Version auch noch nicht raus.