Quelle für CF Lib (möglichst Source)

[ST-Oldie]

Hallo,

bei einem kleinen Gespräch über erweiterte GEM Libs bin ich auf die CF-Lib gestoßen worden. Nur geht der Link auf atariuptodate ins Leere. Gibt es denn noch in den Untiefen des Internets eine Möglichkeit zum Download oder ist die Lib zusamen mit dem Interesse des Autors gestorben?

Tschüß
Michael

[mfro]

Hallo,

bei einem kleinen Gespräch über erweiterte GEM Libs bin ich auf die CF-Lib gestoßen worden. Nur geht der Link auf atariuptodate ins Leere. Gibt es denn noch in den Untiefen des Internets eine Möglichkeit zum Download oder ist die Lib zusamen mit dem Interesse des Autors gestorben?

Tschüß
Michael

Das CVS-Repository der CF-Lib ist auf sparemint.org zu finden (http://sparemint.org/cgi-bin/cvsweb/), gemeinsam mit der MiNTlib, den FreeMiNT-Quellen und noch ein paar interessanten Sachen.

[HelmutK]

Oder fertig hier:

http://www.freemint.org/

[m0n0]

Ich habe die GEMLIB + CFLIB mal mit AHCC kompiliert.

Leider sind die Programme nicht stabil.

Kann an AHCC liegen, oder meiner XAAES Installation (eine mittlerweile betagte Beta Version), oder dass sich evtl. doch irgendwo ein Fehler in meinem Code befindet.

Das ist ziemlich schade, naja, nur solange man nicht weiss wo das Problem liegt.

Ich schreibe das deshalb, weil die CFLIB auf der GEMLIB aufbaut... Da musst Du mit PureC dann auch eine ältere Version der GEMLIB kompilieren (oder als lib haben, aber davon sehe ich ab, weil das dann nicht Firebee freundlich ist - wenn man jedoch die Sourcen hat, kann man mit AHCC ja einfach auf Coldfire umschalten ) um die CFLIB zu kompilieren.

Mich würden dann Deine Ergebnisse in Richtung Stabilität interessieren. Bei mir reichte schon ein einfacher Aufruf von Funktionen wie init_app (oder wie die CFLIB Funktion heisst...) damit Funktionen wie Fopen / Fread / fopen / fread Probleme bereiteten (zumindest beim öffnen und lesen von /dev/random).

Hier sind Links zu den Paketen die u.a. für AHCC gepatch sind (inkl. der Binärversionen):

https://freeshell.de/~monokrom/geeklog/downloads/index.php?id=cflib_ahcc_rc1

https://freeshell.de/~monokrom/geeklog/downloads/index.php?id=gemlib_ahcc_latest

[ST-Oldie]

Hallo,

danke für die Infos an alle.

Ich habe die GEMLIB + CFLIB mal mit AHCC kompiliert.

Leider sind die Programme nicht stabil.

Kann an AHCC liegen, oder meiner XAAES Installation (eine mittlerweile betagte Beta Version), oder dass sich evtl. doch irgendwo ein Fehler in meinem Code befindet.

Das ist ziemlich schade, naja, nur solange man nicht weiss wo das Problem liegt.

Ich schreibe das deshalb, weil die CFLIB auf der GEMLIB aufbaut... Da musst Du mit PureC dann auch eine ältere Version der GEMLIB kompilieren (oder als lib haben, aber davon sehe ich ab, weil das dann nicht Firebee freundlich ist - wenn man jedoch die Sourcen hat, kann man mit AHCC ja einfach auf Coldfire umschalten ) um die CFLIB zu kompilieren.

Ups, du überfährst mich etwas. Ich wollte im ersten Schritt nur mal auf die Lib in meinen Programmierseiten verlinken. Und wenn ich Langeweile habe, mal überlegen, ob ich für meine Homepage und Matthias einen Artikel schreibe. Ich hab hier noch Turbo C und einen TT bzw. STem (oder Aranym). Mit Coldfire und Firebee hab ich nix am Hut. Aber immerhin auch MinT, nur auch eine nicht ganz aktuelle Version mit MultiTOS, n.aes, XAAES oder MyAES (wählbar). Vom Uppgrade hat mich zum einen "die eigne Faulheit", läuft doch, abgehalten. Und dann aber auch die Leute, die an MinT arbeiten. Denn es gibt keinen vernünftigen Weg für einen Upgrade des gesamten MinT Systems mit binarys und UNIX like Filesystem. Erst tarballs (mint98), dann rpm's (sparemint), dann tarballs (gentoo). dann xxx? Soll ich jetzt jedesmal meine installation platt machen? Das ist Murks. auch wenn man froh über jeden sein muß, der da Arbeit reinsteckt. Als Anwender brauche ich aber einen Möglichkeit, Upgrades einzuspielen, bei dem ich mein System nicht platt machen muß und am Ende ein lauffähiges System habe. Also sollten diejenigen, die eine aktuelle Distri bereitstellen, in den sauren Apfel beißen und mit dem Paketformat des Vorgängers weitermachen statt mit den eigenen Vorlieben. Also rpm der SpareMinT. Alles andere hält Leute mit alten Installation von Upgrades ab.

GEMLIB ist doch eine "Standard" GEM Lib, die sich an die API der Geiß Brüder anlehnt?

Daß die Programme nicht stabil sind, ist ärgerlich. Aber das sollte sich ja finden lassen. Der Zusammenhang mit fopen/fread, speziell für /dev/random ist aber erstmal merkwürdig. Das klingt auf den erstren Blick eigentlich danach, als werden Informationen im Speicher überschrieben. also z.B. eine Pointerfehler o.ä.

Mich würden dann Deine Ergebnisse in Richtung Stabilität interessieren. Bei mir reichte schon ein einfacher Aufruf von Funktionen wie init_app (oder wie die CFLIB Funktion heisst...) damit Funktionen wie Fopen / Fread / fopen / fread Probleme bereiteten (zumindest beim öffnen und lesen von /dev/random).

Unter welchem System? Ich dachte, die CFLib kann ich auch unter TOS einsetzen. Wenn du Zugriff auf /dev/random machst, dann muß es ja ein MinT System sein. Ich hätte wahrscheinlich einfach unter TOS mal etwas versucht.

Wenn du spezielle Wünsche hast, kann ich aber auch mal ein paar Tests machen.

Tschüß
Michael

[mfro]

Also rpm der SpareMinT. Alles andere hält Leute mit alten Installation von Upgrades ab.

Das funktioniert leider nicht. RPM läuft auf dem ST nur in einer uralten Version, neuere sind nicht ohne weiteres portierbar.

GEMLIB ist doch eine "Standard" GEM Lib, die sich an die API der Geiß Brüder anlehnt?

Die GEM libs, die hier gemeint sind, haben mit dem, was die Geiß-Brüder damals gemacht haben, nichts zu tun. Gemeint sind hier die "Standard" AES- und VDI-Libraries. Die "Geiß"-APIs gibt's meiner Kenntnis nach nur auf den Disketten zu den Büchern vom Huth-Verlag oder man schnibbelt sich aus den Quellen von Phoenix raus, was man braucht.

Daß die Programme nicht stabil sind, ist ärgerlich. Aber das sollte sich ja finden lassen. Der Zusammenhang mit fopen/fread, speziell für /dev/random ist aber erstmal merkwürdig. Das klingt auf den erstren Blick eigentlich danach, als werden Informationen im Speicher überschrieben. also z.B. eine Pointerfehler o.ä.

Die Programme sind stabil, so man die gcc-Toolchain benutzt, für die sie gemacht sind. Mit AHCC hab' ich nie was gemacht, da mag es Probleme geben, aber QED z.B. läuft mit der CFLIB und gcc kompiliert einwandfrei.

[ST-Oldie]

Hi,

Das funktioniert leider nicht. RPM läuft auf dem ST nur in einer uralten Version, neuere sind nicht ohne weiteres portierbar.

Schade, aber wäre nicht wirklich ein Hinderungsgrund.

Die GEM libs, die hier gemeint sind, haben mit dem, was die Geiß-Brüder damals gemacht haben, nichts zu tun. Gemeint sind hier die "Standard" AES- und VDI-Libraries.

Moment. Die Geiß-Libs sind die "Standard" AES und VDI-Libraries. Die hatten das damals mit Atari und DRI standardisiert. Und meine Turbo C GEM Lib und auch meine (alte) gcc GEM Lib folgen (bis auf ganz wenig Unterschiede) diesem Standard. Wenn jetzt eine GEM Lib das anders macht, dann ist sie keine Standard GEM Lib mehr.

Die Programme sind stabil, so man die gcc-Toolchain benutzt, für die sie gemacht sind. Mit AHCC hab' ich nie was gemacht, da mag es Probleme geben, aber QED z.B. läuft mit der CFLIB und gcc kompiliert einwandfrei.

Damit wäre ja die Frage von M0n0 beantwortet. War die CF Lib denn von Anfang an für den gcc vorgesehen? Ich dachte, die wäre immerhin so alt, daß sie wahrscheinlich zuerst für einen anderen Compiler, z.B. Pure C, entwickelt wurde.

Tschüß
Michael

[mfro]

Hi,

Das funktioniert leider nicht. RPM läuft auf dem ST nur in einer uralten Version, neuere sind nicht ohne weiteres portierbar.

Schade, aber wäre nicht wirklich ein Hinderungsgrund.

Na dann. Auf geht's!

Die GEM libs, die hier gemeint sind, haben mit dem, was die Geiß-Brüder damals gemacht haben, nichts zu tun. Gemeint sind hier die "Standard" AES- und VDI-Libraries.

Moment. Die Geiß-Libs sind die "Standard" AES und VDI-Libraries. Die hatten das damals mit Atari und DRI standardisiert. Und meine Turbo C GEM Lib und auch meine (alte) gcc GEM Lib folgen (bis auf ganz wenig Unterschiede) diesem Standard. Wenn jetzt eine GEM Lib das anders macht, dann ist sie keine Standard GEM Lib mehr.

Da weißt Du mehr als ich (was ich aber überhaupt nicht in Frage stellen will). Ich kenne von den Geiß-Brüdern lediglich die beiden Bücher über strukturierte GEM-Programmierung und natürlich Phoenix. Ich war immer der Überzeugung, daß die GEM APIs schon lange vorher durch DR festgeschrieben wurden.

Die Programme sind stabil, so man die gcc-Toolchain benutzt, für die sie gemacht sind. Mit AHCC hab' ich nie was gemacht, da mag es Probleme geben, aber QED z.B. läuft mit der CFLIB und gcc kompiliert einwandfrei.

Damit wäre ja die Frage von M0n0 beantwortet. War die CF Lib denn von Anfang an für den gcc vorgesehen? Ich dachte, die wäre immerhin so alt, daß sie wahrscheinlich zuerst für einen anderen Compiler, z.B. Pure C, entwickelt wurde.

Das stimmt wohl - QED wurde zunächst mit Pure-C programmiert.

[MJaap]

Die CF-Lib war von Anfang an sowohl für PureC als auch GnuC konzipiert. Ich habe sie selbst mit PureC zur Modernisierung von spareTIME verwendet.

[ST-Oldie]

Hi,

Na dann. Auf geht's!

Na da würde ich mir ja die komplette Verwaltung einer Mintdistribution ans Bein binden. Ganz so viel Zeit stecke ich im Moment doch nicht mehr in Atari.

Ich kann mir im Moment eher vorstellen, mal wieder an meiner Homepage zu arbeiten und Doku zum Thema Atari zu erweitern bzw. vervollständigen. Da ist ja der Teil zum Programmieren, wo ich eine Übersicht über diverse Protokolel wie z.B. Olga, BubbleHelp, ... habe. Das könnte vielleicht eine Aktualisierung vertragen, wenn es mittlerweile tote Links gibt. Ich hab noch einen angefangenen GEM Programmier Kurs den ich fertigstellen könnte (nur bis TOS 3.xx). Neueres (ab Falcon, Mint, ...) ist noch gar nicht angesprochen. Evtl. fällt dabei auch etwas für Agelika's FireBee SDK ab. Und einfach um Leute einzuladen (wieder) mit Atari zu spielen ein paar einfache Anleitungen zum Einrichten, Bedienen, Instalaltion eines Emulators, ... Eine Übersicht über TOS Versionen, Hardware und Emulatoren ist ja schon da. Und meist auf vorhandene Seiten verwiesen.

Einfach deshalb, damit das nicht in Vergessenheit gerät. Und beim Programmierteil auch um selbst einen Überblick zu behalten.

Da weißt Du mehr als ich (was ich aber überhaupt nicht in Frage stellen will). Ich kenne von den Geiß-Brüdern lediglich die beiden Bücher über strukturierte GEM-Programmierung und natürlich Phoenix. Ich war immer der Überzeugung, daß die GEM APIs schon lange vorher durch DR festgeschrieben wurden.

Das Buch "Vom Anfänger zum GEM Profi" verweist auf diese Arbeit. Ich hab aber aus dieser Zeit auch den Eindruck bekommen, daß sowieso jede Atari C Entwicklungsumgebung als Namen der C-Bindings die offiziellen Namen der GEM Funktionen verwendet. Auch die defines für Konstanten verwenden fast überall die gleichen Namen. Mit der Datei portab.h wurden dann Fehler oder Unterschiede ausgeglichen und Integer Datentypen einer definierten Länge definiert (WORD, ...). Außerdem wurde dadurch plattformunabhängiger Code (bzgl. GEM Programmierung) möglich.

Wenn man mal in den Quellcode der freigegebenen Programme schaut (RCS, Desktop) sieht man, daß dafür noch keine GEM Lib benutzt wurde. Die benutzten VDI Funktionen waren direkt Bestandteil des Sourcecodes. Und die Namen der VDI Funktionen entsprachen noch denen des GKS Grafikpakets von DRI, das dann zum GEM VDI wurde. Zumindest für diese Programme wurde noch eine andere GEM API benutzt. Zwar natürlich dieselben Funktionen, aber noch nicht die uns vom VDI bekannten Namen.

Tschüß
Michael

[mfro]

...Na da würde ich mir ja die komplette Verwaltung einer Mintdistribution ans Bein binden. Ganz so viel Zeit stecke ich im Moment doch nicht mehr in Atari...

Siehst Du, da haben wir ein wohl symptomatisches Problem (nicht nur) der Atari-Welt: an Ideen, was andere mit ihrer Freizeit anstellen könnten, um etwas voranzubringen, mangelt es nicht

[m0n0]

Als ich mal HighWire kompiliert habe, hatte ich auch nach einer CFLIB gesucht, die mit PureC gelinkt werden kann. Ich hatte dann eine ziemlich alte Version gefunden:

http://nic-nac-project.org/%7Emonokrom/monochrom.net/atari/dl/cflib09.zip

Die Sourcen sind leider nicht dabei.

[ST-Oldie]

Hi,

Siehst Du, da haben wir ein wohl symptomatisches Problem (nicht nur) der Atari-Welt: an Ideen, was andere mit ihrer Freizeit anstellen könnten, um etwas voranzubringen, mangelt es nicht

Stimmt, da kann ich 100% zustimmen. Ich hab auch festgestellt, daß nette Mitmenschen sich manchmal Gedanken machen, was ich mit meiner Freizeit anfangen könnte ;-) Und das kommt verstärkt zum Tragen, wenn auch noch spezielle Kenntnisse nötig sind. Da ich Erfahrung als Software-Ingenieur habe, sind da auch schon Anfragen bekommen, mich zu engagieren.

Falls deine Bemerkung auf mich zielen sollte, ich erwarte nicht, daß da jemand anderes an RPMs für eine Mint Distribution arbeitet und wollte auch keinen dazu anhalten. Ich hab (zumindest zur Zeit) auch keine Ambitionen, mein System auf eine aktuelle Version upzugraden. Also brauch ich auch keine RPMs. Ich wollte nur dieses Durcheinander mit verschiedenen Paketformaten mal als Problem hinstellen. Das hält ja auch Leute vom Upgrade ab, wenn man quasi jedesmal eine Neuinstallation machen muß. Und es gibt immer noch Leute, die an Mint weiterentwickeln. Und dann wahrscheinlich gern sehen wollen, daß eine aktuelle Distribution benutzt wird. Ach ja, meine Installation basiert noch auf den Tarballs die z.B. auch in der Min98 Distri waren und nicht auf den RPMs von Sparemint.

Mich hält also quasi mangelndes Interesse an einer Mint Distribution davon ab, Zeit in die Erstellung einer solchen zu stecken. Man sucht sich ja die Arbeiten aus, bei denen man irgendwie ein Interesse hat daß es gemacht wird. Also quasi irgendeinen "Profit" zurück bekommt. Das kann auch ein ideeller Wert sein. Oder man benutzt das Ergebnis selbst, ...

Tschüß
Michael

[mfro]

Leider sind die Programme nicht stabil.

Mir ist da noch was eingefallen: die gemlib wurde irgendwann mal (ich nehme an, im Zuge der Einführung von "dynamic libraries" mit LDG) so "umgebastelt", daß die VDI-Funktionen reentrant/multithreading-fähig wurden. Die VDI-Funktionen in der GEMLIB nutzen - im Gegensatz zum ursprünglichen Original - keine globalen Parameterarrays mehr, sondern funktionslokale. Nachdem die natürlich auf dem Stack angelegt werden, muß der wesentlich größer ausfallen als "früher".

Normalerweise ist das kein Problem (man kann den ja entsprechend anlegen), es wird aber u.U. eins mit USERDEF-AES Objekten. Die werden vom AES im Supervisor-Mode aufgerufen, entsprechend werden die lokalen Parameterarrays (das sind 2-3kB) auf dem (u.U. sehr begrenzten) OS-Supervisor-Stack angelegt, was zumindest bei einigen TOS-Versionen und ohne MiNT zu einem Überlauf desselben führt.

Das ist der Grund warum QED (und manch andere Programme, die das AES per USERDEFS "aufhübschen") ohne MiNT auf manchen Betriebssystemversionen ein "seltsames Verhalten" an den Tag legen.

Ist das vielleicht bei dir auch die Ursache?