OS2.org Forum

aschn hat geschrieben: Di 22. Mai 2018, 21:03 Da sollte sich die letzten Tage was verbessert haben

In der frischen GA2-Version wenigstens hier leider noch nicht. Bin ich denn der einzige, der auf zwei Rechnern probiert hat, bei 99,9%CPU in einem Forum einzutippen? Da bleibe ich lieber bei meinem aktuellen Win-Monster (oder gelegentlich FF38).

FF45-9-0 GA2 läuft bei mir ohne Probleme, seit ich ein spezielles Addon deaktiviert habe. Das gleiche galt auch schon für die GA1.
Ich gehe davon aus, dass alle externen Abhängigkeiten (RPM-Requirements) installiert und auf dem aktuellen Stand sind.
Also am besten mal den FF starten alle Addons deaktivieren und schauen ob dies (nach einem Neustart des FF) hilft. Wenn Ja, dann sukzessive die Addons wieder aktivieren. Das Addon, welches ein Problem bereitet sollte sich so identifizieren lassen.

Grüße aus Potsdam,
Mike

Überraschenderweise hilft es auch das eine oder andere neue Theme zu benutzen. Als Beispiel nenne ich mal das "LavaFox V2" theme.
Warum das so ist weiß noch keiner aber es ist so. Wenn man das Theme ausgetauscht hat wird man dann im günstigsten Fall feststellen daß die CPU Auslastung verschwindet (insbesondere auch dann wenn man FF minimiert hat).

Leider sieht das "LavaFox V2" theme gräulich aus ...

Bei mir trappt der 45.9.0-3 (GA2) wieder, genau so wie 45.9.0-2. Interessant, dass 45.9.0-t5 dagegen bei mir lief - mit 100 %. (Die nächsten 2,5 Wo nichts mehr von mir.)

Inzwischen ja weit entfernt vom OP.... Nur diese eine Zeile noch zum 99,9%-Problem: Anscheinend hilft bisher, in der FF-config den Parameter "layout.frame_rate" von 0 auf -1 zu setzen (=der Default in meinen übrigen Firefaxen). Und habe dazu ein Ticket #271 eingestellt.

hey... vielen Dank für den Tip !!

jetzt läuft mein FF 45.9 ebenso ohne den "99.9%-Hänger"

Rolf

Um mal wieder auf mein ursprüngliches Thema zurückzukommen:

Rolf hat geschrieben: Di 29. Mai 2018, 11:15jetzt läuft mein FF 45.9.

Bei mir jetzt auch

Allerdings erst, nachdem ich das ArcaOS 5.0.1 neu installiert und dann ANPM verwendet habe. Alle anderen, herkömmlichen Versuche, die ich auf der Basis meiner (rudimentären) OS/2-Systemkenntnisse (DLL, LIBPATH etc.) unternommen hatte, sind gescheitert. Warum, bleibt ungeklärt, ist mir jetzt aber letztlich auch egal.

Mehr wollte ich eigentlich nicht sagen. Weiterlesen bitte nur, wer sonst nix Besseres zu tun hat

Ganz trivial war aber die Installation des von github besorgten FF 45.9.0, das in Form einer 7z-Datei vorliegt, immer noch nicht. Zuerst mußte ich einen 7z-Entpacker installieren (für Leute wie mich gehört dieses Format zu den "Exoten"). Dann mußte ich das so viel geühmte ANPM ebenfalls installieren (von der Arcanoae-Homepage). Es ist offenbar nicht Bestandteil des ArcaOS 5.0.1. Aber egal. Das ANPM ließ sich mittels des guten alten WPI leicht installieren.

Randbemerkung:
Das WPI-Verfahren brauchte Jahre, um auszureifen, was inzwischen der Fall ist. Sehr schade, dass dieses Verfahren nun wieder obsolet ist, zugunsten eines vollkommen anderen, des ANPM-Verfahrens. Aber auch hier sage ich: Ok, es ist wohl der - unausweichlichen - Tatsache geschuldet, dass die OS/2-Systemarchitektur inzwischen wesentliche Strukturmerkmale der Unix-Welt eingepflanzt bekommen hat.

Nun zum ANPM, das hier immer wieder als problemlos zu handhabende GUI über dem YUM/RPM-Verfahren angepriesen wird:

Im Readme.os2 meines Firefox-Installationspakets lese ich:
"If you have an ArcaOS subscription, then simply install a package named `firefox` using the ANPM GUI".
Das hat schlichtweg nicht funktioniert. Ein Packet namens Firefox war weder in "Installierten" Paketen enthalten noch in den "Verfügbaren" (ich habe das ANPM-Sprachpaket Deutsch installiert).

Damit stand ich wieder einmal vor der Wand. Die Rettung kam hier aus dem Forum, wo ich darauf hingewiesen wurde, dass es für den FF 45.9. zwei verschiedene Quellen gibt. Ausser der von mir verwendeten Quelle auf os2world.com gibt es noch ein strukturell völlig anders aufgebautes Paket auf github, in diesem 7z-Format. Dieses habe ich downgeloadet und dort fand ich dann ein weiteres Readme, in dem die Installationsweise ebendieses 7z-Pakets mit Hilfe von ANPM genau beschrieben wurde. Update: Wie ich gerade sehe, ist auf der genannten Seite jetzt nur noch die github-.Version verlinkt!


Das hat dann zunächst auch geklappt. Aber als der Firefox starten wollte, gab es die nächsten Probleme: Zweimal konnte die XUL.DLL nicht geladen werden, jedesmal im Kontext mit irgendeiner anderen DLL. Wieder stand ich vor der Wand. Irgendeine innere Intuition riet mir dann: Gehe ins ANPM und installiere diese beiden DLLs (Namen habe ich jetzt vergessen) aus den "Verfügbaren Paketen".

Als das erledigt war, startete der Firefox aber immer noch nicht. Diesmals aber fieserweise ganz ohne Fehlerdialog. Programmaufruf von der Kommandozeile - dunkler Bildschirm - zwei Sekunden später wieder zurück auf der Kommandozeile.

Wieder half mir die innere Intuition: Ich schaute im POPUPLOG.OS2 nach. Dort war zu lesen, dass es einen SYS2020 in der LIBCX0 gab. Wenn ich nicht in meinem früheren Leben selbst einmal C-Programme geschrieben und folglich zur Genüge diesen Fehlercode schon erlebt hätte, wüßte ich damit nix anzufangen. So aber war klar: Versionsunverträglichkeit in der LIBCX0. Also auch die mußte per ANPM nachinstalliert werden.

Dann - Uff!! - startete der FF 45.9. ohne weitere Sperenzchen.

Warum erzähle ich das alles hier lang und breit? Hm, weiß nicht genau. Mußte mir vielleicht mal den ganzen Frust, der sich über Monate des immer mal wieder Versuchens angestaut hatte, loswerden. Ich wollte doch nur meinen Firefox von Version 38 auf 45 upgraden!

Vielleicht will ich damit aber auch zum Ausdruck bringen: OS/2 (aka ArcaOS) ist inzwischen genausowenig DAU-fähig wie es Linux immer noch ist. Ok, kann man jetzt einwenden: Wer was anderes erwartet hatte, ist naiv. Ok, ok.

Dennoch möchte ich nicht versäumen, meinen Respekt den Leuten von ArcaNoae und Bitwise (und wer sonst noch an all dem "neuen" Zeugs beteiligt ist) auszusprechen. Das ANPM scheint - wenn man einmal die Terminologie verstanden hat - recht ausgereift zu sein. Und es spricht sogar Deutsch

Mir ist die Fortexistenz "meines" OS/2 (heiße es wie es wolle) zu wichtig, als dass ich die Leute, die noch an der Weiterentwicklung beteiligt sind, mit übertriebener Kritik vergrätzen möchte. Deswegen schließe ich meine "Rede" mit einem ausdrücklichen Dank an alle und hoffentlich weiter so (oder besser )

Gruß,
Lutz Wagner

DonLucio hat geschrieben: So 3. Jun 2018, 17:32 Weiterlesen bitte nur, wer sonst nix Besseres zu tun hat

Solch ein Satz ist ja wie eine Aufforderung zum Trotzdem und hab' grad frei
Super dass es geklappt hat.

Zuerst mußte ich einen 7z-Entpacker installieren (für Leute wie mich gehört dieses Format zu den "Exoten"). Dann mußte ich das so viel geühmte ANPM ebenfalls installieren (von der Arcanoae-Homepage). Es ist offenbar nicht Bestandteil des ArcaOS 5.0.1. Aber egal. Das ANPM ließ sich mittels des guten alten WPI leicht installieren.

Hätte hätte... Zuerst hätte ich den neuesten ANPM bei ArcaNoae geholt und installiert. Anschließend alles updaten, gelegentlich muss zwischendurch neu gebootet werden, insbesondere bei libc*, glaube ich. Eventuell auch wiederholen.
Ein 7z-Entpacker steckt bereits im Lieferumfang von ArcaOS, nämlich das "ArchiveTool", bei mir unter Computer -> Utilities.

simply install a package named `firefox`

Ach ja, Entwicker und Dokumentation... Ob das nur an registrierte Beta-Tester adressiert ist oder schon ein Vorgriff auf die Zukunft für DAUs, wer weiß. Am Ende hat ja die "manuelle Installation" irgendwie funktioniert. Hier ging das Installieren nach wohlwollendem Rätselraten überraschend ohne nennenswerte Haken. Allerdings, so richtig rund bin ich mit dem FF45 noch nicht, trotz Grobtuning, es kommen hoffentlich weitere "GAs".

Deinem Dank und Respekt vor den Entwicklern möchte ich mich ausdrücklich anschließen!! Es sind nämlich keine Myriaden von Humankaptital inklusive Tester an den Projekten beteiligt, und die Support-Basis ist inzwischen generell recht überschaubar. Für konkrete Probleme ist am Ende der Bugtracker viel besser geeignet als irgendwelche ätzende praxisferne Mopperei in den Foren. Dagegen freue ich mich immer wieder über Berichte, wie jemand so oder anders erfolgreich war (oder noch nicht), das zieht auch so manchen Nebel vor den Augen weg

<CITE>Meine FF-45-Version stammt von hier: https://github.com/bitwiseworks/mozilla ... _OS2_GA1_1.</CITE>
Dort gibt es die Version firefox-45.9.0-3.oc00.pentium4.7z
nach meinem Verständnis sollte die Version firefox-45.9.0-4.oc00.pentium4.7z die aktuellere sein ???

Viele Grüße,
Gerhard

Gerhard hat geschrieben: So 3. Jun 2018, 18:28 Dort gibt es die Version firefox-45.9.0....

Die Updates kommen halt manchmal schneller als wir hier tippen Regelmäßig auf https://www.os2world.com/ und http://ecsoft2.org/ stöbern ist nicht schlecht.

Mal eine Frage die zum Titel dieses Fadens ("Grundlagen...") passt:

Wie lang dürfen eigentlich die Einträge im PATH und LIBPATH sein?
Ich weiß, daß es eine Beschränkung gab, aber welche...

P.S. Ahh, gerade hier: viewtopic.php?p=8989#p8989 gefunden. Also ca. 500 Zeichen.
Hmm, ich habe da nämlich ein Problem. Meine Libpath hat einschließlich Schlüsselwort eine Länge von 479 Zeichen und meine Path eine Länge von 495 Zeichen. Trotzdem sagt mir die Kommandozeile beim Aufruf eines (im Path enthaltenen) Programmes: SYS1041 (kain ausführbares Programm...

Es gibt da noch ein paar Details. Aus meinen Aufzeichnungen für so etwas:

• BeginLIBPATH und EndLIBPATH können sogar 1023 Byte lang sein (Pseudo-Variablen).
• Wie lang LIBPATH werden kann und ob ob dieses Maximum zusammen mit Begin/EndLIBPATH gilt, weiß ich nicht. Wie ich gerade im Link gesehen hab, hab ich damals die Zahl von etwa 500 ins Spiel gebracht. Das hatte ich dann mal ausprobiert. LIBPATH ist eine Kernel-Anweisung und deshalb ein Sonderfall.
• CONFIG.SYS-Variablen: ? (Auf jeden Fall mehr als das, was CMD.EXE verträgt. In cfgdat.inf kann ich auch nichts darüber finden. Wer's wissen will, muss wohl Steven Levine fragen.)
• CMD.EXE: max. 299 Byte. Das muss nicht heißen, dass Variablen auch nicht länger werden dürfen.
• COMMAND.COM: max. 127 Byte.

Bei den Erweiterungen von BeginLIBPATH und EndLIBPATH gibt es noch etwas zu beachten. Du hast zwar nichts von BeginLIBPATH geschrieben, aber die neueste Mozille erweitert auch den LIBPATH im laufenden Betrieb für die folgende Umgebung, was nur mit Begin/EndLIBPATH geht. Dabei kommt es übrigens auf die Systax an: Alle Pfade müssen existieren. Pfade müssen immer mit ';' abgeschlossen werden. Ansonsten wird Begin/EndLIBPATH gelöscht. Ich glaub aber diese Regel gilt für LIBPATH nicht.

Das lässt sich auch einfach ausprobieren. Man kann sich ja den Wert der Variablen PATH anzeigen lassen. Also nach jeder Erweiterung auch den Wert abfragen, bis es irgendwann nicht mehr geht. Bei mir sind aktuell LIBPATH 418 Byte und PATH 379 Byte lang.

Zuerst würde ich aber neu starten. Dann hast Du ausgeschlossen, dass ein Speicherbereich nicht mehr frei ist.

aschn hat geschrieben: Di 14. Mai 2019, 21:40
...
Das lässt sich auch einfach ausprobieren. Man kann sich ja den Wert der Variablen PATH anzeigen lassen. Also nach jeder Erweiterung auch den Wert abfragen, bis es irgendwann nicht mehr geht. Bei mir sind aktuell LIBPATH 418 Byte und PATH 379 Byte lang.

Hallo Andreas,
also erst mal muß ich mich hier konkretisieren: bei mir ging es nicht um den firefox sondern um ffmpeg - t'schuldigung dafür. Sachlich ändert das aber nichts.
Also Path habe ich kontrolliert; 's geht ja einfach mit Eingabe von PATH auf der Kommandozeile - und der ist vollständig.
Wie kann man libpath kontrollieren? Und: wie misst Du die Größe der beiden Werte? (Ich hatte sie kurzerhand in papyrus kopiert und dort über die Dokumentenstatistik ermittelt da ich mich mit den ganzen Editoren nun gar nicht auskenne)

Zum Tipp "neu starten": ist bei einer "frischen" Änderung ja sinnvoll bzw. sogar notwendig, jedoch existieren die Einträge bei mir schon lange. Nur nutze ich eben selten die Kommandozeile...

Ach so, noch etwas: daß in der config.sys vor LIBPATH kein SET steht ist richtig, oder?

ajunra hat geschrieben: Mi 15. Mai 2019, 16:47

ich würde einmal mit chkdll32 oder mit pmdll schauen ob alles für ffmpeg da ist. ich vermute eher es fehlt eine dll oder sowas.

_diver hat geschrieben: Mi 15. Mai 2019, 16:55 ...
ich würde einmal mit chkdll32 oder mit pmdll schauen ob alles für ffmpeg da ist. ich vermute eher es fehlt eine dll oder sowas.

Werde ich machen, jedoch glaube ich das nicht. Denn wenn ich direkt in das Programmverzeichnis gehe funktioniert es ohne murren. Nur eben nicht "einfach so".
Aber gerade bei den neueren ffmpeg-Versionen war das schon ein Krampf die zum laufen zu bewegen. Was da alles aus dem ffmpeg/lib-Verzeichnis ins usr/lib Verzeichnis kopiert werden musste

ajunra hat geschrieben: Mi 15. Mai 2019, 17:19 Denn wenn ich direkt in das Programmverzeichnis gehe funktioniert es ohne murren. Nur eben nicht "einfach so".
Aber gerade bei den neueren ffmpeg-Versionen war das schon ein Krampf die zum laufen zu bewegen. Was da alles aus dem ffmpeg/lib-Verzeichnis ins usr/lib Verzeichnis kopiert werden musste

Das hört sich dann doch danach an, dass Du ein Mischmasch aus verschiedenen DLL-Versionen hast.

Bei so etwas ist es gut, erst einmal die Reproduzierbarkeit zu überprüfen. Dazu nimmt man ein frisches (AN-)System, installiert die .rpm-Pakete mit ANPM und testet dann. Dann hat man nämlich genau den Weg eingehalten, den Entwickler unterstützen und auch fast immer selbst testen. Alles andere ist "Basteln" auf eigenes Risiko.

Ich würd es also umgekehrt machen: Erst einmal den Standardweg versuchen. Wenn der funktioniert, hat man ein System, das man mit dem eigentlichen vergleichen kann. Sonst ist es ja wegen der unendlichen Möglichkeiten fast aussichtslos einen Fehler zu finden.

Hmm, wie ich erwartet hatte, alle DLLs konnten geladen werden.

ajunra hat geschrieben: Mi 15. Mai 2019, 18:04 Hmm, wie ich erwartet hatte, alle DLLs konnten geladen werden.

da ja nichts aus dem ffmpeg dir gebraucht wird, muss es von überall gehen. ansonsten mal ffmpeg >log.txt 2>err.txt und schauen ob da was drin steht,.

Leider steht bei beiden nichts relevantes drin. Wenn ich aus c: ffmpeg aufrufe bleibt log.txt leer und err.txt zeigt beim Aufruf aus dem Verzeichnis bei e:\Programme... bleibt log.txt auch leer und err.txt zeigt Also nichts anderes als das was generell beim Aufruf über die Kommandozeile kommt. Hmm, seltsam.

ajunra hat geschrieben: Mi 15. Mai 2019, 20:23 Leider steht bei beiden nichts relevantes drin. Wenn ich aus c: ffmpeg aufrufe bleibt log.txt leer und err.txt zeigt
...

und du bist sicher deine PATH variable stimmt? Ich zweifle da etwas. mach mal set path und zeig was er dir ausgibt.

_diver hat geschrieben: Do 16. Mai 2019, 08:09 ...
und du bist sicher deine PATH variable stimmt? Ich zweifle da etwas. mach mal set path und zeig was er dir ausgibt.

Oh man, Du hast ja so Recht! Da fehlte ein Teil des Pfades! Da hatte ich seinerzeit beim entpacken nicht aufgepaßt und den Haken vergessen wegzunehmen.
Ok, habe ich jetzt korrigiert (die Dateien einen Ordner nach oben geschoben). Jetzt funktioniert es! Mann, wie kann man nur so Blind sein...