|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > Eure Anforderungen an eine IDE für AmigaOS? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
|
12.06.2012, 15:34 Uhr Reth Posts: 1858 Nutzer |
Hi zusammen, kurze Frage: Was wären denn eure Anforderungen an eine moderne IDE für das AmigaOS (natürlich auch MOS/AROS - spiele aber mit dem Gedanken eine Bounty auf AmigaBounty.net für AOS4 und ggf. AOS3.x einzustellen und möchte Ideen/Vorschläge sammeln)? Hier mal meine Wünsche:
Möchte in den nächsten Tagen evtl. ein Bounty dafür eröffnen (mal sehen - bin erst einmal auf Ideensuche). Codebench von Rigo gefällt mir schon ganz gut und geht auch in die Richtung. Da er aber noch viele andere Dinge zu tun hat, die z.T. auch wichtiger sind, wird die Entwicklung dort wohl erst mal nicht so schnell vorangehen (vielleicht schnappt er sich das ggf. entstehende Bounty ja auch). Danke schon mal! Ciao [ - Antworten - Zitieren - Direktlink - ] |
|
12.06.2012, 15:42 Uhr ylf Posts: 4112 Nutzer |
Ein WYSIWYG GUI Editor? [ - Antworten - Zitieren - Direktlink - ] |
|
12.06.2012, 17:11 Uhr Holger Posts: 8116 Nutzer |
Wenn Du schon auf Eclipse eingehst, die grundlegende Idee, die Software modular aufzubauen und eine durchdachte Plug-In-Schnittstelle anzubieten, sollte sich wiederfinden. Und dann sollte das Ganze nicht so auf den Editor fokussiert sein. Editoren mit ein bisschen Entwicklungssupport gibt’s schon genug. Projektverwaltung, Team-Support, etc. müssten wesentlich mehr in den Vordergrund gerückt werden. Wobei es im Amiga-Bereich schon ein Erfolg wäre, ein Paket anzubieten, das sofort nach dem Runterladen und ggf. Installieren ohne Rumbastelei funktioniert. Insb. wenn es ums Unterstützen verschiedener Plattformen beim Build geht… -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
12.06.2012, 17:47 Uhr ZeroG Posts: 1487 Nutzer |
@Reth: Ich bin der meinung das OS4 nicht noch ein IDE-Projekt braucht, man sollte lieber mit Rigo sprechen und mit seinem segen Codebench unterstützen bzw. ergänzen. [ - Antworten - Zitieren - Direktlink - ] |
|
12.06.2012, 18:05 Uhr Reth Posts: 1858 Nutzer |
Danke für eure Anregungen. @ZeroG: Ja, das würde ich auch befürworten. Allerdings hat er ja mit AmiUpdate, AOS4-Betatest usw. eh schon genug um die Ohren. Keine Ahnung, wie da die Prio bei ihm ist. Werde ihn nochmal kontaktieren. Bleibt dann erstmal noch AOS3.x. Wie seht ihr denn den Bedarf hierfür? Und wie würden die MOS-Entwickler einen Bedarf für ihr SDK sehen? [ - Antworten - Zitieren - Direktlink - ] |
|
12.06.2012, 18:23 Uhr Holger Posts: 8116 Nutzer |
Zitat:Richtig, es hat ja schon eines im 0.23-Stadium, das sich in enormen Tempo (letztes Update September letzten Jahres) weiterentwickelt. Nicht dass noch die AOS4-Entwickler eine Überdosis moderner leistungsfähiger IDEs bekommen. Dann macht Reth halt aus dem „ggf AOS 3“ ein „auf jeden Fall AOS3 und ggf AROS und MOS“ und schon ist der Bedarf da. Zitat:Warum? Seit wann muss man sich den Segen eines anderen, möglicherweise nicht mal mehr aktiven Entwicklers holen, um eine Bounty zu eröffnen? -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
12.06.2012, 18:27 Uhr Holger Posts: 8116 Nutzer |
Zitat:IDEs sind nicht wirklich performance-hungrig, solange man native Tools (vor allem Compiler) einbinden kann. Deshalb wäre eine 68k/AOS3.x Version, die auch auf AOS4 und MOS läuft, absolut sinnvoll. Die würde sich auch am ehesten auf AROS portieren lassen. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
12.06.2012, 19:19 Uhr ZeroG Posts: 1487 Nutzer |
@Holger: Rigo ist aktiv und der Texteditor-Teil von Codebench wird bereits von jemand anderem geschrieben. Und das Problem mit deinem "klar noch eine IDE" ist das sowas erfahrungsgemäß lange bevor etwas halbwegs brauchbares herauskommt einschläft weil keiner mehr Bock hat. Außerdem wird das ganze dann währscheinlich mal wieder so ne halbgare "wir beschränken uns auf OS3.1 + MUI weil es überall laufen soll"-Geschichte... Da ist es doch viel besser auf was vorhandenem aufzubauen und wenigsten ein System verknüpftig auszureizen (oder sogar zu erweitern). [ - Antworten - Zitieren - Direktlink - ] |
|
12.06.2012, 19:34 Uhr Holger Posts: 8116 Nutzer |
Zitat:Welche tollen Features sind denn seit OS3.1 + MUI hinzugekommen, die für eine IDE zwingend notwendig wären? Außerdem ist die Trennung in Basisfunktionalität und Zuckerguss eines der Dinge, die man beherrschen sollte, bevor man sich an etwas so großes wie eine IDE macht. Zitat:Wenn das vorhandene denn von Anfang an darauf ausgelegt wurde, darauf aufbauen zu können. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
13.06.2012, 10:14 Uhr Reth Posts: 1858 Nutzer |
Hi nochmal, ich geh mal nur auf die Dinge ein, die mir für das Bounty wichtig wären: Ich würde das Thema gern für AOS3.x aufbringen, da ich derzeit versuche, für dieses zu entwickeln, da es noch die größte potentielle Nutzerbasis bietet. (Was ist eigentlich mit der Murks!IDE für AROS geworden? Scheint auch eingeschlafen zu sein?). Falls es zur Umsetzung kommt, würde dieses Tool dann ja auch unter MOS, AOS4 und ggf. AROS seinen Dienst verrichten. Die IDE sollte dann auch mit nem kompletten Paket aus Compiler, Debugger, Linker und was alles noch dazu gehört kommen. Das automatische Erzeugen von Makefiles (ggf. mit GUI-Unterstützung) soll möglich sein. Themen wie GUI-Builder, Team-Support (á la Repository-Anbindungen etc.) gibt es ja schon als Zusatztools in einigen Ausmaßen. Die würde ich erst einmal außen vor lassen (ggf. 3. Stufe). Die Plugin-Schnittstelle finde ich eine sehr gute Idee, wäre für mich aber von der Prio her ggf. auch erst in Stufe 2 möglich (aktuell fehlen mir persönlich vernünftige Möglichkeiten, mich mit einem Tool ganz auf mein Programm zu konzentieren, ohne dass ich ziemlichen Aufwand in das Erlernen von weiteren Dinge fürs Debuggen, Makefile-Erstellen, API-Nutzung usw. stecken und mich da in zig verschiedene Dokumentationen einlesen muss)! MUI würde ich ebenfalls als optional, ggf. für eine Stufe 2 ansehen. Wichtig wäre mir eine Unterstützung für die Entwicklung gegen das AOS-API, die es dem Entwickler so einfach wie möglich macht, sich auf das eigentliche Programm zu konzentrieren! @Holger: Welche (Mindest-)Anforderungen stellst Du Dir denn für die Projektverwaltung vor? Alle Sourcen, Header, Makefiles und Ressourcen zum Projekt zu laden und zu speichern? Habe mir auch schon überlegt, die Frage ggf. nochmal in entsprechenden englischen Foren zu stellen. Mal sehen. Ciao [ Dieser Beitrag wurde von Reth am 13.06.2012 um 10:45 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
13.06.2012, 12:31 Uhr Holger Posts: 8116 Nutzer |
Zitat:„Zusatztools“ ist aber diametral zu einer IDE. Das „I“ steht für integriert. Heißt ja nicht, dass die Software monolithisch sein muss. Nur, dass sie ggf. die existierende Software irgendwie integriert. Oder eine Möglichkeit zur Integration bietet (siehe unten). Zitat:Das ist aber essentiell. Nachträglich eingeführte Modularisierung ist immer mit Nachteilen verbunden. Außerdem schafft genau diese Schnittstelle die Möglichkeit, die anderen Anforderungen leichter umzusetzen: User xyz findet, dass Tool abc sollte integriert werden? → einfach über die öffentliche Schnittstelle einbinden. Zitat:Glaub mir, selbst wenn man dabei gar nichts erlernen muss, kann der Aufwand extrem hoch sein. Zitat:Was das GUI angeht, sollte man überhaupt keine Vorschriften machen. Eine IDE ist eine Menge Holz und der/die Entwickler sollen nehmen, was auch immer sie für richtig halten, am diesen Berg effizient abtragen zu können. Zitat:Ja, erstmal müssen alle zugehörigen Ressourcen identifiziert werden können, dann müssen alle zugehörigen Aufgaben unterstützt werden, d.h. Makefile erstellen für Projekte, die es brauchen, nicht nur um eine ausführbare Datei auszuspucken, sondern auch zur Dokumentationserstellung oder Backup (bzw. Synchronisation mit externem Repository). Bei mehreren Projekten müssen Abhängigkeiten eingebbar sein. Das wichtigste ist, dass alle Module/Plugins auf das aktuelle Projekt zugreifen können und selbst Informationen mit dem Projekt bzw. enthaltenen Ressourcen assoziieren können. Zitat:Gute Idee. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
13.06.2012, 13:25 Uhr OlafSch Posts: 91 Nutzer |
@Reth: noch eine kleine Anmerkung... ich arbeite an einer 68k Distribution von Aros die dann auch die Basis für die 68k Emulation in Aros (X86) sein wird. Infos: http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=35913&forum=47 Wenn die IDE also in meiner Distribution läuft wird sie mit hoher Wahrscheinlichkeit auch zukünftig in den Aros X86 Distributionen laufen. [ - Antworten - Zitieren - Direktlink - ] |
|
13.06.2012, 14:42 Uhr Reth Posts: 1858 Nutzer |
Was mir noch einfällt: Was wäre denn ein guter Anforderungspunkt im Sinne des Ergebnisses? Also sollte es GPL sein, auf Sourceforge gehostet oder dem Entwickler freigestellt sein, was damit passiert? Und: Die möglichen Spender für dieses Bounty sind ja primär "reduziert" auf interessierte Entwickler (allerdings auch auf "mitdenkende" User). Das schränkt den Umfang der Spendenquelle wohl deutlich ein (sollte aber kein Hinderungsgrund sein). [ - Antworten - Zitieren - Direktlink - ] |
|
13.06.2012, 17:30 Uhr Beeblebrox Posts: 723 Nutzer |
@Reth: Was den Editor angeht: Code completion hört sich prima an. Dazu gehört noch - go to definition of foo() - go to declaration of foo() - find all references to foo() - function parameterlist Was ich auch ganz toll finde ist wenn man einen Begriff Markiert, dann sollten alle gleichen Begriffe in dem Dokument auch markiert werden (wie z.B. bei CodeBlocks) Dann mag ich eine Funktionsliste der Datei im Editor, die in einem eigenen Fenster ist und nicht in einem Pulldown-Menü, wie z.B. bei PSPad. -- >>> bEeBlEbRoX <<< http://www.endlosstudent.de [ - Antworten - Zitieren - Direktlink - ] |
|
13.06.2012, 19:38 Uhr cha05e90 Posts: 157 Nutzer |
Hoffentlich keine Neuentwickling, das wäre dann die vierte (!) bzw. fast fünfte IDE. Wobei nur eine davon soweit fertig ist, daß man damit eigentlich schon ganz prima arbeiten kann (Codebench). - OS4.x-Prototyp der AROS Murks-IDE (schade, das Heinz da nicht weitergemacht hat, aber sein Hauptprojekt dürfte eher bei AROS liegen). - AVD von Jamie Krueger - schon durchaus funktional vorgeführt bei den AmiWest-Veranstaltungen, Status unbekannt. - Unbekannte IDE, unbekannter Autor: http://www.amigans.net/modules/myalbum/photo.php?lid=200 - Codebench - gibt's und geht und läuft, Weiterentwicklung findet statt, aber langsam... Ansonsten sei angemerkt, daß CB durchaus Plug-in-fähig ist, für Sprachen/Syntaxhighlighting (PHP, C/C++, Hollywood) als auch Versionskontrolle (CVS, SVN) gibt's die schon. -- SAM440ep-OS4.1|A2000/060-CGX4-OS3.9|A2000/040-P96-OS3.9|A1000-OS1.3|PegasosII/G4-OS4.1-MorphOS3.0 [ - Antworten - Zitieren - Direktlink - ] |
|
13.06.2012, 19:58 Uhr Reth Posts: 1858 Nutzer |
@cha05e90: Allerdings kenn ich (noch) keine mit integriertem graphischen Source Level Debugging. Hat das schon eine der Genannten? Und ist darunter eine für 68k? Bei CodeBench kann man auch auf den Debug-Button drücken und landet dann glaub in der Shell bei GDB (habs lang nicht mehr probiert). Zu Codebench: Das stimmt, die Plugins sind vorhanden (ist die Pluginschnittstelle eigentlich dokumentiert?). Bei AvD kam schon lange nix Neues mehr. Evtl. sollte der Autor die Aufmerksamkeit erhöhen (via Bounty o.ä.)? @Beeblebrox: Was genau meinst Du mit "- function parameterlist"? Die automatische Anzeige erkannter Paramterlisten bei Funktionen/Methoden im Rahmen der Codecompletion? Und was meinst Du mit "Funktionsliste der Datei im Editor"? Eine Outline-Funktionalität? Diese gibt es schon in Codebench. Was mir dazu noch einfällt ist das Anzeigen einer Callhierarchie! Das finde ich immer extrem hilfreich! [ - Antworten - Zitieren - Direktlink - ] |
|
14.06.2012, 15:11 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das ist Codebench mit nem anderen Skin. Zitat:Ist die Schnittstelle auch öffentlich? Zitat:Es ist das ausgereifteste Projekt auf dem Amiga, soweit ich das sehen kann. Aber ganz klar auf AmigaOS4.1+allerneueste Updates ausgerichtet. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
14.06.2012, 17:10 Uhr DaFreak Posts: 354 Nutzer |
Zitat: Sicher? Weil der Entwickler in den oben geposteten Link extra auf diese Frage einging. Obwohl "Code Editor" schon ziemlich ähnlich ausschaut. -- Sam440ep + AmigaOS4.1 im Morex 3677 Gehäuse [ - Antworten - Zitieren - Direktlink - ] |
|
14.06.2012, 18:53 Uhr Holger Posts: 8116 Nutzer |
Zitat:Nee, natürlich bin ich mir da gar nicht sicher. Ich hab die Beiträge beim ersten Anschauen auch nicht gesehen, waren außerhalb des sichtbaren Bildschirms. Aber vielleicht habe ich noch mehr übersehen: Wenn ich das jetzt richtig verstehe, hat da jemand angeblich heimlich eine völlig unbekannte IDE entwickelt und als einziges Zeichen der Existenz dieses Projekts einen Screenshot auf dieser Seite gepostet. Weiter schreibt er, man könne eine Beta haben, wenn man sich registriert, schreibt aber nirgendwo, wo. Und andere seiner Beiträge von 2009 weisen eher darauf hin, dass er selber Codebench benutzt und 2010 war eh sein letzter Login… -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
14.06.2012, 19:10 Uhr cha05e90 Posts: 157 Nutzer |
Zitat:So sehe ich das auch. Da ich selbst Codebench nutze und der ominöse "madmonkey" keine sichtbare Relation zu Simon Archer hat (der zu dem Zeitpunkt schon längst offen mit CodeBench unterwegs war..daher auch die Frage eines der User danach), scheint mir das tatsächlich was eigenes zu sein. Aber außer dem "mockup" kenne ich auch nix. Also bisher vermutlich Luftware. -- SAM440ep-OS4.1|A2000/060-CGX4-OS3.9|A2000/040-P96-OS3.9|A1000-OS1.3|PegasosII/G4-OS4.1-MorphOS3.0 [ - Antworten - Zitieren - Direktlink - ] |
|
14.06.2012, 20:37 Uhr Der_Wanderer Posts: 1229 Nutzer |
Eines der wichtigsten Features finde ich Auto-Kompilierung und Anzeige von Warnings/Errors im Source. D.h. das IDE kompliliert nach jeder signifikanten Änderung des Quelltextes automatisch neu und highlighted die Fehler, so wie eine Rechtschreibprüfung. Das spart enorm viel Zeit. Gleich nebenauf sind natürlich ein Source-Level Debugger mit Single Step Funktion und die Möglichkeit, die Inhalte von Variablen zu durchstöbern. Code Completion, vor allem bei Structs ist auch wichtig. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
14.06.2012, 21:31 Uhr Kaesebroetchen Posts: 643 Nutzer |
Zitat: Hi, weder Krysztof noch ich arbeiten derzeit daran, von daher kann man schon sagen das es eingeschlafen ist. Ab und zu wenn ich mal etwas Zeit überhabe, versuche ich zumindest ein rudimentäres Syntax Highlightling einzubauen. Immerhin habe ich dabei herausgefunden, das AROS' Texteditor.mcc fehlerhaft war. Thore war so freundlich das zu fixen und Mazze hat diesen Code inzwischen in AROS eingepflegt. Leider werde ich in auch nächster Zeit nicht viel Zeit haben daran weiter zu arbeiten. Wenn du aber sowieso eine IDE schreiben willst, wie wäre es dann wenn du Murks!IDE voranbringst ? Ist GPL, Sourcen hier: http://sourceforge.net/projects/murks-ide/ Bist herzlich eingeladen ! Das ganze ist in C++ für ZUNE/MUI geschrieben. Der Code ist immerhin in einem Zustand, daß man ihn ohne Änderungen für AmigaOS3, OS4, MorphOS, AROS-x86 und AROS-X86_64 kompilieren kann. Ausserdem kann sich Murks!IDE unter AROS-x86 selbst kompilieren. Ist also vielleicht nicht die schlechteste Grundlage für eine AmigaOS IDE. -- http://amidevcpp.amiga-world.de/ [ Dieser Beitrag wurde von Kaesebroetchen am 14.06.2012 um 21:33 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
14.06.2012, 22:56 Uhr Reth Posts: 1858 Nutzer |
@Der_Wanderer Das mit dem Sofortcompilieren hatte ich mir auch überlegt, finde ich extrem hilfreich. Wenn ich allerdings sehe, wie lange ein GCC compile meiner Sourcen auf nem Peg1 G4 1,25 GHz und 1GB RAM dauert, dann bin ich eher dagegen! Das Ganze soll nicht nur in Emulatoren (oder ggf. AROS) auf High-End PCs lauffähig sein! @Kaesebroetchen: Von selber schreiben war nie die Rede (dazu bin ich überhaupt nicht in der Lage, weder was Wissen, Können noch Zeit anbelangen). Ich spiele nur mit dem Gedanken ggf. eine entsprechende Bounty zu eröffnen. Mal nebenbei: Stelle ich mir, das "sich selbst compilieren" auch richtig vor? Nach meiner Meinung muss doch erst einmal ein Binary vorliegen, damit etwas ausgeführt wird (vorausgesetzt Compiler, Linker usw. sind nicht Bestandteil der IDE). Und das IDE-Binary kann dann seinen eigenen Source wieder compilieren. Oder wie ist das? (Sorry für die naive Anfängerfrage, ist auch noch OT.) [ Dieser Beitrag wurde von Reth am 14.06.2012 um 23:00 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
15.06.2012, 09:59 Uhr Kaesebroetchen Posts: 643 Nutzer |
Zitat: Murks!IDE wurde mit AmiDevCpp entwickelt und kompiliert. Es nutzt außerdem das gleiche textbasierte Projektformat. Man kann also mit Murks, das Murks-Projekt laden und kompilieren. Dazu nutzt MurksIDE den auf AROS vorhandenen gcc. -- http://amidevcpp.amiga-world.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
15.06.2012, 11:39 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das hängt mit der typischen Struktur von C-Projekten und -Compilern zusammen. Dabei spielt die CPU eine untergeordnete Rolle, der I/O Durchsatz und die Cache-Strategien sind wesentlich wichtiger. Um in einer IDE benutzbares automatisches Feedback anzubieten, musst Du dementsprechend Gehirnschmalz in eine Übersetzung im Hintergrund mit asynchroner Aktualisierung im Editor investieren. Am besten ergänzt dadurch, dass Du dem Compiler ein virtuelles Dateisystem unterschiebst, das 1. direkt auf den aktuellen Editor-Content für geöffnete Dateien zugreifen kann und 2. eine für den Compiler sinnvolle Cache-Strategie frei Haus liefert -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
15.06.2012, 13:26 Uhr Der_Wanderer Posts: 1229 Nutzer |
@Reth Du musst ja keinen Code generieren und linken, sondern nur das aktuelle Modul kompilieren. Das geht schnell. Ausserdem soll das natürlich asynchron laufen, mit niedriger Pri sodass der User im Editor nicht gestört wird. Ob ein Fehler nach 1 sek oder 10 sek angezeigt wird ist nicht so wichtig. Hauptsache man spart sich das manuelle anstoßen des Kompiler Vorgangs und das springen zu den Fehlern, was in der Regel mehrere Klicks und ein paar Sekunden Wartezeit kostet, oft nur um zu merken dass man ein ";" vergessen hat oder solche Kleinigkeiten. Wenn das automatisch im Hintergrund passiert spart man sich auf dauer massig Geklicke und Wartezeiten. Man kann auch Gedanklich 100% im Editor bleiben, und muss keinen "Context Switch" im Hirn durchführen, bei komplexen Aufgaben ist das nicht zu unterschätzen. Und weil ein Classic dafür zu langsam sein könnte ist ja wirklich kein Argument dagegen. Per Prefs kann man das ja abschaltbar machen. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
15.06.2012, 15:16 Uhr geit Posts: 332 [Ex-Mitglied] |
Da wird nix langsam. Darum haben wir doch Multitasking. Ich kompiliere immer manuell in der Shell direkt auf dem Ambientschirm und editiere derweil mit CubicIDE auf dem eigenen Bildschirm weiter. Das geht immer. Wenn man nicht gerade hunderte von Kilobyte in einer Textdatei kompiliert, bleibt das alles erträglich. Wenn der Editor sich am Compiler stört, dann ist der Rechner eindeutig zu langsam. Auf einem Pegasos2 1Ghz mache ich das immer. Meistens räume ich den Quellkode auf oder suche schon nach anderen Problemen, während der Compiler das Ganze im Hintergrund zusammenbaut. Jeder mini ist deutlich schneller als der Peg2. Mit den bisherigen Lösungen kann ich mich nicht so recht anfreunden. Wenn man im Editor den Vorgang startet, dann hat man endweder ein fettes Fenster im Bild, oder der Editor ist blockiert. Optimal für meinen Bedarf wäre das automatische Ausführen von Make seitens des Editors, wenn sich eine Datei ändert. So hat man zu jeder Zeit ein aktuelles Programm zum Testen auf der Platte. Das sollte natürlich ab/zuschaltbar sein. Es macht keinen Sinn, wenn man weiß das das Programm sowieso noch nicht lauffähig ist. So etwas setzt natürlich ein ordentliches Makefile mit Objekten und Abhängigkeiten vorraus. Geit [ - Antworten - Zitieren - Direktlink - ] |
|
16.07.2012, 22:57 Uhr Reth Posts: 1858 Nutzer |
@geit: Also in Codebench kann man Compilieren und dabei lustig weiter editieren. Man muss halt aufpassen, ob der aktuelle Source schon vom compile betroffen war, oder nicht, wenn man speichert. Denn in letzterem Fall wird ansonsten der neue Stand compiliert! [ - Antworten - Zitieren - Direktlink - ] |
|
16.07.2012, 23:01 Uhr Reth Posts: 1858 Nutzer |
Sorry für die lange Pause, hab zu viele Baustellen und auch beruflich und privat noch ne Menge zu tun (wie wohl die meisten). Auf Nachfrage bei Rigo habe ich erfahren, dass er und andere an Codebench weiter entwickeln. Leider ist die Plugin-Schnittstelle (noch) nicht offiziell. D.h., man kann (noch) nicht dafür entwickeln. Also ich fasse mal zusammen (in nem engl. Forum hab ich noch nicht gepostet):
So, ich hoffe, ich hab nix vergessen! Puh! Also wenn ich mir das so ansehe, scheint ein Eclipse-Port ein Kinderspiel dagegen zu sein (bitte nicht wörtlich nehmen!)! Also realistisch umsetzbar ist das wohl mit den aktuell bekannten Kapazitäten in den einzelnen "Lagern" wohl nicht. Daher plädiere ich für einen vernünftigen Schnitt in mehrere Stufen und bitte hiermit um Vorschläge! WYSIWYG GUI Editor hab ich mal ausgeschlossen, da es solche schon gibt. Außerdem: Auf welches GUI sollte der denn ausgerichtet sein? MUI hab ich ebenfalls mal ausgenommen, da zu spezifisch. [ - Antworten - Zitieren - Direktlink - ] |
|
24.07.2012, 11:34 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wer hat gesagt, dass es leicht sein wird?  Zitat:Wenn Du Deine Features abstrahierst und Abhängigkeiten der Features analysierst, kommst Du auf zwei grundlegende Komponenten: Wenn diese Komponenten allgemein genug entworfen sind, so dass beliebige Programmierer die beschriebenen Features darauf aufbauen können, kann es auch etwas werden. Als Beispiel: dem Editor kann es egal sein, ob die von einem Modul angeforderte Hervorhebung die weiteren Vorkommen der Variablen unter dem Cursor oder die aktuelle Zeile des im Debugger laufenden Programms ist. Beides muss aber gleichermaßen möglich sein. Andere hier nicht enthalten Punkte können über eigene Fenster der jeweiligen Module abgehandelt werden, wobei das Amiga-Feature der Public Screens schon ausreicht, um eine Zusammengehörigkeit im Sinne einer IDE zu demonstrieren. Natürlich könnte man wesentlich mehr tun, um Einheitlichkeit zu erreichen, aber alles, was in diese Richtung geht, erhöht auch die Anforderungen an den Programmierer eines Moduls/einer Erweiterung. Will man möglichst viele dazu bringen, etwas beizusteuern, muss man die Zwänge und Einstiegshürden minimieren. Ein Ansatz könnte so aussehen: Geringer geht die Einstiegshürde kaum. Module können selbst als DOS/Rexx Script implementiert werden und selbst Programme, die nichts von der IDE wissen, könnten zu Modulen werden, falls sie typischen Amiga-Konventionen (z.B. Unterstützung des Parameters PUBSCREEN) folgen. Und jeder, der in der Lage ist, ein Modul zu implementieren, ist auch in der Lage, es in die IDE zu integrieren (was bei anderen Systemen keine Selbstverständlichkeit ist). -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
| -1- 2 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > Eure Anforderungen an eine IDE für AmigaOS? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|