Mein letztes CI-Latest ist schon einige Wochen alt, bin erst am Mittwoch aus dem Urlaub zurück. Also werde ich mir das mal "reinziehen" und schauen.
Für einen kurzen Blick kannst du natürlich auch immer https://mgroeber.de/geos-live_d.html anschauen, wo jeweils das aktuelle CI-Latest läuft.
ciao marcus
Das Problem ist vermutlich die Kombination mit exempt, aber ohne platform: dann wird der ganze Plattform-Check-Mechanismus aktiviert, aber es gibt gar keine Liste, welche Libraries überhaupt da sind. Der ergibt nur Sinn, wenn man sowohl die Libraries einer Plattform kennt, aber dann auch einzelne ausnehmen will, die man selbst mitliefert.
Erst mal keine Idee, woher das kommt. Sind denn überhaupt irgendwelche Platform-Dateien in der gp aufgeführt? Ich bin mir nicht sicher, woher die "default-Plattform" kommt, wenn man keine platform angibt, aber könnte es sein, dass deine .ldf-Dateien nicht in Ordnung sind?
Wenn ich mir Library_CheckForMissingLibraries in glue ansehe, kann diese Meldung überhaupt nur auftauchen, wenn eine Plattform angegeben ist, oder eine Library exempt ist (weil der Check ansonsten übersprungen wird).
Dann müsste man ein Mapping von Helvetica auf andere Schrift erstellen !
Outliner benutzt Font URW_Sans wird gemappt mit Nimbus Sans Info von Falk !
Ich vermute, der Treiber benutzt nur Helvetica, weil er nichts besseres findet.. So wie ich fontID.def und die Funktion CalcFontDiff interpretiere, gibt sich der PS-Treiber viel Mühe, anhand der FontID eine passende Schrift zu finden, die "ähnlich" aussieht (also gleiche Familie, ähnliche Strichstärke usw.). Wäre es denkbar, dass das Mapping von Geos-Fonts auf PS-Fonts hat die neuen TT-Fonts nicht zuordnen kann und darum immer auf Helvetica zurückfällt?
Das sieht aber wieder anders aus als die Frage, warum die PS-Datei abgeschnitten wird...
Krass! Ist das eine Funktion, die Du vermisst?
Wenn ich mich richtig erinnere, war es zumindest mal eines der Highlights von GeoDraw, dass es sehr früh schon diese Mischung aus Vektor- und Bitmap-Zeichenprogramm angeboten hat. In sofern wäre es wirklich schön, wenn man das reaktivieren könnte, um den ganzen ursprünglichen Funktionsumfang zeigen zu können.
ciao marcus
Font-Dateinamen haben kleine Buchstaben, der Font Viewer findet/liest diese Fonts gar nicht.
Nur so ein Gedanke: könnte es vielleicht nur die Dateierweiterung sein, die den Unterschied macht (*.TTF vs. *.ttf)?
Ich habe jetzt begonnen mich mit dem Speicherhandling des Treibers zu beschäftigen. Ein erster Block ist bereits von einen fixed Block zu einem movable und swapble Block geworden. Es müssen aber noch ein paar weitere folgen.
Gibt es aktuell irgendeinen Bereich, den ich mir mal genauer ansehen könnte, ohne dir im Weg zu sehen? Ich nehme an, das ist immer noch der alte TTF Branch in deinem Repo?
ciao marcus
Danke für das Update, Jirka!
Um diese Idee hier etwas zu unterstützen...
Dann muss die Performance des Treiber noch deutlich verbessert werden. Ein direkter Vergleich der Renderzeiten von Nimbus und TTF-Treiber wäre auch noch interessant um herauszufinden wieviel da noch zu tun ist. Da die Font Funktionen im Kernel quasi für die Struktur der Nimbus-Fonts 'maßgeschneidert' wurden wird der TTF-Teiber die Performance des Nimbus-Treibers nicht erreichen können.
...habe ich mal eine kleine Ergänzung an meinem Font Lister gemacht, so dass er auch die ungefähre Rendering-Zeit für einen Buchstaben anzeigen kann. Dazu werden die Buchstaben A bis Z nacheinander in 29pt (wofür es hoffentlich fast nirgendwo optimierte Bitmaps gibt) in einen Bitmap-GString gemalt und die Zeit gestoppt. Das geht zwar pro Systemstart nur einmal (danach ist der Font-Cache gefüllt), aber eine Idee gibt es schon mal. Im Moment würde ich grob einen Faktor 10-12 zwischen TTF und Nimbus sehen:
Den Quellcode gibt es hier: https://github.com/mgroeber9110/freegeos-font-lister
Hallo Thomas,
die Frage hat zwar nur am Rande mit Pi/GEOS zu tun, aber mangels Pi zum Ausprobien frage ich einfach mal hier:
Wie löst du das Problem mit der TLS-Kompatibilität beim Browser, da die Geos-SSL-Library ja nur sehr begrenzt HTTPS erlaubt? Benutzt Pi/GEOS einen lokalen Proxy?
Ich versuche gerade, mir so was unter Windows aufzusetzen, um den aktuellen Browser in FreeGEOS mal etwas besser zu testen (via pppd und squid), aber vielleicht hast du ja ein eleganteres Setup gefunden.
Hab es mal kurz hiermit probiert, aber noch ohne Erfolg: https://system7today.com/setup-crypto-ancienne
Ich glaube, ich hab's gefunden - es war tatächlich etwas mit den Defines für den Watcom-Compiler, wodurch versehentlich eine wichtige Zeile des PPP-Codes nicht eingebaut wurde.
Mit diesem PR funktioniert es für mich wieder: https://github.com/bluewaysw/pcgeos/pull/467
ciao marcus
Ich habe dann nacheinander SYSTEM/NET.GEO und SYSTEM/NETUTILS.GEO mit den Versionen aus BBX4.1.3 ausgetauscht: ohne Effekt. Danach SYSTEM/SOCKET/PPP.GEO und den Rest in SYSTEM/SOCKET. Das führt aber sofort zum KR-06/07 nachdem gewählt wurde.
Der PPP-Treiber enthält gegenüber dem EtherODI/PKT ja auch C-Code. Vielleicht ist da ja was noch nicht sauber umgestellt.
Danke für die Experimente! Mal überlegen, ob man das noch irgendwie einkreisen kann - wäre doch schön, wenn man die erste Relase von FreeGEOS auch mit Pi/GEOS laufen lassen kann. Kann natürlich wirklich sein, dass das Problem auf den PPP-Treiber beschränkt ist, dann wäre zumindest Falks Direktverbindung zur DOSBox davon nicht betroffen.
ciao marcus
in Pi/GEOS wird die Internetverbindung wie im von Dir verlinkten Posting aufgebaut. Das funktioniert auch mit allen GEOS-Version ab 3.1 nur nicht mit FreeGEOS. Daher ist es gut möglich, dass etwas in der von Dir ausgemachten Bibliothek fehlerhaft ist.
Danke - das ist auch ein guter Datenpunkt. Wenn FreeGEOS unter Pi/GEOS auf diese nicht ins Internet kommt, das letzte Breadbox-Ensemble aber schon, ist das auf jeden Fall ein Grund, noch mal auf Fehlersuche zu gehen (z.B. durch Austauschen von Libraries), parallel zu den Experimenten von Falk mit einer direkten Verbindung über die DOSBox.
Kannst du vielleicht etwas genauer beschreiben, was mit FreeGEOS auf dem Pi nicht funktioniert? Bei mir scheitert schon der Versuch, die PPP-Verbindung auszuhandeln (ich glaube, es endet mit mit einem LCP-Timeout).
Dieses Ding ist echt Klasse, weil man so auch immer schnell mal gucken kann, sich das offizielle GEOS verhält, wenn man beim Programmierrn unsicher ist ob man gerade einen Bug produziert hat.... wäre echt mega wenn wir das Ding an die CI hängen könnten, so dass automatisch mit jedem GitHub-Build auch so eine Referenzinstallation im Web erfolgt...
Das wäre nicht so schwierig, man müsste nur den Code für den Emulator und die Seite auf dem gleichen Server hosten, auf den man auch die CI-Builds pusht, da sonst die Cross-Origin-Beschränkung des Browsers dazwischenfunkt.
Das einzige, was noch nötig wäre, ist jeweils eine feste Konfigurationsdatei für jsdos in der hochgeladenen .zip-Datei zu ergänzen.
Da Falk die Builds (soweit ich weiß) sowieso auf einem eigenen Jenkins-Server macht und dann auf Github hochlädt, könnte man das vermutlich recht einfach einrichten - vielleicht unter live.bluewaysw.de oder so, damit Build und Hosting in einer Hand bleiben.
Danke, den Branch hatte ich bisher noch gar nicht auf dem Schirm.
Läuft schon mal und verbindet sich auf Anhieb, auch wenn ich im Moment noch ziemlich schnell in einen KR-09 bzw. einen Verbindungsfehler laufe. Ich schaue mal bei Gelegenheit mit Swat etwas genauer drauf.
Ich habe neulich mal einen Versuch gestartet, für das aktuelle #FreeGEOS einen einfachen, stabilen Weg zu dokumentieren, wie man unter Windows eine Internet-Verbindung ausprobieren kann.
Dabei schien mir erst mal der Ansatz per PPP-Einwahl über ein simuliertes Modem am vielversprechendsten, wie er hier beschrieben ist. Perfekt wäre ein kleines Windows-Programm, das das Routing übernimmt, aber die Idee sollte sich erst mal auch mit dem WSL2-Subsystem für Linux in Windows verwirklichen lassen.
Ich habe schon erste Kontakte zwischen dem pppd und GEOS in der DOSBox hinbekommen, aber noch keine echte PPP-Verbindung aufbauen können, über die sich Daten austauschen ließen (meist scheint es irgendeinen Speicherüberlauf im Umfeld von NetUtils zu geben).
Hat jemand zufällig Erfahrung damit, ob das mit dem aktuellen #FreeGEOS überhaupt geht? Ich habe mich bisher noch nicht so detailliert mit dem Zustand des TCP/IP-Stacks beschäftigt, daher könnte es einfach sein, dass irgendein Feature in der GEOS.INI noch gar nicht richtig eingerichtet ist. Auch die Details der Modem-Emulation der DOSBox scheint stark vom verwendeten Fork abhängig zu sein, weil sie wohl fast nur für Multiplayer-DOS-Spiele genutzt wird.
Ich habe jetzt mal die Höhe des virtuellen Bildschirms auf 600px festgelegt, um die Skalierung zu vermeiden, und bei der Gelegenheit auch die aktuellen Builds von heute Nachmittag eingespielt.
Weil es so schön einfach geht, habe ich jetzt auch noch die aktuelle deutsche Übersetzung hinzugefügt: https://mgroeber.de/geos-live_d.html
Ich habe noch mal ein bisschen weiter experimentiert, im Moment mal mit js-dos, da es dort mit https://dos.zone/studio/ eine sehr einfache Möglichkeit gibt, ein .zip (wie z.B. von github) noch mit den nötigen DOSBox-Konfigurationsdaten "anzureichern" und dieses Paket dann mit ein paar Zeilen JavaScript im Browser laufen zu lassen.
Nur mal als Idee ist hier die aktuelle (englische) Release von github (pcgeos-ensemble_nc.zip) - allerdings muss die im Moment noch als Kopie auf meiner Domain liegen, da der JavaScript-Client sie wegen CORS (einem Sicherheitsfeature) nicht von einem anderen Server holen kann und weil eben die [font='Courier New, Courier, mono'].jsdos/dosbox.conf[/font] noch zusätzlich im gleichen .zip benötigt wird:
https://www.mgroeber.de/geos-live.html
Als i-Tüpfelchen würde jetzt noch fehlen, einen neuen Geos-Build nicht nur bei github zu veröffentlichen, sondern auch auf einer anderen Domain, wo dann auch die Seite mit der DOS-Box im Browser liegt. Damit könnte man dann jeden aktuellen Build sofort im Browser ausprobieren, ohne irgendwas installieren zu müssen.
Ist das _der_ Fabrice Bellard? Dem verdanken wir QEMU und die Anfangszeiten davon waren extrem spannend. Vorallem, wenn man mit den Programmierern noch direkt per Email Ideen und Probleme austauschen konnte...
Ja, das müsste _der_ Fabrice Bellard sein. Von ihm habe ich erst neulich zum ersten Mal gelesen. Ich glaube, dass er auch FFMPEG initiiert hat - das ist wohl einer der großen Helden der Zunft...
Schon cool! Bei mir ließ sich aber keines der GEOS-Programme starten.
Stimmt - geht bei mir leider auch nicht. Da müsste man wohl noch ein bisschen herumexperimentieren. Was mir im Moment vorschwebt, wäre eine Webseite, die so einen DOS-Emulator enthält und sich jeweils das aktuelle Image von https://github.com/bluewaysw/pcgeos/releases/tag/CI-latest holt.
Dann könnte man jederzeit die aktuelle Nightly-Version in einem Browser anschauen - natürlich nicht zum Arbeiten (weil man ja keine Dateien dauerhaft speichern kann), aber um schnell mal etwas ausprobieren oder zeigen zu können, ohne irgendwas installieren zu müssen.
