atari-home.de - Foren
Software => Software (16-/32-Bit) => Thema gestartet von: gh-baden am Di 14.01.2020, 18:51:24
-
Hallo,
die Sourcen von Texel kann man jetzt unter
https://github.com/thmuch/texel
ausfassen :-) „Gepriesen sei der Thomas.“
-
:D
Ich wünschte, mehr SW-Autoren gingen so vor.
-
Im Moment wird man das wahrscheinlich nicht mit PurePascal bauen können – Texel ist zu groß für den normalen PP-Compiler. Aber es gab einen Patch für mehr, viel mehr Stack, ich suche den mal raus.
-
Abgesehen vom Stack schreibt er auch was über Virtual memory tables.
BTW das repo beinhaltet auch ältere Versionen, also ist sogar eine gewisse Historie verfügbar.
-
Ich wünschte, mehr SW-Autoren gingen so vor.
Es wurde doch schon eine Menge Software als Open Source freigegeben? Fehlt eigentlich nur noch eine Textverarbeitung für ein "Open Office".
-
Ich wünschte, mehr SW-Autoren gingen so vor.
Es wurde doch schon eine Menge Software als Open Source freigegeben?
Beispielsweise hätte ich gerne NVDI als Open-Source gesehen, denn dafür gibt's noch keine echte freie Alternative. Aber das wird nie passieren. Oder Big-DOS. (OK, letzteres ist unnötig, wenn man EmuTOS einsetzt.)
-
Ja NVDI ist sehr wichtig, gehört ja fast schon zum System ...
-
Hallo,
die Sourcen von Texel kann man jetzt unter
https://github.com/thmuch/texel
ausfassen :-) „Gepriesen sei der Thomas.“
Das sieht ja immer noch modern aus...
Vielen Dank Thomas
-
Beispielsweise hätte ich gerne NVDI als Open-Source gesehen, denn dafür gibt's noch keine echte freie Alternative. Aber das wird nie passieren. Oder Big-DOS. (OK, letzteres ist unnötig, wenn man EmuTOS einsetzt.)
Da wird dir niemand widersprechen, NVDI ist "the Big One". Ohne Vektorfonts sieht auch Texel altmodischer aus :(
Generell ist aber doch einiges freigegeben worden, auch größere Programme. Geneva, Boxkite, faceVALUE und die Erweiterungen des Milan-TOS wären auf meiner Wunschliste.
-
Beispielsweise hätte ich gerne NVDI als Open-Source gesehen, denn dafür gibt's noch keine echte freie Alternative. Aber das wird nie passieren.
Nun, die Behnes haben wohl halt nicht alle Rechte am Code (Font-Scaler). Und vielleicht haben sie keine Lust, das auseinanderzudröseln. Jetzt könnte man natürlich nach NVDI 2.5 fragen, das letzte ohne Vektorfonts, aber das würde den Nutzwert halt auch deutlich einschränken heutzutage. Und Lust haben & Zeit nehmen müßten sie sich immer noch.
-
Generell ist aber doch einiges freigegeben worden, auch größere Programme. Geneva, Boxkite, faceVALUE und die Erweiterungen des Milan-TOS wären auf meiner Wunschliste.
- Freedom
- IdeaList
- Dynabuster+
- X-Act
- Arabesque Pro
- MegaPaint
- That’s Write
- Adimens + AdiTalk
-
Den Christoph mal gefragt? Von deinen acht Wunschprogrammen scheint Idealist noch am realistischsten.
-
Beispielsweise hätte ich gerne NVDI als Open-Source gesehen, denn dafür gibt's noch keine echte freie Alternative. Aber das wird nie passieren. Oder Big-DOS. (OK, letzteres ist unnötig, wenn man EmuTOS einsetzt.)
Da wird dir niemand widersprechen, NVDI ist "the Big One". Ohne Vektorfonts sieht auch Texel altmodischer aus :(
Nicht zu vergessen dient NVDI ET4000 oder NVDI Matgraph CXX oder auch NVDI Matgraph TC auch als Treiber für diverse Grafikkarten ...
-
Den Christoph mal gefragt? Von deinen acht Wunschprogrammen scheint Idealist noch am realistischsten.
Ja, klar. Er überlegt noch :-) Ich bleibe dran.
-
meine Nr. 1 für Open Source eindeutig Calamus, und da vor allem erstmal das Dateiformat...
-
Beispielsweise hätte ich gerne NVDI als Open-Source gesehen, denn dafür gibt's noch keine echte freie Alternative. Aber das wird nie passieren.
Nun, die Behnes haben wohl halt nicht alle Rechte am Code (Font-Scaler). Und vielleicht haben sie keine Lust, das auseinanderzudröseln. Jetzt könnte man natürlich nach NVDI 2.5 fragen, das letzte ohne Vektorfonts, aber das würde den Nutzwert halt auch deutlich einschränken heutzutage. Und Lust haben & Zeit nehmen müßten sie sich immer noch.
NVDI 2.5 als Grundumfang von EmuTOS wäre schon mal deutlich besser wie nichts.
-
Im Moment wird man das wahrscheinlich nicht mit PurePascal bauen können – Texel ist zu groß für den normalen PP-Compiler.
Wie genau äußert sich das? Ich habe es mal mit der PP-Version vom 4.5.1994 erstellt. Damit meine ich nicht die Standalone Version.
Ich habe auch die letzten Quellen von Texel genutzt, also die 2.30. Auf github fehlen noch die Dateien "TEXEL.DAT" und "TEXEL.FRM". Kann man aber von einem Original rüberziehen.
-
Wie genau äußert sich das? Ich habe es mal mit der PP-Version vom 4.5.1994 erstellt. Damit meine ich nicht die Standalone Version.
Ich habe auch die letzten Quellen von Texel genutzt, also die 2.30. Auf github fehlen noch die Dateien "TEXEL.DAT" und "TEXEL.FRM". Kann man aber von einem Original rüberziehen.
IIRC geht da der Stack aus, irgendwo, zuviele Objekte unter gewissen Umständen. Das ist aber echt nebliges Terrain, diese Erinnerungen …
-
Wie genau äußert sich das? Ich habe es mal mit der PP-Version vom 4.5.1994 erstellt. Damit meine ich nicht die Standalone Version.
Habs jetzt auch nochmal versucht, mit der PP-Version die im englischen Forum zu finden ist (Versionsnummer sehe ich da keine, aber Datum ist vom 31. Jul 1995)
Kommt mir aber irgendwie so vor, als ob sowohl PP als auch Texel etwas instabil sind. Bei einigen der Beispielen von ObjectGEM kracht der Compiler regelmässig weg (und das liegt vermutlich nicht an irgendwelchen virtuellen Tabellen). Texel selbst schmiert mir immer mal wieder mit einem Index-Fehler ab. Vlt. sollte man erstmal auf die Version 2.2 zurück gehen, wenn man sich das genauer anschaut.
Auffallend auch, daß sowohl bei ObjectGEM als auch bei Texel Optimierungen ausgeschaltet sind, dementsprechend grottig ist auch der erzeugte Code.
Auf github fehlen noch die Dateien "TEXEL.DAT" und "TEXEL.FRM". Kann man aber von einem Original rüberziehen.
Ja, hab ich auch schon gemerkt ;) Vom original rüberziehen ist allerdings nicht so trivial, wenn man keinen Key hat, der Key-Generator der jetzt bei den Sourcen dabei ist, ist nur für Texel.app, aber nicht für das Setup. Ausserdem sollte man die Routinen mal entfernen, sonst muss man nach jedem neu übersetzen den erstmal drüber laufen lassen...
IMHO fehlen auch noch Resource-Dateien. Da ist zwar eine englische Resource im Ordner, allerdings ist die komplett in Deutsch. Dito für die eingebauten Strings (stehen in lang/english.inc). Französisch scheint wohl auch vorgesehen zu sein, fehlt aber gänzlich.
-
Sieht irgendwie so aus als ob PP Probleme mit den grossen Quell-Dateien hat. Wann immer ich txmain.pas oder owindows.pas auf habe (beide jeweils ~500K) und versuche zu übersetzen, schmiert er mir weg. Schliesse ich die Fenster vorher, geht es. Ist aber ziemlich ätzend, weil man dann ausgerechnet in den grossen Dateien erstmal die Stellen wiederfinden muss.
-
Habs jetzt auch nochmal versucht, mit der PP-Version die im englischen Forum zu finden ist (Versionsnummer sehe ich da keine, aber Datum ist vom 31. Jul 1995)
Da wurde nie wirklich was vergeben. Maximal im einer Liesmichdatei steht was drin. Letzte Versionnummer was ich mal gelesen habe ist die 1.1m. Keine Ahnung was für ein Datum die hat.
Ja, hab ich auch schon gemerkt ;) Vom original rüberziehen ist allerdings nicht so trivial, wenn man keinen Key hat,
Taja, habe selbstverständilich Texel mal käuflich erworben.
der Key-Generator der jetzt bei den Sourcen dabei ist, ist nur für Texel.app, aber nicht für das Setup. Ausserdem sollte man die Routinen mal entfernen, sonst muss man nach jedem neu übersetzen den erstmal drüber laufen lassen...
Geht einfach: In der Datei TXPROCS.PAS die Funktion "KeyCorrect" so ändern, das sie imm er eins zurückgibt.
Sieht irgendwie so aus als ob PP Probleme mit den grossen Quell-Dateien hat. Wann immer ich txmain.pas oder owindows.pas auf habe (beide jeweils ~500K) und versuche zu übersetzen, schmiert er mir weg.
Kann ich hier nicht bestätigen. Beide Dateien offen und das "Make All" läuft ohne Problme durch. Entweder ist Deiner PP zu neu oder es ist Emulator abhänig. Zum Beispiel ging PP anfangs nicht unter MagiCMac.
Vielleicht kann "gh-baden" ja nochmal schauen ob er einen Patch für PP findet.
-
War die einzige version die ich auf schnelle gefunden habe. Vorher hatte ich eine deutlich ältere (keine Ahnung mehr wo die her war), damit sind meine ersten Versuche klägiich gescheitert.
Entweder ist Deiner PP zu neu oder es ist Emulator abhänig.
Kann ich nicht gänzlich ausschliessen, aber es passiert halt immer nur bei den grossen Dateien.
Zum Beispiel ging PP anfangs nicht unter MagiCMac.
Emulator in dem Fall ist STonX. Meine ARAnyM Umgebung startet normalerweise Mint/XaAES, da verweigert sich PP komplett. Vlt sollte ich es mal mit MagiC versuchen, ist vermutlich die Umgebung die auch Thomas verwendet hat.
Geht einfach: In der Datei TXPROCS.PAS die Funktion "KeyCorrect" so ändern, das sie imm er eins zurückgibt.
Ja, schon klar. Aber bei einer opensource-Version sollte man solch überflüssigen Kram mal entfernen. DemoNervAlert etc. gehört auch dazu.
Hab mir übrigens mal die Änderungen von 2.20 nach 2.30 angeschaut. Abgesehen von verschobenen Resource-Dateien, hinzugefügten Readme's etc. hat sich an den Sourcen selber da eigentlich fast nichts geändert.
-
Hab jetzt PP mal unter MagiC getestet (ARAnyM+MagiC+fVDI). Abstürze gibs da keine, aber so richtig gut funktioniert es da auch nicht. Zum einen hinterlässt der Mauszeiger Spuren auf dem Bildschirm (ähnlich wie PureC, wenn man es unter MInT startet). Die Slider der Fenster werden entweder gar nicht oder transparent gezeichnet, sind auf jeden Fall kaum zu bedienen. Und wenn man das Programm aus PP heraus startet, findet es seine Resource-Datei nicht (typisches Problem, das auch bei Pure-C manchmal auftritt, weil die Shell das Programm nur per Pexec startet, ein anschliessender shel_find() dann aber die Werte vom Programmstart von PP selber bekommt). Wenn sich das Programm beendet, hängt scheinbar alles, und Bildschirm ist weiss.
Irgendwie finde ich diese selbst-gestrickte Oberfläche von PP ziemlichen Müll. Ich frage mich echt wie Thomas das entwickelt hat, ohne ein Multi-Tasking System (welches auch immer) sind die ganzen Protokolle die Texel unterstützt für die Katz. Insbesondere das Einbinden von Objekten über OLGA funktioniert dann nicht.
Update: die Abstürze bei den grossen Dateien sind ein hausgemachtes Problem von SingleTOS, und haben mit dem Emulator nichts zu tun. Scheinbar macht PP sehr viele Malloc() Aufrufe, ohne den Speicher gross selber zu verwalten, wodurch irgendwann der GEMDOS-Pool überläuft. Abhilfe: FOLDR100 oÄ. benutzen.
-
Zum Beispiel ging PP anfangs nicht unter MagiCMac.
Emulator in dem Fall ist STonX. Meine ARAnyM Umgebung startet normalerweise Mint/XaAES, da verweigert sich PP komplett. Vlt sollte ich es mal mit MagiC versuchen, ist vermutlich die Umgebung die auch Thomas verwendet hat.
Texel wurde erst auf einem Falcon mit TOS 4.04 entwickelt, dann auf MagiC, dann auf MagiCMac.
Ja, schon klar. Aber bei einer opensource-Version sollte man solch überflüssigen Kram mal entfernen. DemoNervAlert etc. gehört auch dazu.
Wer ist "man"? Meinst du jetzt Thomas? Fände ich jetzt schon eher Jammern auf hohem Niveau ...
-
Vielleicht kann "gh-baden" ja nochmal schauen ob er einen Patch für PP findet.
Ich habe ziemlich sicher die gepatchte PP-Version und würde halt ein bindiff daraus machen. Dauert aber noch ein wenig.
-
Wer ist "man"? Meinst du jetzt Thomas?
Nein, natürlich nicht. "man" wäre derjenige, der da evtl. die weitere Pflege übernimmt. Und nein, ich werde das nicht ernsthaft übernehmen, höchstens mit Ratschlägen zur Seite stehen ;)
würde halt ein bindiff daraus machen
Bindiff funktioniert natürlich nur wenn man exakt die gleiche PP version hat wie du. Was vermutlich schon daran scheitert, daß die Serien-Nummer ins Programm eingepatcht wird. Ausserdem scheint es doch diverse verschiedene Versionen zu geben.
Wie gesagt, abgesehen von den oben beschriebenen Problemen lässt sich Texel mit der Version aus dem englischen Forum übersetzen. Entweder ist das schon eine gepatchte Version, oder aber eine neuere wo das Limit angehoben wurde. Lediglich bei einigen der Beispiel-Programmen aus dem ObjectGEM Verzeichnis (BEISPL09 - BEISPL12) schmiert er mir immer noch ab.
-
Ja, schon klar. Aber bei einer opensource-Version sollte man solch überflüssigen Kram mal entfernen. DemoNervAlert etc. gehört auch dazu.
Für mich war jetzt erstmal wichtig das es zu kompilieren ist. Ich hatte mal vor Ewigkeiten ein Programm zu übersetzen versucht und bin gescheitert. Zum Glück konnte ich den Programmierer noch kontaktieren und alles nötige bekommen. Wobei er ziemlich angefressen war, weil Ihn jemand gebeten hatte die Quellen zuveröffentlichen und dann nichts mehr kam.
Da es geht kann darauf aufsetzt werden.
Ich habe ziemlich sicher die gepatchte PP-Version und würde halt ein bindiff daraus machen. Dauert aber noch ein wenig.
Danke.