R-Basic-Programme ausführbar machen?

Hallo Jörg

Ich denke, ein modifiziertes R-Basic zu installieren wäre ein bisschen Overkill, da dieses dann in allen UniInstaller-Paketen der Programme dabei wäre, oder man muss dann jeweils zwei Pakete machen (einmal mit/einaml ohne).

Für Rainer sehe ich zwei Möglichkeiten:

1. Eine Runtime-Version, die der Benutzer einmal installiert
2. Das R-Basic-Programm wird kompiliert mit einem Loader verpackt, der dieses dann ausführt

Persönlich bin ich für die Runtime-Variante, obwohl R-Basic nach nativ GEOS sehr sexy wäre

Gruss
Andreas

Wenn ich Rainer richtig verstanden habe, soll es auf eine der beiden von Andreas beschriebenen Möglichkeiten hinauslaufen.

Bernd

Hallo,

es wird folgende Möglichkeiten geben:

1. Wie gehabt. Man verteilt den Quelltext, den der "Anwender" compilieren uns starten kann. Das ist aber eher was für Beispiele, Demos oder andere Dinge von "Programmieren unter sich".

2. Der Programmierer erzeugt eine "Runtime-Version" zum verteilen. Diese besteht z.B. aus einem Uni-Installer-Paket mit dem compilierten Programm, das in irgendeinem "versteckten" Ordner liegt (z.B. Userdata\r-basic\runtime" einem "Launcher" der im World liegt und den benötigen Runtime-Libraries. GGF kann man auch weitere benötigte Dateien hinzufügen. Die Runtime-Libraries machen aktuell ca 250 kB aus (unkomprimiert) und sollten nach meiner Meinung immer mit im Paket sein, damit das installierte Programm auf jeden Fall sofort lauffähig ist.

Der Nutzer klickt dann nur den Launcher im World an und das Programm verhält sich so wie ein SDK-Programm. R-BASIC selbst (d.h. der Editor und der "Compiler", die Handbücher, Beispiele etc.) müssen gar nicht auf dem System installiert sein. Damit das geht sind noch ein paar Vorarbeiten zu treffen, die ich Schritt für Schritt in den letzten Betas und den noch kommenden umsetze, ohne viel darüber zu reden. Seit Beta 0.8.1 sind z.B. die Runtime-Libraries vom Compiler getrennt.

Wie ich das "Anlegen der Runtime-Version" aber genau organisiere und auch die Benutzerführung dabei ist mir noch nicht ganz klar. Z.B. könnte man in der Runtime-Version den Quelltext entfernen ...

Kommentare? Immer her damit!

Gruß
Rainer

@Bolle:
1. So richtig erkenne ich den Unterschied zwischen deinen beiden Varianten nicht.
2. "Nativ" GEOS wir definitv nicht kommen, der R-BASIC "Compiler" übersetzte den BASIC Quellcode "nur" in eine Token-Folge, die von den Runtime-Libraries interpretiert wird.
@Jörg:
Der Uni-Installer ist schon seit der letzten Version dahingehend "leicht" modifiziert, dass er einen Versionscheck für R-BASIC Programme ausführen kann, die ja aus Sicht des Systems keine Programme sondern Dokumente sind. Das ist uach eine der "stillen" Vorarbeiten, die ich oben erwähnte.

Hallo Rainer

1. Variante: RunTime Environment (RTE) wird einmal im System installiert

+ Einfache Installation
- Komplexer mit verschiedenen Versionen (vor allem, wenn Source nicht mehr im Programm)

2. Interpreter ("~Loader") in der Programmdatei integriert

+ Keine fixe RTE nötig
+ Programm kann einfach gestartet werden, hat richtige Version immer dabei
- Grosse Programme

Gruss
Andreas

Zitat

Original von Rainer: Der Programmierer erzeugt eine "Runtime-Version" zum verteilen. Diese besteht z.B. aus einem Uni-Installer-Paket mit dem compilierten Programm, das in irgendeinem "versteckten" Ordner liegt (z.B. Userdata\r-basic\runtime" einem "Launcher" der im World liegt und den benötigen Runtime-Libraries. GGF kann man auch weitere benötigte Dateien hinzufügen. Die Runtime-Libraries machen aktuell ca 250 kB aus (unkomprimiert) und sollten nach meiner Meinung immer mit im Paket sein, damit das installierte Programm auf jeden Fall sofort lauffähig ist.

Klingt für mich grundsätzlich nach einer sehr benutzerfreundlichen Variante. Die Dateigröße sollte heutzutage kein Problem mehr darstellen, selbst mit einem sehr langsamen Internetanschluss dürfte solch ein Installer-Paket zumindest innerhalb weniger Minuten geladen sein.

Fest vorgeschriebene Ordner für die Programme (und auch für Libraries) sind richtig, damit nicht jeder Programmierer sein eigenes Süppchen kocht und Dateien im ganzen System verteilt. Der Installer würde die benötigten Libraries nur installieren, wenn sie noch nicht im vorgeschriebenen Ordner vorhanden sind, so schwillt das System nicht durch diverse Runtimes an.

Kann der Installer eigentlich selbständig gezippte Inhalte entpacken? Dadurch könnten die Installer-Pakete noch etwas kleiner ausfallen.

Zitat

Der Nutzer klickt dann nur den Launcher im World an und das Programm verhält sich so wie ein SDK-Programm. R-BASIC selbst (d.h. der Editor und der "Compiler", die Handbücher, Beispiele etc.) müssen gar nicht auf dem System installiert sein.

Sehr gut

Bernd

Zitat

Original von Rainer
Hallo...
...dass er einen Versionscheck für R-BASIC Programme ausführen kann, die ja aus Sicht des Systems keine Programme sondern Dokumente sind.

Deswegen also kann ich die R-BASIC-Programme nicht über Express-Menü->Programme finden?

Hallo,

Zitat

Deswegen also kann ich die R-BASIC-Programme nicht über Express-Menü->Programme finden?

Genau. Der Laucher aber ist ein ectes GEOS-Programm, trägt sich also in Expressmenu ein. Geplant ist, dass ich dort nur den Dateinamen "patche". Ob man was bezüglich der Icons machen kann weiss ich noch nicht. Vor allem habe ich noch keine Idee, wie ich das dem BASIC-Programmierer präsentieren soll....

Zitat

Kann der Installer eigentlich selbständig gezippte Inhalte entpacken?

Leider nein. Wenn man aber das Installer-Archiv zippt macht das keinen Unterschied - eher wird das gezippte Archiv (ohne Zips als Inhalt) kleiner.

Zitat

Fest vorgeschriebene Ordner für die Programme (und auch für Libraries) sind richtig, damit nicht jeder Programmierer sein eigenes Süppchen kocht und Dateien im ganzen System verteilt.

Ja. so sehe ich das auch. Unterordner sind aber evt. sinnvoll (userdata\r-basic\runtime\bernd) - das verringert die Chance von Namenskonflikten.

Zitat

Variante: RunTime Environment (RTE) wird einmal im System installiert

Klingt sehr verlockend in meinen Ohren. Aber ich erinnere mich noch mit Grausen an die vielen Visual-Basic-Programme, die ich nie zum Laufen bekommen habe, weil ich die falsche Version der VBRUN100.DLL installiert hatte ...

Gruß
Rainer