amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Suche [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 2 3 -4- 5 Ergebnisse der Suche: 124 Treffer (30 pro Seite)
tboeckel   Nutzer

29.11.2007, 10:46 Uhr

[ - Direktlink - ] 		Thema: "Virtueller RAM Speicher" als Partition oder in einer Datei
Brett: Amiga, AmigaOS 4

@MaikG:
Zitat:
Naja, ich meine es waren ja immer 4 Pixel, da Programmiert
man halt so effektiv wie möglich und benutzt sowenig
wie möglich berechnungen.

Genau da liegt das Grundproblem des Amiga. Mit Effizient hat das wenig zu tun. Wenn das Auslesen der Rahmengröße aus einer Struktur im Gegensatz zu einer Konstante wirklich Performanceprobleme verursacht, dann hat so ein Programm noch ganz andere Probleme. Nur weil viele Sachen "schon immer so waren" heißt das noch lange nicht, daß sie "auch immer so bleiben". Die Rahmengröße in der Fensterstruktur existiert schon seit OS1.x, nur stehen viele Programmierer auf dem Standpunkt, daß man solche Sachen nicht benutzen braucht, wenn man es selbst besser weiß als das OS. So was muß früher oder später dazu führen, daß man sich selbst (und auch anderen) in den Fuß schießt.

Als das neue Speichersystem in OS4 implementiert wurde gab es ähnliche Diskussionen, weil einige Programme die undokumentierte Tatsache ausgenutzt haben, daß AllocVec() die Speichergröße an einer bestimmten Stelle speichert. Als das dann unter OS4 nicht mehr funktionierte, weil diese Größenangabe vom OS plötzlich gar nicht mehr benötigt wurde, da war das Geschrei groß. Aber komischerweise konnte niemand außer "Bequemlichkeit" wirklich gute Gründe angeben, warum man schlauer als das OS sein sollte und darum undokumentierte Zufälle ausnutzen darf. Das hat nichts mehr mit Kompatibilität zu tun.

Wann lernen es die Programmierer endlich mal den offiziellen Weg zu gehen? Nur weil unter AmigaOS früher viele Hacks problemlos möglich waren ändert das nichts an der Tatsache, daß es Hacks waren, sind und bleiben werden, die unerlaubte Abkürzungen gehen und deswegen unter zukünftigen OS-Versionen scheitern müssen, weil der Trampelpfad zu einem Abgrund wurde. Aber das aus gutem Grund!
 
tboeckel   Nutzer

26.11.2007, 08:34 Uhr

[ - Direktlink - ] 		Thema: "Virtueller RAM Speicher" als Partition oder in einer Datei
Brett: Amiga, AmigaOS 4

@MaikG:

Zitat:
Dumme entscheidung. Selbst wenn es langsam ist, es wird ja nur
benutzt wenn die 128 MB voll sind!

Das neue Speichersystem hat keine Prioritäten mehr. Der gesamte Speicher wird als Einheit angesehen. Der langsame Z2/3-Speicher könnte also jederzeit genutzt werden, und nicht erst dann, wenn der Speicher auf der CS voll ist. Das System würde also eigentlich ständig vom langsamen Speicher ausgebremst. Von daher ist die Entscheidung überhaupt nicht dumm.

Zitat:
Was ist dir lieber ein Systemabsturz oder ein kurzzeitig langsames System?

Wenn es wegen Speichermangel einen Absturz gibt, dann ist das auch unter OS3 bereits so gewesen und ein Fehler in dem jeweiligen Programm, aber garantiert nicht im Betriebssystem.
 
tboeckel   Nutzer

19.11.2007, 17:19 Uhr

[ - Direktlink - ] 		Thema: YAM und der Filter ....
Brett: Amiga, AmigaOS 4

@R-TEAM:

Aber hast du das System denn wirklich schon mal ohne alle Patches aus dem Aminet oder sonst wo her laufen lassen? OS3.5/9 sind zwar auch "nur" ein Aufsatz auf OS3.1, aber immerhin ein offizieller Aufsatz. Alles weitere ist oft nur Hackerei ohne Kenntnis der Interna.

Deaktivier bitte einmal alles bis auf die für 68060 nötigen Sachen und laß YAM dann laufen. Das Risiko ist gleich Null. Es reichts ja die Patches auszukommentieren. Wenn dann irgendwas ein erfolgreiches Booten verhindert, dann kann man es ja jederzeit wieder mit reinnehmen.

Wenn man Probleme behoben haben möchte, dann sollte man auch schon mal ein wenig mithelfen. Und da das Problem bisher nur und ausschließlich bei dir auftritt ist es leider wahrscheinlicher, daß irgendwas in deinem System im Weg steht anstatt was in YAM.
 
tboeckel   Nutzer

19.11.2007, 08:06 Uhr

[ - Direktlink - ] 		Thema: YAM und der Filter ....
Brett: Amiga, AmigaOS 4

@R-TEAM:

Die "normalen" Filter vergleichen nur Strings bzw machen Pattern-Matching. Im einfachsten Fall werden sogar nur Zahlen verglichen. Nur der Spam-Filter braucht Fließkommaarithmetik, und die wird unter OS3 von clib2 (das C-Runtime-System) komplett über die mathieee#?.library's abgewickelt.

Die Mails einfach nur auf dem Server zu belassen wird nicht reichen, solange YAM Duplikate vermeiden soll. Das muß ebenfalls ausgeschaltet werden, damit immer alle Mails geholt werden.
 
tboeckel   Nutzer

18.11.2007, 19:43 Uhr

[ - Direktlink - ] 		Thema: YAM und der Filter ....
Brett: Amiga, AmigaOS 4

@R-TEAM:

Wenn ich mir deine Startup-Sequence so ansehe, dann hast du vielleicht 10% der Patches deaktiviert, aber noch lange nicht alle. Und in SYS:WBStartup liegen auch gerne noch viele Patches drin. Verläßliche Ergebnisse erhält man nur, wenn mal *alle* Patches ausschließen kann. Vor allem solche Hacks wie "Quantum" sollte man definitv vermeiden. Wer glaubt durch sowas einen schnelleren Rechner zu bekommen, der irrt! Laß YAM doch bitte mal komplett *ohne* Patches laufen.

Mal so nebenbei eine kleine Denksportaufgabe. Der Task des input.device, das für die Maus verantwortlich ist, läuft mit Priorität 20. Wenn YAM auf Priorität 0 es schafft, einen Task mit Pri 20 zu "überflügeln", so daß die Maus hakt, aber auf Pri -2 nicht mehr, dann liegt das woran? Solche Effekte schaffen nur komische Hacks! Wenn es keine anderen rechenwilligen Tasks mit Pri 0 gibt, dann ist Pri -2 genauso gut wie Pri 0 oder -100, es sei denn, man hat ganz gewaltig am Scheduler gedreht. Und genau das macht zB Quantum!

Außerdem gibst du selbst zu, daß nicht nur YAM diese Aussetzer verursacht, sondern auch andere Programme. Ein Filesystem wie SFS ist *immer* aktiv, könnte also auch immer für Hänger sorgen, wovon ich aber mal nicht ausgehe.

CyberPatcher zu deaktivieren sollte auch keine Probleme machen, weil YAM ist für 68020-68060 compiliert ist und somit die möglichen Problembefehle des 68060 vermeiden sollte. Ich hatte YAM selbst jahrelang auf einem 060er System mit einigen eigenen Filtern laufen (allerdings noch lange vor dem Spamfilter), und da hat nie was gehakt.

YAM's Spamfilter braucht beim Bewerten des Mailinhalts Fließkommaarithmetik. Neben den normalen Grundrechenarten werden sonst nur log(), exp() und frexp() benötigt, wobei log() und exp() direkt durch die mathieeedoubtrans.library abgewickelt werden. Wenn die nicht sauber implementiert ist, dann liegts auch wieder nicht an YAM, falls etwas hakt.

Um wirklich verläßliche Ergebnisse zu erhalten laß dein System bitte mit so wenig Patches wie möglich laufen, vor allem auf die doch oft sehr zweifelhaften Hacks sollte man auf Dauer verzichten. Den nötigen Input für die Filter kann man sich auch selbst schicken, falls der normale Nachschub nicht reicht. Hakt es auch, wenn deine eigenen Filter alle nicht aktiv sind?

Tut mir leid, aber außer einem total zugepatchten System lieferst du absolut keine nachvollziehbaren Fakten, daß YAM's Filter in irgendeiner Art und Weise etwas "schlimmes" tun, das die Maus haken lassen könnte.
 
tboeckel   Nutzer

16.11.2007, 14:21 Uhr

[ - Direktlink - ] 		Thema: YAM und der Filter ....
Brett: Amiga, AmigaOS 4

Problem gelöst oder kein Interesse mehr?
 
tboeckel   Nutzer

12.11.2007, 15:16 Uhr

[ - Direktlink - ] 		Thema: YAM und der Filter ....
Brett: Amiga, AmigaOS 4

@R-TEAM:

OS3-System neigen dazu bis weit über die Hutkrempe (sprich: ein gesundes Maß) mit Patches vollgestopft zu sein. Welche Patches hast du üblicherweise aktiv? Die Filter nutzen dos/MatchPattern() für die Stringsuche. Wenn irgendein Patch das auf eine etwas unsaubere Art implementiert, dann fällt das beim exzessiven Gebrauch durch YAM natürlich schnell negativ auf. Wobei das aber immer noch kein Fehlverhalten von YAM ist.

Hakt es auch, wenn AmiGift/CTorrent nicht läuft?

Hast du auch mal nebenbei Programme wie CyberGuard/MuForce/etc laufen lassen? Eine hakende Maus ist auch oft ein Zeichen dafür, daß irgendein Programm Null-Pointer dereferenziert und dann wilde Sau spielt. Unter OS3 muß das nicht sofort zum Absturz führt.
 
tboeckel   Nutzer

10.11.2007, 23:21 Uhr

[ - Direktlink - ] 		Thema: YAM und der Filter ....
Brett: Amiga, AmigaOS 4

@R-TEAM:

Wenn deine Maus hakt, dann liegt das garantiert nicht an YAM, da YAM weder das Multitasking deaktiviert noch irgendwelchen anderen Schweinkram macht.

Außerdem solltest du bedenken, daß sich Spam üblicherweise nur sehr schwer wirklich zu 100% klassifizieren läßt. Darum verwendet YAM auch einen Bayes-Filter, der bestimmte Wörter mit bedingten Wahrscheinlichkeiten verknüpft und dadurch Spam mit hoher, aber nicht 100%iger Wahrscheinlichkeit erkennen kann. Ohne ein entsprechendes Training kann dieser Filter wenig bis gar nichts korrekt erkennen und hat außerdem auch false-positives (Nicht-Spam-Mails, die als Spam erkannt werden) mit dabei. Nur ein brauchbares Training mit mindestens 100 bis 200 von Hand klassifizierten Mails hilft da wirklich, und selbst dann fällt immer mal wieder ein Mail durch das Raster, weil die Spammer auch nicht auf den Kopf gefallen sind und ihre Texte entsprechend ändern. Einen 100%igen Filter gibt es nicht und wird es auch nie geben, es sei denn man läßt die Finger komplett von Mails und Internet generell.

Wenn du viele eigene Filter zur Spamfilterung benutzt, dann ist dein interner Spamfilter sehr wahrscheinlich wenig gut trainiert und klassifiziert dementsprechend auch mehr Mails falsch.
 
tboeckel   Nutzer

08.11.2007, 13:31 Uhr

[ - Direktlink - ] 		Thema: YAM und der Filter ....
Brett: Amiga, AmigaOS 4

So, der sehr wahrscheinliche Fehler ist gefixt und das nächste nightly build sollte auch unter OS3 wieder korrekt filtern. Probiers bitte mal aus.
 
tboeckel   Nutzer

08.11.2007, 11:55 Uhr

[ - Direktlink - ] 		Thema: YAM und der Filter ....
Brett: Amiga, AmigaOS 4

@R-TEAM:

Die Performance-Probleme sind eigentlich sehr erklärlich.

Erst mal eine Frage: wieviele Filter hast du insgesamt angelegt?

Denk bitte daran, daß jede Nicht-Spam-Mail jeden Filter komplett durchlaufen muß. Das frißt natürlich Zeit. Und je mehr Filter aktiv sind, desto umfangreicher ist die Überprüfung natürlich.

Dummerweise habe ich heute erst herausgefunden, daß unter OS3 der Logarithmus von sehr kleinen Werten, wie sie beim Spamfilter sehr häufig vorkommen, falsch berechnet wird, und Spam-Mails dann unnötigerweise als normale Mails angesehen werden. Darum entsteht bei dir wahrscheinlich der Eindruck, daß der Spamfilter nicht taugt.

Sobald wir den Fehler in den nightly builds wieder gefixt haben solltest du den normalen Spamfilter noch einmal ausprobieren und so viele eigene Filter wie möglich wieder deaktivieren/löschen.
 
tboeckel   Nutzer

15.10.2007, 16:17 Uhr

[ - Direktlink - ] 		Thema: Overflow berechnen
Brett: Programmierung

Zitat:
Das Prog ist Zeitkritisch und das timer.device im allgemeinen
sehr langsam.
Legentlich GetSysTime erlaubt ein Timing welches schneller als
12000 HZ ist.

AddTime() macht eigentlich nicht mehr als das hier:

void AddTime(struct TimeVal *dest, struct TimeVal *src)
{
dest->tv_sec = dest->tv_sec + src->tv_sec;
dest->tv_usec = dest->tv_nsec + src->tv_usec;
if (dest->tv_usec >= 1000000) {
// Ueberlauf
dest->tv_sec = dest->tv_sec + 1;
dest->tv_usec = dest->tv_usec - 1000000;
}
}

Analog für SubTime().

Das ist prinzipiell genau das, was du auch mindestens tun mußt. Wenn das bereits zu langsam ist, dann solltest du besser sofort aufhören. Du kannst gerne das Rad zum x-ten Male erfinden, aber deutlich schneller geht es dadurch immer noch nicht.
 
tboeckel   Nutzer

15.10.2007, 09:09 Uhr

[ - Direktlink - ] 		Thema: Overflow berechnen
Brett: Programmierung

@MaikG:

Wie wärs mit timer.device/AddTime() oder timer.device/SubTime()? Da werden alle Über- und Unterläufe der Mikrosekunden korrekt in die Sekunden einbezogen. Für genau sowas sind die Funktionen da.
 
tboeckel   Nutzer

02.10.2007, 10:57 Uhr

[ - Direktlink - ] 		Thema: Genesis-Problem
Brett: Amiga, AmigaOS 4

@Amaris:

Lesen macht "Ah". Kein freier Speicher mehr. Das ist auf dem Screenshot deutlich zu sehen (m_mclalloc: max amount of memory... (exceeded?)). Das Logbuch existiert mit Sicherheit auch noch als normale Textdatei. Da sollte dann auch die komplette Meldung drin stehen. Die Tatsache, daß in dem Moment reichlich große Bilder geladen werden sollten, spricht auch sehr für Speichermangel. 32MB sind wirklich nicht übertrieben viel.
 
tboeckel   Nutzer

17.09.2007, 15:41 Uhr

[ - Direktlink - ] 		Thema: Timing nochmal
Brett: Programmierung

@MaikG:

Für das sinnvolle "Vorausberechnen" der Zeit sollte man dann aber nicht UNIT_MICROHZ oder UNIT_ECLOCK, sondern UNIT_WAITUNITL oder UNIT_WAITECLOCK nehmen, je nachdem welche Zeitbasis einem besser gefällt. Die beiden Units warten nicht eine bestimmte Zeitspanne, sondern bis zu einem bestimmten Zeitpunkt. Den muß man sich vorher ausrechnen. Auf jeden Fall kann zwischen zwei Zyklen (fast) beliebig viel passieren ohne daß der eigene Rhythmus durch andere äußere Einflüsse aus dem Takt gebracht wird. Wurde in einem Zyklus mehr Zeit verbraucht als in den vorherigen, so löst das timer.device trotzdem noch zum richtigen Zeitpunkt aus, weil die Endzeit absolut und nicht relativ berechnet wurde.
 
tboeckel   Nutzer

29.06.2007, 12:34 Uhr

[ - Direktlink - ] 		Thema: tcp -> richtige Programmierung
Brett: Programmierung

@Ralf27:

YAM deckt mittlerweile so gut wie alles ab: Grafik, GUI, Netzwerk, etc. Den kompletten Source gibt es hier. Alles was mit TCP/IP und SSL zu tun hat wird hier behandelt.
 
tboeckel   Nutzer

21.06.2007, 12:52 Uhr

[ - Direktlink - ] 		Thema: Datatypes ohne Screen?
Brett: Programmierung

@geit:

Zur Not könnte man sich die Daten auch per PDTM_READPIXELARRAY besorgen. In welchem Format die dann aber jeweils vorliegen (LUT8, RGB, RGBA, etc) weiß ich auch nicht. Kannst ja mal in die Sourcen von TheBar.mcc sehen. Da werden die Bilder auch über die Datatypes geladen und dann mit PDTM_READPIXELARRAY weiter bearbeitet.
 
tboeckel   Nutzer

21.06.2007, 12:45 Uhr

[ - Direktlink - ] 		Thema: Datatypes ohne Screen?
Brett: Programmierung

@geit:

Der Screen gibt meines Wissens nur an, anhand welchen Screens die Farben gemappt werden sollen, falls kein Fenster benutzt wird. Ich kann allerdings momentan nicht sagen, ob PDTM_PROCLAYOUT ohne Screen und ohne Fenster erfolgreich ist. Falls ja, dann sollte PDTA_UseFriendBitMap=TRUE helfen. Aber ohne Bezug (kein Screen, kein Fenster) dürfte das eher schlecht aussehen. Warum müssen es denn unbedingt fried-Bitmaps sein? Per BltBitmapRastport() sollten sich doch beliebige Bitmaps malen lassen.
 
tboeckel   Nutzer

30.05.2007, 14:31 Uhr

[ - Direktlink - ] 		Thema: YAM2.4 auf 2.5 - Welche Konfig-Dateien übenehmen?
Brett: Amiga, AmigaOS 4

Zitat:
also langsam wirds aber doch auch mal zeit fuer nen release oder ?

Hilf mit entwickeln, dann geht's schneller! Wir sind nur zwei Leute, die aktiv an YAM in unserer Freizeit arbeiten!
 
tboeckel   Nutzer

29.05.2007, 11:55 Uhr

[ - Direktlink - ] 		Thema: YAM2.4 auf 2.5 - Welche Konfig-Dateien übenehmen?
Brett: Amiga, AmigaOS 4

@Reth:

1. YAM 2.5 ist bisher noch Beta bzw die verfügbaren Versionen sind "nightly builds" und können durchaus Fehler enthalten.

2. Das einfachste ist es eine lauffähige YAM 2.4 Installation zu nehmen und die Dateien aus den nightly build Archiven darüber zu entpacken. Dann hat man alles nötige, bzw YAM wird einem schon sagen, wenn etwas fehlt. Alternativ kann man auch komplett ohne Konfigurationsdateien starten. YAM legt dann alles nötige selbst an.

3. Für solche Fragen wären eigentlich die YAM Mailingliste oder das YAM Forum sehr viel geeigneter, weil es da weitaus mehr Leute gibt, die YAM 2.5dev schon sehr lange benutzen.

Grundsätzlichen kann ich jedem nur die YAM FAQ nahe legen.
 
tboeckel   Nutzer

05.01.2007, 10:39 Uhr

[ - Direktlink - ] 		Thema: IBrowse 2.4 Fenstergröße
Brett: Amiga, AmigaOS 4

@Bluebird:

Exakt
 
tboeckel   Nutzer

05.01.2007, 08:33 Uhr

[ - Direktlink - ] 		Thema: IBrowse 2.4 Fenstergröße
Brett: Amiga, AmigaOS 4

@Reth:

Wie wäre es mit "Snapshot"?

"remember on exit" bedeutet nur, daß die momentanen Dimensionen in ENV: gespeichert werden, aber nicht in ENVARC:. Ohne das bekommt ein Fenster bei jedem Öffnen seine Standardgröße.
 
tboeckel   Nutzer

11.07.2006, 09:38 Uhr

[ - Direktlink - ] 		Thema: Wie erstellt man eine Library in C?
Brett: Programmierung

Zitat:
Also nochmal ganz langsam: wenn eine Bibliothek eine Einschränkung, die bis dato gar nicht existierte, nicht erzwingt, sondern einfach nur funktioniert, ist es ein Fehler der Bibliothek?

Ob sie existierte oder nicht kann ich nicht sagen. Diese Beschränkung war wohl nur den C=-Entwicklern wirklich klar, bzw sie sind davon ausgegangen, daß niemand auf die Idee kommt single und double precision zu mischen. Ich wußte bislang auch nur, daß die Basisadressen nicht von unterschiedlichen Tasks benutzt werden dürfen.

Nur, wenn sich Bibliothek A und B gegenseitig ausschließen (warum auch immer), aber weder A noch B prüfen, ob der jeweils andere Part aktiv ist, und trotzdem "so in etwa" funktionieren, dann ist das definitv ein Fehler, weil ein normaler Benutzer zunächst nicht unbedingt etwas davon bemerkt. Und auf der Seite des Entwicklers sind solche Fehler zu weilen unmöglich nachzuvollziehen, weil sie in diesem Fall sehr stark vom verwendeten Prozessor abhängen.

Bei den Mathebibliotheken mag man als Ausrede anbringen, daß ja nur die Rundung falsch wird, aber selbst das kann unvorhersehbare Folgen haben, weswegen so etwas von Anfang an verhindert werden sollte.

Zitat:
Zitat:
Sie kann es nicht wissen. Aber dann darf ein Task auch nicht gleichzeitig beide Bibliothekstypen öffnen dürfen. Da fehlt dann halt eine entsprechende Abfrage, die das Öffnen scheitern läßt. Das wäre eine ganz legale Technik.
Was soll das heißen, da fehlt eine Abfrage? Vor AOS3.9 gab es diese Einschränkung, daß man sie nicht gleichzeitig benutzen dürfe, überhaupt nicht. Wieso sollten diese Bibliotheken etwas abfragen?

Weil sie sich gegenseitig ausschließen, zumindest dann, wenn sie auf einem Prozessor mit FPU und im gleichen Task verwendet werden. Diese Eigenschaft ist mir allerdings auch erst seit dieser Diskussion bekannt. Bislang wußte ich nur von der task-bezogenen Benutzung.

Zitat:
Zitat:
Aber wer sagt, denn daß die Mathe-Bibliotheken nicht noch einen anderen Weg benutzen, um verschiedene Tasks unterscheiden zu können.
Wer?!
Na DU:
Zitat:
http://www.amiga-news.de/forum/thread.php?id=23201&BoardID=7#231681
Spätestens ab OS2.x war es dann dokumentiert, daß ein OpenLibrary("mathieeesingbas.library",0) eine task-spezifische Basisadresse liefert.

Wo ist der Widerspruch? Es ist die Aufgabe der Mathbibliotheken verschiedene Tasks unterscheiden zu können. Wie sie das machen, braucht niemanden zu interessieren. Hauptsache ist sie machen es korrekt. Ich gebe aber zu, daß ich den Autodocs und der gesamten weiteren Dokumentation auf den Developer-CDs eine Aussage unterstellt habe, die es lange nicht bzw nie so richtig gegeben hat. Mein Fehler.

Zitat:
Und nachdem Du behauptest hast, daß es so "schon ab OS2.0" dokumentiert wäre, kommt jetzt das:
Zitat:
Hat denn überhaupt jemand behauptet, daß die Autodocs die Bibel sind, und daß alles, was da nicht drin steht, auch nicht sein darf? Auch die Autodocs sind nicht fehlerfrei und geben teilweise sehr unorthodoxe Beispiele mit auf den Weg.

Eben noch war es seit OS2.0 dokumentiert, daß es so ist, jetzt kann es so sein, muß aber nicht, und kann auch mal in der Dokumentation fehlen...

Was denn nun?

Ok, ich gebe zu, daß es nicht in den Autodocs dokumentiert ist. Das wurde erst mit OS3.9/OS4 nachgeholt. Es ist auch nicht in den Autodocs dokumentiert, daß eine Basisadresse nicht von >= 2 Tasks gleichzeitig benutzt werden darf. Das steht nur in einigen wenigen Beispielprogrammen in einer Randnotiz. Ich habe diese Information irgenwann in den letzten Jahren aufgeschnappt und sie seit dem verinnerlicht. Die Tatsache, daß es nicht explizit dokumentiert ist, ist mir auch erst jetzt aufgefallen. Es ist halt irgendwie "allgemein bekannt", daß manche Bibliotheken nur task-gebunden benutzt werden dürfen. Wenn man dieses "Wissen" hat, dann kontrolliert man es nicht jedes Mal, sondern benutzt es einfach. Mein Fehler.
 
tboeckel   Nutzer

11.07.2006, 09:09 Uhr

[ - Direktlink - ] 		Thema: Wie erstellt man eine Library in C?
Brett: Programmierung

Zitat:
Original von Holger:
Zitat:
... Es gibt mehr Gründe als nur die reine Abwesenheit einer Bibliothek, warum OpenLibrary() fehlschlagen kann. Der unmögliche Mix aus mathieeesing#? und mathieeedoub#? gehört nun mal dazu.
...
Zitat:
Ist das auch schon immer so gewesen?

Zumindest so lange wie ich unter AmigaOS programmiere, und das sind mittlerweile knapp 20 Jahre.
Aha, Du weißt das also schon seit 20 Jahren. Und wie kam dann folgendes Posting zustande?!:
Zitat:
http://www.amiga-news.de/forum/thread.php?id=23201&BoardID=7#231681
Lies diesen Satz noch mal mit ganz viel Verstand von vorne bis hinten durch. Da steht nichts davon drin, daß man die mathieeesing#? und die mathieeedoub#? nicht gleichzeittig verwenden darf.

Die 20 Jahren bezogen sich auf das erlaubte Fehlschlagen von OpenLibrary(). Das war schon immer so. Ich hätte wohl besser noch ein "scheinbar" in dem darauf folgenden Satz schreiben sollen.

Außerdem bezog sich meine Antwort auf das Verwenden der gleichen Basisadresse in unterschiedlichen Tasks. Bis dahin war nie von einem gewollten Mix aus single und double precision die Rede.
 
tboeckel   Nutzer

10.07.2006, 22:07 Uhr

[ - Direktlink - ] 		Thema: Wie erstellt man eine Library in C?
Brett: Programmierung

Zitat:
Original von Holger:
Ein Verhalten, das vielleicht bei ein paar Entwicklern hinter vorgehaltener Hand weitererzählt wird, ist keine Spezifikation.

Abgesehen davon, mag es vielleicht sogar so sein, daß irgendwer mal gesagt hat, daß die Library-Base nicht zwischen tasks weitergereicht werden darf. Trotzdem stehen in der aktuellen Fassung der Dokumentation plötzlich Dinge wie, daß man nicht mathieeesing... und mathieeedoub... gleichzeitig verwenden kann, weil es sonst Probleme gibt, sprich, die Berechnung in der falschen Genauigkeit durchgeführt werden könnte.

Es steht auch nirgendwo, daß es erlaubt ist. Heißt das jetzt, daß beides falsch oder beides richtig ist?

Es gibt einen guten Grund, warum man das Ergebnis von OpenLibrary() und vergleichbaren Funktionen immer prüfen sollte. Nichts und niemand in einem Multitasking-System garantiert einem, daß immer alles korrekt funktioniert. Es gibt nur beschränkte Resourcen, und die müssen sich alle teilen. Es gibt mehr Gründe als nur die reine Abwesenheit einer Bibliothek, warum OpenLibrary() fehlschlagen kann. Der unmögliche Mix aus mathieeesing#? und mathieeedoub#? gehört nun mal dazu.

Zitat:
Und daß man NULL zurückbekommen könnte, wenn man die Bibliothek ein zweites Mal öffnet (eine Katastrophe für einen Library-Entwickler, der nicht wissen kann, ob der Aufrufer die Bibliothek schon einmal geöffnet hat)...

OpenLibrary() darf definitiv NULL zurückgeben, wenn es meint, daß eine Bibliothek (warum auch immer) nicht geöffnet werden konnte. Man erhält zwar keine weiteren Informationen, warum das Öffnen nicht geklappt hat, aber man darf auch nicht davon ausgehen, daß man jede Bibliothek unter allen Umständen mehr als 1x erfolgreich öfnnen kann.

Zitat:
Ist das auch schon immer so gewesen?

Zumindest so lange wie ich unter AmigaOS programmiere, und das sind mittlerweile knapp 20 Jahre.

Zitat:
Und wenn das alles schon immer so war, daß math-libs innerhalb einer Bibliothek aufgrund dieser Einschränkungen praktisch nicht verwendet werden können, wieso hat es eine Woche gedauert, bis es jemanden aufgefallen ist?

Vielleicht weil die Verwendung dieser Bibliotheken mittlerweile etwas ins Hintertreffen geraten ist? Kaum jemand benutzt noch einen nackten 68020 oder gar 68000. Alles unter 68040, besser noch unter 68060, ist zu langsam. Und die Dinger haben eine FPU, so daß man die Mathelibs nicht mehr braucht.
 
tboeckel   Nutzer

10.07.2006, 22:05 Uhr

[ - Direktlink - ] 		Thema: Wie erstellt man eine Library in C?
Brett: Programmierung

Zitat:
Original von Holger:
Wie Du vielleicht siehst, geht es hier um Library-Programmierung. Und in einer Library hat man keinen Einfluß darauf, was der Aufrufer noch so alles macht. Wenn Du Dir die Dokumentation mal durchliest, auch bzgl. dessen, was in diesem kleinen Zitat nicht erwähnt wurde, z.B. über das Verhalten bei mehrmaligen Öffnen und eben der Sache mit dem Mischen von single- und double precision, dann wird Dir vielleicht auch klar, das damit das Benutzen der math-libs aus einer Bibliothek unmöglich geworden ist.

Es ist das gute Recht von OpenLibrary() NULL zurückzuliefen, selbst wenn die gleich Bibliothek vorher bereits erfolgreich geöffnet wurde. Und wenn sich single und double precision gegenseitig ausschließen und dies von libOpen() der Mathe-Bibliotheken nicht korrekt erkannt wird, dann ist das ein Fehler der Bibliotheken.

Zitat:
Woher soll Bibliothek a wissen, ob eine Bibliothek b, vom gleichen Task geöffnet, eine andere math-Bibliothek öffnet?

Sie kann es nicht wissen. Aber dann darf ein Task auch nicht gleichzeitig beide Bibliothekstypen öffnen dürfen. Da fehlt dann halt eine entsprechende Abfrage, die das Öffnen scheitern läßt. Das wäre eine ganz legale Technik.

Zitat:
Das meinst Du... Ich habe gerade testweise auf meinem System von mehreren Tasks die math-libs öffnen lassen, und alle bekommen dieselbe Basisadresse.

Task-spezifische Basisadressen sind eine Möglichkeit. Aber wer sagt, denn daß die Mathe-Bibliotheken nicht noch einen anderen Weg benutzen, um verschiedene Tasks unterscheiden zu können. Sofern das überhaupt unter allen Umständen nötig ist. Wie gesagt, OpenLibrary() darf eine task-spezifische Adresse liefern, es muß aber nicht.

Zitat:
In den Dokumentationen der Bibliotheken steht, wie gesagt, bis AOS3.5 nichts dazu. Und die "AmigaMails" durchforsten zu müssen, um so etwas zu erfahren, kann man nicht Dokumentation nennen. Abgesehen davon, daß selbst Commodore im Vorwort zum Archiv sagt, daß man nicht alles, was da drin steht, für bare Münze nehmen sollte.

Hat denn überhaupt jemand behauptet, daß die Autodocs die Bibel sind, und daß alles, was da nicht drin steht, auch nicht sein darf? Auch die Autodocs sind nicht fehlerfrei und geben teilweise sehr unorthodoxe Beispiele mit auf den Weg. Die Dinger wurden seit Jahren nicht gepflegt. Es fehlen halt Erklärungen für Dinge, die man besser wissen sollte. Das OS4-SDK enthält teilweise sehr stark modernisierte Autodocs, welche dann auch eben solche Sachen endlich mal klarstellen. Aber es muß auch Leute geben, die so etwas dokumentieren. Das wurde halt jahrelang versäumt. Typische C=-Politik!
 
tboeckel   Nutzer

10.07.2006, 18:41 Uhr

[ - Direktlink - ] 		Thema: Wie erstellt man eine Library in C?
Brett: Programmierung

@Holger:
Zitat:
The library base of the mathieeesingbas.library MUST NOT be shared among tasks.
Lies diesen Satz noch mal mit ganz viel Verstand von vorne bis hinten durch. Da steht nichts davon drin, daß man die mathieeesing#? und die mathieeedoub#? nicht gleichzeittig verwenden darf.

Der Satz besagt nur, daß du in einem multi-threaded Programm die Bibliotheken in JEDEM Subtask öffnen mußt, bevor der Subtask sie benutzen darf. Der alte Trick, daß das Hauptprogramm alle Bibliotheken öffnet und alle weiteren Subtasks munter dieselben Basisadressen verwenden, klappt nämlich genau bei sämtlichen math#?.library NICHT. Das ist hier mit shared among tasks gemeint.

Ich meine dieses Verhalten wäre bereits unter OS1.3 so gewesen, wo so langsam die ersten Turbokarten mit FPU in Mode kamen. Spätestens ab OS2.x war es dann dokumentiert, daß ein OpenLibrary("mathieeesingbas.library",0) eine task-spezifische Basisadresse liefert.

Dieses Verhalten ist bereits auf der Developer-CD 1.1 von 1996 in den AmigaMails vol 1 dokumentiert, und die sind von 1990!
 
tboeckel   Nutzer

28.06.2006, 10:44 Uhr

[ - Direktlink - ] 		Thema: Fließkommazahlen in Library
Brett: Programmierung

@Micha1701:

natürlich darf man Link-Libraries benutzten, nur nicht alle Funktionen davon. Generell darf alles verwendet werden, was keinen impliziten Kontext bzw die Laufzeitumgebung braucht und alles, was thread-safe ist. D.h. Divisionen/Multiplikationen dürfen auf jeden Fall verwendet werden, ebenso die str#? Funktionen.

NICHT verwendet werden darf zB jede Art von I/O (open, read, write, printf, etc) und die Speicherverwaltung (malloc, free), weil dafür die nötigen Strukturen durch den nicht vorhandenen Startup-Code nicht initialisiert worden sind. Für solche Fälle muß man den direkten Ersatz vom AmigaOS (dos/Open/Read/Write, exec/AllocMem/FreeMem, etc) benutzen.

Mit Sicherheit gibt es noch eine Reihe weiterer Funktionen, die in shared libraries benutzt bzw nicht benutzt werden dürfen, aber die beschriebenen sind die, die man am ehesten benutzen möchte.
 
tboeckel   Nutzer

25.04.2006, 10:10 Uhr

[ - Direktlink - ] 		Thema: Unterschiedliche Versionsangaben von gleicher Datei?
Brett: Amiga, AmigaOS 4

@Festus:

C:Version nutzt, falls bereits geladen, die Daten im Speicher. WB/Information nimmt immer die Daten aus der Datei. Wenn du also bereits eine (ältere) Bibliothek geladen hast und dann anschließend auf der Platte ersetzt, dann bekommst du genau das angezeigt. Im Speicher liegt die alte Version, auf der Platte die neue. Darum gibt's bei C:Version auch die Option "FILE". Damit zwingt man das Programm wirklich die angegebene Datei (evtl sogar mit Pfad) nach Versionsinformationen zu durchsuchen.
 
tboeckel   Nutzer

18.04.2006, 09:22 Uhr

[ - Direktlink - ] 		Thema: OS4 und MUI
Brett: Programmierung

Zitat:
Original von geit:
Error 21: main.o (.text+0x150): Reference to undefined symbol IDoMethod.
Error 21: libasyncM.a(gui.o) (.text+0x98): Reference to undefined symbol MUI_DisposeObject.
Error 21: internal_mui.o (.text+0xf0): Reference to undefined symbol MUI_NewObjectA.
Error 21: internal_mui.o (.text+0x110): Reference to undefined symbol MUI_NewObject.
Error 21: internal_mui.o (.text+0x1bc): Reference to undefined symbol MUI_DisposeObject.
Error 21: internal_mui.o (.text+0x260): Reference to undefined symbol MUI_MakeObject.
Error 21: internal_mui.o (.text+0x330): Reference to undefined symbol MUI_NewObject.

Sieh dir mal die Makefiles und Sourcen von Scout oder YAM an. Da werden in den Makefiles manche Sachen umdefiniert. Ich kann sowohl Scout als auch YAM problemlos mit dem gcc compilieren.
 
tboeckel   Nutzer

27.07.2005, 10:53 Uhr

[ - Direktlink - ] 		Thema: Probleme mit SCSI und IBM Festplatte
Brett: Amiga, AmigaOS 4

Zitat:
Eigentlich sollte das MoBo-Ram ja nichts ausmachen.

Warum nicht? Es ist da, es darf benutzt werden. Und nur weil es erst dann verwendet wird, wenn nichts anderes mehr frei ist, heißt nicht, daß es nie verwendet wird. Und wenn dummerweise Kontrollstrukturen in genau diesem kaputten Bereich gelagert und später wieder auf die Platte zurück geschrieben werden, dann ist der Platteninhalt ebenso kaputt.

Da hilft auch kein Glauben und kein Hoffen. Kaputtes RAM sorgt nicht nur für fehlerhafte Daten im Speicher!

Zitat:
Im Aminet gibt es ein Tool das nennt sich glaub MemCheck.
Laut diesem Tool sind auf einem 4MB Riegel ein paar Blöcke
defekt. Allerdings erzeugt dieses Tool eine ausführbare
Datei die sich MemPatch nennt. Diese muss man vor Setpatch
einbinden.
Wenn man nun nochmal das Checkprogramm startet, findet er
keine Fehler mehr, da die defekten und markierten Bloecke
uebersprungen werden.

Wusste auch nicht das es so geniale Tools gibt. :) Aber
vielleicht ist das ja die Lösung wenn die anderen Sachen nicht
greifen.

Die Lösung ist kurzfristig und genaugenommen ein Hack. Wer sagt dir denn, daß dieser Speicher wirklich immer als belegt gekennzeichnet werden kann? Ich habe früher zwar selbst mal so ein Programm geschrieben, weil von den 2MB auf dem alten GVP genau 1,5K kaputt waren. Das Programm hat dann diese 1,5K per AllocAbs() belegt und nie wieder freigegeben. Aber selbst AllocAbs() kann und darf fehlschlagen.

Außerdem lohnt es sich die Anleitung zu lesen:
Zitat:
In the long term, you should consider replacing any memory
which MemCheck declares to be faulty.
 
 
1 2 3 -4- 5 Ergebnisse der Suche: 124 Treffer (30 pro Seite)

Suchbegriffe
Schlüsselwörter      Benutzername
Suchoptionen
Nur in diesen Foren suchen
   nur ganze Wörter
Nur Titel anzeigen
alle Treffer anzeigen

.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.