amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > Fehlersuche [ - Search - New posts - Register - Login - ]

-1- [ - Post reply - ]

2007-12-30, 16:08 h

Ralf27
Posts: 2779
User 		Ich hab vor einiger Zeit am RSS-Reader gearbeitet. Am Anfang hab ich die Fenster von MaxonBasic benutzt, bin dann aber auf die Systemfenster umgestiegen. Somit mußte ich auch die gesamte Ereignissverarbeitung an Intuition abgegeben, bzw. benutze jetzt das System statt MaxonBasic.

Jetzt kommt es aber, das das Programm ab und an einfach einfriert und das wars dann. Ich weiß einfach nicht woran das liegt.
Deswegen hab ich auch damals die Weiterentwicklung eingestellt.

Jetzt will ich aber denn Fehler finden und auch einige weitere Probleme beseitigen, bzw. erweitern. Aber ich kann denn Fehler einfach nicht eingrenzen.

Ich hab hier einfach mal denn kompletten(!) Quellcode auf meine Homepage gelegt. Mir ist auch klar, das da z.b. die Signalverarbeitung noch nicht so ganz nach "Systemvorschrift" abläuft und das da bestimmt noch einige andere Bugs drin sind. Das Programm sieht auch noch etwas durcheinander aus und ist mit ca. 20kb auch nicht gerade kurz für eine Fehlersuche...

Schaut es euch bitte einfach mal an und vielleicht findet sogar jemand denn oder die Bug(s).

Downloadlink: http://home.pages.at/a1260/RSS-Reader_test.bas
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2007-12-30, 17:14 h

thomas
Posts: 7718
User
Wenn du vermutest, daß das Programm bei dem Wait anhält, dann solltest du zum einen vor dem Wait mal die Signale ausgeben. Ein Wait(0) bringt das Programm für alle Ewigkeiten zum Warten. Und du könntest zu den ganzen Signalen auch noch SIGBREAKF_CTRL_C hinzufügen, dann kannst du das Wait einfach mit Ctrl-C unterbrechen.

Darüberhinaus könntest du mit einem System-Monitor wie ARTM prüfen, auf welche Signale dein Programm wartet. ARTM kann auch ein Signal an die Task senden.

Überhaupt ist in dem Programm kein einziges Print zu finden. Wenn ich einen Fehler suche, dann versuche ich wenigstens den Programmteil einzugrenzen, in dem er sich befindet. Mit einfachen Vermutungen kommst du nicht schnell voran.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Answer - Quote - Direct link - ]
2007-12-30, 17:38 h

Ralf27
Posts: 2779
User
Zitat:
Original von thomas:

Wenn du vermutest, daß das Programm bei dem Wait anhält, dann solltest du zum einen vor dem Wait mal die Signale ausgeben. Ein Wait(0) bringt das Programm für alle Ewigkeiten zum Warten. Und du könntest zu den ganzen Signalen auch noch SIGBREAKF_CTRL_C hinzufügen, dann kannst du das Wait einfach mit Ctrl-C unterbrechen.
Ich hatte auch mal testweise ein REM vor diese Zeile gesetzt um zu testen ob es daran liegt. Aber leider liegt es wohl nicht daran.
Aber die Idee mit SIGBREAK_CTRL_C werd ich auch noch einbauen. Sicher ist sicher.
Zitat:
Darüberhinaus könntest du mit einem System-Monitor wie ARTM prüfen, auf welche Signale dein Programm wartet. ARTM kann auch ein Signal an die Task senden.
Es scheint wohl leider nicht am Wait zu liegen. Auch wenn ich es ausklammer, bzw. ein REM davorsetze, hängt irgendwann das ganze Programm.
Zitat:
Überhaupt ist in dem Programm kein einziges Print zu finden. Wenn ich einen Fehler suche, dann versuche ich wenigstens den Programmteil einzugrenzen, in dem er sich befindet. Mit einfachen Vermutungen kommst du nicht schnell voran.
Da hast du natürlich recht. Ich hab hier schon einiges versucht, wollte aber nicht alles hier im Quellcode drin lassen.

Es könnte auch am CloseWindow liegen, aber das ist leider auch nur eine Vermutung. Ich hab was gelesen vom "sicheren schliesen", aber das verursacht bei mir einen Absturz (?). Hab es deswegen auch in REM-Zeilen ausgeklammert.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2007-12-31, 00:03 h

thomas
Posts: 7718
User 		@Ralf27:

Zitat:
Ich hab was gelesen vom "sicheren schliesen", aber das verursacht bei mir einen Absturz (?)

Zitat:
REM Forbid
REM msg&=1
REM Port&=PEEKL(win&+UserPort%)
REM WHILE msg&
REM msg&=GetMsg&(Port&)
REM IF msg& THEN ReplyMsg msg&
REM WEND
REM POKEL win&+UserPort%,0
REM junk=ModifyIDCMP(win&,0)
REM Permit


Sorry, aber *das* hat nichts mit CloseWindowSafely zu tun. Das offenbart nur, daß du nicht verstanden hast, wie CloseWindowSafely funktioniert und wofür es gut ist.

Du brauchst das nicht. CloseWindowSafely braucht man nur, wenn man den gleichen Message-Port für alle Fenster benutzt. Du hast aber für jedes Fenster einen eigenen Port.

Den Absturz bekommst du, weil du nicht abfragst, ob überhaupt ein Port da ist. Und beim Schnließen von testwin, welches keinen IDCMP hat, ist Port NULL und führt bei GetMsg(Port) zum Absturz.

Zitat:
Es könnte auch am CloseWindow liegen, aber das ist leider auch nur eine Vermutung.

Wenn du eine konkrete Vermutung hast, dann läßt die sich doch ganz einfach bestätigen: mach vor dem CloseWindow ein Print und danach auch und wenn nur das erste rauskommt, dann hängt's am CloseWindow. Wenn nicht, dann nicht.

Finde doch erstmal heraus, wo es hängt. Dann kannst du dir eine Lösung überlegen.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Answer - Quote - Direct link - ]
2007-12-31, 00:39 h

Ralf27
Posts: 2779
User
Zitat:
Original von thomas:
@Ralf27:

Zitat:
Ich hab was gelesen vom "sicheren schliesen", aber das verursacht bei mir einen Absturz (?)

Zitat:
REM Forbid
REM msg&=1
REM Port&=PEEKL(win&+UserPort%)
REM WHILE msg&
REM msg&=GetMsg&(Port&)
REM IF msg& THEN ReplyMsg msg&
REM WEND
REM POKEL win&+UserPort%,0
REM junk=ModifyIDCMP(win&,0)
REM Permit


Sorry, aber *das* hat nichts mit CloseWindowSafely zu tun. Das offenbart nur, daß du nicht verstanden hast, wie CloseWindowSafely funktioniert und wofür es gut ist.

Du brauchst das nicht. CloseWindowSafely braucht man nur, wenn man den gleichen Message-Port für alle Fenster benutzt. Du hast aber für jedes Fenster einen eigenen Port.

Den Absturz bekommst du, weil du nicht abfragst, ob überhaupt ein Port da ist. Und beim Schnließen von testwin, welches keinen IDCMP hat, ist Port NULL und führt bei GetMsg(Port) zum Absturz.
In der Tat hab ich das nicht verstanden, bzw. hatte ich das auch noch in keinem Programm benutzt und als ich halt mal bei CloseWindow() dieses CloseWindowSafely gesehn habe, hab ich es einfach mal versucht.
Ich war mir da auch relativ (aber nicht zu 100%) sicher, das es damit nix zu tun hat. Deswegen auch in REMs.
Mir ist aber auch klar das Vermutungen beim Programmieren nicht das Gelbe vom Ei sind. Ist eher eine Verzweiflungstat...
Zitat:
Zitat:
Es könnte auch am CloseWindow liegen, aber das ist leider auch nur eine Vermutung.

Wenn du eine konkrete Vermutung hast, dann läßt die sich doch ganz einfach bestätigen: mach vor dem CloseWindow ein Print und danach auch und wenn nur das erste rauskommt, dann hängt's am CloseWindow. Wenn nicht, dann nicht.

Finde doch erstmal heraus, wo es hängt. Dann kannst du dir eine Lösung überlegen.
Genau daran hängt es, das ich das nicht finde. Ich bin aber gerade dabei etwas denn Code zu überarbeiten, bzw. zusammenfassen, etc.

Irgendwo in dem Programm muß sowas wie ein Illegaler Zugriff statt finden.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2007-12-31, 02:48 h

RhoSigma
Posts: 67
User 		Hallo, gute Nacht wünsch ich schon mal, denn wenn ich das hier fertig geschrieben habe, dann gehe ich ins Bett :)

Also das hört sich ganz nach dem gleichen Problem an, das ich vor ca. 2 Jahren mit meinem MakeHTMLMap Projekt hatte, da blieb das Programm auch manchmal mittendrin sang und klanglos hängen ohne Fehler ohne Absturtz, nur das Proggi eben.

Des Rätsels Lösung war, daß sich der Garbage Collector von MaxonBasic in bestimmten Situationen offensichtlich festfährt, da du in deinem Programm auch einige Arrays benutzt und Strings sowiso, und diese auch in diversen Schleifen immer wieder mal verändert werden, wodurch ja immer wieder neue temporäre Objekte auf dem Heapspeicher von Basic erzeugt werden (sprich diesen langsam aber sicher aufbrauchen), könnte dieses Problem bei dir auftauchen.

Um dies mal zu überprüfen, solltest du mal einen PRINT FRE(0) in deine Hauptschleife setzen. Da du nun aber keine Basicfenster mehr
verwendest, müstest du dazu zeitweise eben doch mal wieder eins öffnen, der Rest sollte ja trotzdem weiter in deinem Programmfenster landen. Der Befehl gibt nun bei jedem Schleifendurchlauf die größe des noch freien Heapspeichers aus, dabei wirst du feststellen, daß dieser mehr oder weniger abnimmt, dann sprunghaft mal wieder größer wird und wieder abnimmt etc.. Der sprunghafte Anstieg zeigt, daß gerade eine Garbage Collection (Müllsammlung) stattgefunden hat bzw. daß die HEAPDYNAMIC Funktion einen neuen Block alloziert hat. Der
Punkt ist nun folgender, wenn dein Programm einfriert, nachdem der letzte ausgegebene Wert sich nahe gegen Null genährt hat und eigentlich wieder ein entsprechender Anstieg zu erwarten wäre, dieser aber nicht kommt, dann wirds wohl tatsächlich am Garbage Collector liegen, und dann kannst du in deinem eigenen Code auch lange und vergeblich nach einem Fehler suchen ;(

Wenn das nun zutrifft, dann kannst du mal versuchen das Programm mit einer höheren HEAPDYNAMIC Einstellung zu kompilieren, wenn das nichts hilft bzw. den Hänger nur eine Weile hinauszögert dann füge einfach den folgenden Codeblock in deine Hauptschleife mit ein, seitdem ich das bei meinem Programm getan habe, läuft es einwandfrei. Meine Standardwerte für die Compilereinstellungen stehen oben drüber:

code:
' alte Heapgröße = 0KB   /  dyn. Heapgröße = 128KB
' mindest. Stack = 4096B /  mathem. Stack  = 256B

    '-------------------------------------
    ' workaround Garbage Collector hangup
    '-------------------------------------
    IF FRE(0)<500 THEN                               ' Platz auf BASIC-Heap < 500 Bytes ??
        gcTmp$=""                                        ' dann temporären $ vom letzen mal löschen
        tmp&=FRE("")                                     ' und Garbage Collection erzwingen
        IF FRE(0)<500 THEN                               ' immer noch weniger 500 Bytes ??
            WHILE FRE(0)<60000&                              ' dann temp-$ wieder vergrößern,
                gcTmp$=gcTmp$+STRING$(1000,CHR$(0))          ' bis die HEAPDYNAMIC Funktion
            WEND                                             ' einen neuen Block alloziert.
            IF FRE(-1)>262144& THEN                          ' wenn genug freier Systemspeicher,
                POKEL SYSTAB+44,(PEEKL(SYSTAB+44)+65536&)    ' dann Limit für nächste GaCol erhöhen
            ELSE
                tmp&=SetIoErr&(103&)                     ' sonst OutOfMemory
                ERROR 7                                  ' kannste mit ON ERROR GOTO über eine
            END IF                                       ' Aufräumfunktion sauber zum ProgEnde
        END IF                                           ' leiten
    END IF
    '-------------------------------------

P.S. Probleme mit Compileroptionen bemerkt ?? - dann guck dir auch mal mein MBPrefs (Aminet) an...

[ - Answer - Quote - Direct link - ]
2007-12-31, 17:25 h

Ralf27
Posts: 2779
User
Zitat:
Original von RhoSigma:
Also das hört sich ganz nach dem gleichen Problem an, das ich vor ca. 2 Jahren mit meinem MakeHTMLMap Projekt hatte, da blieb das Programm auch manchmal mittendrin sang und klanglos hängen ohne Fehler ohne Absturtz, nur das Proggi eben.
Ist schon irgendwie seltsam, aber vor ca. 2-3 Jahren hab ich auch so ein Programm geschrieben, auch in MaxonBasic. Es war recht gut (für meine Verhältnisse), hab es aber leider durch meinen Festplattencrash damals verloren, sonst wäre es auch auf meiner Page.
Zitat:
Des Rätsels Lösung war, daß sich der Garbage Collector von MaxonBasic in bestimmten Situationen offensichtlich festfährt, da du in deinem Programm auch einige Arrays benutzt und Strings sowiso, und diese auch in diversen Schleifen immer wieder mal verändert werden, wodurch ja immer wieder neue temporäre Objekte auf dem Heapspeicher von Basic erzeugt werden (sprich diesen langsam aber sicher aufbrauchen), könnte dieses Problem bei dir auftauchen.
Das Programm benutzt eigentlich recht wenige Strings, etc. Wenn ich da an Sudoku denke, da ist das Programm wesentlich länger.
Ich denk einfach, das es daran nicht liegt, bzw. bin mir eigentlich nur zu 99% sicher, aber nicht ganz. Aber ich werde das auch mal testen.
Zitat:
Um dies mal zu überprüfen, solltest du mal einen PRINT FRE(0) in deine Hauptschleife setzen. Da du nun aber keine Basicfenster mehr
verwendest, müstest du dazu zeitweise eben doch mal wieder eins öffnen, der Rest sollte ja trotzdem weiter in deinem Programmfenster landen. Der Befehl gibt nun bei jedem Schleifendurchlauf die größe des noch freien Heapspeichers aus, dabei wirst du feststellen, daß dieser mehr oder weniger abnimmt, dann sprunghaft mal wieder größer wird und wieder abnimmt etc.. Der sprunghafte Anstieg zeigt, daß gerade eine Garbage Collection (Müllsammlung) stattgefunden hat bzw. daß die HEAPDYNAMIC Funktion einen neuen Block alloziert hat. Der
Punkt ist nun folgender, wenn dein Programm einfriert, nachdem der letzte ausgegebene Wert sich nahe gegen Null genährt hat und eigentlich wieder ein entsprechender Anstieg zu erwarten wäre, dieser aber nicht kommt, dann wirds wohl tatsächlich am Garbage Collector liegen, und dann kannst du in deinem eigenen Code auch lange und vergeblich nach einem Fehler suchen ;(
Das liest sich sehr interesant und ist auch sehr interesant. Denn mit dieser Garbage Collector hab ich auch so meine Probleme. Wenn ich z.b. Fensternamen direkt angeben, bzw. als Zeichenkette direkt im Quellcode, dann kann es passieren, das auf einmal Datenmüll im Fenternamen erscheint. Deswegen muß ich leider auch dann extra dafür Speicher vom System anfordern um die Namen dorthin zu schreiben.
Zitat:
Wenn das nun zutrifft, dann kannst du mal versuchen das Programm mit einer höheren HEAPDYNAMIC Einstellung zu kompilieren, wenn das nichts hilft bzw. den Hänger nur eine Weile hinauszögert dann füge einfach den folgenden Codeblock in deine Hauptschleife mit ein, seitdem ich das bei meinem Programm getan habe, läuft es einwandfrei. Meine Standardwerte für die Compilereinstellungen stehen oben drüber:

code:
' alte Heapgröße = 0KB   /  dyn. Heapgröße = 128KB
' mindest. Stack = 4096B /  mathem. Stack  = 256B

    '-------------------------------------
    ' workaround Garbage Collector hangup
    '-------------------------------------
    IF FRE(0)<500 THEN                               ' Platz auf BASIC-Heap < 500 Bytes ??
        gcTmp$=""                                        ' dann temporären $ vom letzen mal löschen
        tmp&=FRE("")                                     ' und Garbage Collection erzwingen
        IF FRE(0)<500 THEN                               ' immer noch weniger 500 Bytes ??
            WHILE FRE(0)<60000&                              ' dann temp-$ wieder vergrößern,
                gcTmp$=gcTmp$+STRING$(1000,CHR$(0))          ' bis die HEAPDYNAMIC Funktion
            WEND                                             ' einen neuen Block alloziert.
            IF FRE(-1)>262144& THEN                          ' wenn genug freier Systemspeicher,
                POKEL SYSTAB+44,(PEEKL(SYSTAB+44)+65536&)    ' dann Limit für nächste GaCol erhöhen
            ELSE
                tmp&=SetIoErr&(103&)                     ' sonst OutOfMemory
                ERROR 7                                  ' kannste mit ON ERROR GOTO über eine
            END IF                                       ' Aufräumfunktion sauber zum ProgEnde
        END IF                                           ' leiten
    END IF
    '-------------------------------------

P.S. Probleme mit Compileroptionen bemerkt ?? - dann guck dir auch mal mein MBPrefs (Aminet) an...

Ist wirklich ein sehr interesantes Programm.
Ja, das mit den Compileroptionen, bzw. die Verschiebung im Menu ist mir auch schon aufgefallen. Ich gebe aber die Optionen immer alle im Quellcode selbst an, bzw. schalt ich immer alles ab was ich nicht brauch und schalt nur das an, was ich benötige. Das geht halt am besten im Quellcode.

MBasic hat aber auch noch einige andere kleine Besonderheiten, das z.b. Shiften langsamer sein kann als eine Ganzzahldivision, wenn der Ausdruck auch nur etwas komplizierter ist. Der Compiler baut da einfach viel zu viel drum herum, bzw. könnte man da bestimmt noch viel rausholen. Aber ich vermute mal, das Maxon da wohl nicht mehr viel machen wird...
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2008-01-01, 14:57 h

Ralf27
Posts: 2779
User 		Ich habe FRE(0) bei MaxonBasic noch nie eingesetzt, bzw. nicht in einer Hauptschleife. Ist schon interesant was da raus kommt. Der Basic-Heap sinkt ab bis fast auf null und dann geht der wieder rauf auf ca. 64kb. Und das wieder und wieder, wenn ich die einzelnen Punkte auf dem Fenster überfliege. Ist schon interesant.

Aber denn Fehler finde ich leider auch nicht.

Es könnte auch sein das es am IDCMP_MOUSEMOVE liegen könnte, denn das hab ich bis jetzt auch noch nie eingesetzt und das liefert auch ein ganz schönes Datengewitter.

Jedenfalls friert das Programm auch wieder ein, auch wenn ich alle Waits mit REM ausmarkiert habe.

Ich sollte wohl wirklich langsam alles rausschmeisen bis es läuft. Vermutlich mit IDCMP_MOUSEMOVE beginnend.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2008-01-01, 16:12 h

MaikG
Posts: 5172
User 		>Es könnte auch sein das es am IDCMP_MOUSEMOVE liegen könnte,
>denn das hab ich bis jetzt auch noch nie eingesetzt und das
>liefert auch ein ganz schönes Datengewitter.

Ich sag mal deine Programmierweise ist immernoch etwas
unübersichtlich. Aber Mousemove sieht okay aus.

Wenn du den HeapDynamic erhöhst, sagen wir auf 3000 und
die hänger nehmen ab - dann hast du irgendwo, dem System
einen String übergeben der nicht verschoben werden darf.
Beim Fenster kennst du das ja schon, kann aber bei vielen
Libraryfunktionen so sein.

Benutzt du Enforcer?

Ich würde das Prog ja mal starten hab aber einige Includes
dafür nicht.

[ - Answer - Quote - Direct link - ]
2008-01-01, 16:30 h

Ralf27
Posts: 2779
User
Zitat:
Original von MaikG:
>Es könnte auch sein das es am IDCMP_MOUSEMOVE liegen könnte,
>denn das hab ich bis jetzt auch noch nie eingesetzt und das
>liefert auch ein ganz schönes Datengewitter.

Ich sag mal deine Programmierweise ist immernoch etwas
unübersichtlich. Aber Mousemove sieht okay aus.
Der Code müßte mal aufgeräumt werden, das ist schon klar. Aber MouseMove bau ich am besten wieder aus und mach das ganze etwas einfacher. Wird wohl das beste sein.
Zitat:
Wenn du den HeapDynamic erhöhst, sagen wir auf 3000 und
die hänger nehmen ab - dann hast du irgendwo, dem System
einen String übergeben der nicht verschoben werden darf.
Beim Fenster kennst du das ja schon, kann aber bei vielen
Libraryfunktionen so sein.
Sudoku ist ja um welten größer und komplexeri und da hab ich keine Probleme in der Hinsicht. Und das wundert mich schon etwas.
Zitat:
Benutzt du Enforcer?
Ne, hab ich nicht.
Zitat:
Ich würde das Prog ja mal starten hab aber einige Includes
dafür nicht.
Welche fehlen dir denn? Die müßten ja im Aminet liegen.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2008-01-01, 16:58 h

Ralf27
Posts: 2779
User 		Ich glaube, ich habe denn Fehler gefunden: Eine Variable hab ich falsch übergeben-> RastPort konnte dann NULL sein bzw. ins Nirvana zeigen. Ich muß das ganze nochmal testen.

PS: Hab das Programm nochmal überarbeitet und es ist jetzt einige KB Quellcode kürzer, bzw. übersichtlicher.

Ich Prog ja nur noch zum Spaß und das auch nicht am Stück und nur wenn ich Zeit und Lust hab. Deswegen bin ich auch nicht so gut wie es eigentlich sein sollte.

--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 01.01.2008 um 17:35 Uhr geändert. ]

[ - Answer - Quote - Direct link - ]
2008-01-01, 17:47 h

Ralf27
Posts: 2779
User 		Ich finde, es ist immer wieder Merkwürdig, wie MBasic mit z.b. SUBs wohl intern umgeht: Der scheint wohl keine Unterroutinen aufzurufen, sondern viel mehr werden die Routinen immer an die entsprechende Stelle im Programm gesetzt, auch mehrfach.

So werden wohl einfach Programm als ausführbares Programm auch recht schnell recht groß. Ok, ein paar KB mehr oder weniger ist ja heute egal, wenn man sich die Festplatten so ansieht. Ist aber dennoch recht schade.

PS: Mir ist schon klar das der MBasic-Compiler en Witz ist. :(
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2008-01-01, 17:51 h

MaikG
Posts: 5172
User 		>Der Code müßte mal aufgeräumt werden, das ist schon klar. Aber
>MouseMove bau ich am besten wieder aus und mach das ganze etwas
>einfacher. Wird wohl das beste sein.


Ich meine eher so wie in den Beispielen, mit Select Case
zur Intui abarbeitung usw.


>Sudoku ist ja um welten größer und komplexeri und da hab ich keine
>Probleme in der Hinsicht. Und das wundert mich schon etwas.

Ja aber wenn Sudoku nun nicht die Librarys nutzt welche dieses Programm
braucht...


>>Benutzt du Enforcer?
>Ne, hab ich nicht.

Schlecht, hilft echt sehr beim Programmieren.
Bei der BPPC sollte der Cyberquard dabei sein.

>Welche fehlen dir denn? Die müßten ja im Aminet liegen.

BSD und codeset.

>Ich glaube, ich habe denn Fehler gefunden: Eine Variable hab ich
>falsch übergeben-> RastPort konnte dann NULL sein bzw. ins Nirvana
>zeigen. Ich muß das ganze nochmal testen.

Und ebend das hättest du mittels eines Enforcer rausgefunden.
Da hätte dann sowas wie "Long Read from 00000000" gestanden und
schon wüsstest du das irgenwo was nicht da ist.


>Ich Prog ja nur noch zum Spaß und das auch nicht am Stück und nur
>wenn ich Zeit und Lust hab. Deswegen bin ich auch nicht so gut wie
>es eigentlich sein sollte.

Hat ja nichts mit gut oder schlecht zu tun, nur mit Ordentlich...
Früher hatte ich auch immer ein übelstes Chaos, am liebsten hab
ich gar keine Unterprogramme verwendet, select case auch nicht usw.

[ - Answer - Quote - Direct link - ]
2008-01-01, 18:13 h

Ralf27
Posts: 2779
User
Zitat:
BSD und codeset.
Die CodeSet hab ich vor ein paar Tagen ins Aminet hoch geladen, die BSD-Inc aber noch nicht, wie ich eben gesehn habe. Ich hab da aber bis jetzt nur die bmap generiert. Die .hb und .hc ist aber recht komplex. Das hab ich noch nicht gemacht und vermutlich werde ich das auch nicht machen, weil ich das vermutlich auch nicht hinbekommen werde.
Zitat:
>Ich glaube, ich habe denn Fehler gefunden: Eine Variable hab ich
>falsch übergeben-> RastPort konnte dann NULL sein bzw. ins Nirvana
>zeigen. Ich muß das ganze nochmal testen.

Und ebend das hättest du mittels eines Enforcer rausgefunden.
Da hätte dann sowas wie "Long Read from 00000000" gestanden und
schon wüsstest du das irgenwo was nicht da ist.
Wenn ich es verstehen würde, dann ganz bestimmt. :) Du scheinst da mehr zu machen als ich.
Zitat:
>Ich Prog ja nur noch zum Spaß und das auch nicht am Stück und nur
>wenn ich Zeit und Lust hab. Deswegen bin ich auch nicht so gut wie
>es eigentlich sein sollte.

Hat ja nichts mit gut oder schlecht zu tun, nur mit Ordentlich...
Früher hatte ich auch immer ein übelstes Chaos, am liebsten hab
ich gar keine Unterprogramme verwendet, select case auch nicht usw.
Äh, das hat ganz bestimmt was damit zu tun. Das mit ordenlich ist auch eine Auslegungssache. Wenn man halt mehr programmiert, dann kommt man auch tiefer in die Materie rein und dann wird man automatisch besser, bzw. der Code wird besser und auch lesbarer.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2008-01-01, 22:43 h

Ralf27
Posts: 2779
User 		Ja, definitiv, das war der Fehler: Ein ungültiger Pointer auf ein RastPort der eventuell nicht mehr existieren konnte.
Bzw. einfach einen falschen Pointer gesetzt.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2008-01-01, 23:27 h

Ralf27
Posts: 2779
User 		Wegen der bmap für die BSDSocket.lib. Ich hab eben mal die bmap für die Lib auf meine Homepage gestellt.

http://home.pages.at/a1260/EigenePage/Dateien/BSDSocket.lha

Vorsicht, sind 509Bytes! :D
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2008-01-02, 14:45 h

MaikG
Posts: 5172
User 		>Wenn ich es verstehen würde, dann ganz bestimmt. :) Du scheinst da
>mehr zu machen als ich.

Vollständig weiss ich auch nicht was passiert, weil ich nicht
fliessend assembler kann.

Aber Read/write to 00000000 ist einfach zu verstehen.
Enforcer passt auf ob auf Speicherbereiche zugegriffen wird,
auf die man nicht zugreifen darf.

z.B.

abcd&=AllocVec(100, MEMF_CLEAR)

PokeB abc&, 1234

würde einen solchen Hit verursachen.
Das selbe passiert auch bei Systemfunktionen, weil die
meisten nicht prüfen ob du NULL übergeben hast.

So weiss man mindestens das man selbst was falsch gemacht hat
und halbwegs die Position.

[ - Answer - Quote - Direct link - ]
2008-01-02, 17:14 h

Ralf27
Posts: 2779
User 		Leider war es auch so, das der Rastportpointer nicht immer NULL hatte(eigentlich nur am Anfang des Programms), sondern dann auf einen Rastport verweisen konnte, der nicht mehr existent war, sprich: dessen Fenster geschlossen wurde. Genauer getippt: Ich hab da einen Rastport vom falschen Fenster angegeben.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2008-01-02, 17:39 h

MaikG
Posts: 5172
User 		>Leider war es auch so, das der Rastportpointer nicht immer NULL
>hatte(eigentlich nur am Anfang des Programms), sondern dann auf
>einen Rastport verweisen konnte, der nicht mehr existent war,
>sprich: dessen Fenster geschlossen wurde.

Ja, das ist schwieriger zu finden, müsste aber auch einen
Hit geben.

[ - Answer - Quote - Direct link - ]
2008-01-06, 23:08 h

Ralf27
Posts: 2779
User 		Kurz nochmal zu SELECT CASE etc.: Das ausführbare Programm wird dadurch seltsamerweise größer. MaxonBasic hat so einige Ungereimtheiten unter der Haube. Auch wenn man Speedtests macht, dann bekommt man einige überraschungen zu Gesicht. Ist echt schade...
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2008-01-07, 00:15 h

MaikG
Posts: 5172
User 		>Kurz nochmal zu SELECT CASE etc.: Das ausführbare Programm wird
>dadurch seltsamerweise größer.


Größer macht doch nichts.


>MaxonBasic hat so einige Ungereimtheiten unter der Haube. Auch
>wenn man Speedtests macht, dann bekommt man einige überraschungen
>zu Gesicht. Ist echt schade...

Naja, da muss man spezielle sachen machen...
Die Shift sache hab ich nicht hinbekommen:


CS%=(c% AND 16384)16384

ist bei mir langsamer als:

CS%=((c%<<1)>>15)


Praktisch gesehen wird man den Unterschied eh nicht merken.
In so einer Intui Schleife kommt doch eh nur was an wenn einer
Inputs in dein Fenster gibt bzw. die Intuitics 10x in der Sekunde.
Selbst für ein 020er macht da Selectcase <-> IF ELSEIF Else keinen
merkbaren unterschied.
Bei Zeitkritischen sachen kann man dann immernoch if nehmen, oder
natürlich wenns nur 1-3 fallunterscheidungen gibt.

[ - Answer - Quote - Direct link - ]
2008-01-07, 11:11 h

Holger
Posts: 8116
User
Zitat:
Original von Ralf27:
Kurz nochmal zu SELECT CASE etc.: Das ausführbare Programm wird dadurch seltsamerweise größer.
Im Vergleich zu was?
Zitat:
MaxonBasic hat so einige Ungereimtheiten unter der Haube.
Oh ja...
Zitat:
Original von MaikG:
Naja, da muss man spezielle sachen machen...
Die Shift sache hab ich nicht hinbekommen:

CS%=(c% AND 16384)16384

ist bei mir langsamer als:

CS%=((c%<<1)>>15)
Meinst Du nicht umgekehrt? Wenn die Division langsamer als Shiften wäre, wäre es ja vollkommen normal. MaxonBasic dagegen implementiert Shiften als eigenständiges Unterprogramm, das man erst mal aufrufen muss, während die Division als eingebauter Operator realisiert wird. So kann man natürlich den Vorteil der Shift-Operation locker negieren.

Allerdings sollte
CS%=c%16384 AND 1

in diesem Fall noch einen nicht spürbaren Tick schneller sein ;)

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2008-01-07, 15:36 h

MaikG
Posts: 5172
User 		>Meinst Du nicht umgekehrt?

Nein, schon so wie ich schrieb.
Ralf sagt ja shiften ist langsamer als Division in MB.



[ - Answer - Quote - Direct link - ]
2008-01-07, 17:04 h

Holger
Posts: 8116
User
Zitat:
Original von MaikG:
Nein, schon so wie ich schrieb.
Ralf sagt ja shiften ist langsamer als Division in MB.
So habe ich das aber auch beobachtet. Vielleicht gibt es aber da auch noch mal einen Unterschied zwischen 16 Bit und 32 Bit Integer.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2008-01-07, 18:44 h

MaikG
Posts: 5172
User 		>So habe ich das aber auch beobachtet. Vielleicht gibt es aber da
>auch noch mal einen Unterschied zwischen 16 Bit und 32 Bit Integer.

Vielleicht meint er aber auch noch kompexeres Shiften als ich
mache...

[ - Answer - Quote - Direct link - ]
2008-01-07, 20:09 h

Ralf27
Posts: 2779
User
Zitat:
Original von MaikG:
>Meinst Du nicht umgekehrt?

Nein, schon so wie ich schrieb.
Ralf sagt ja shiften ist langsamer als Division in MB.

Shiften ist nicht langsamer, aber man muß es aber Klammern, wenn es nicht alleine steht. Und ruck zuck ist es gleich schnell oder gar langsamer. Es kommt darauf an, wie komplex das ganze wird. Gerade beim BMPReader hab ich da so einiges getestet, weil es wirklich recht langsam ist. An einigen stellen Shifte ich, an deren hab ich es wieder gelassen.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2008-01-07, 20:10 h

Ralf27
Posts: 2779
User
Zitat:
Original von Holger:
Zitat:
Original von Ralf27:
Kurz nochmal zu SELECT CASE etc.: Das ausführbare Programm wird dadurch seltsamerweise größer.
Im Vergleich zu was?
IF THEN

Ist echt Paradox.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]

-1- [ - Post reply - ]


amiga-news.de Forum > Programmierung > Fehlersuche [ - Search - New posts - Register - Login - ]


.
Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved.
.