Zitat:

---

Original von ylf:
Die Frage nach dem richtigen Device stellt sich eigentlich nicht, weil der Amiga selbst mit seinen Browsern der Flaschenhals ist beim Surfen im Internet.

bye, ylf

---

code:

---

a&=2&^32
PRINT 2&^32
PRINT a&

---

Liefert unterschiedliche Werte. Echt irre.
Wenn hinter der 32 auch ein & steht, dann geht es auch auf 4GB hoch. Das dürfte dann wohl ULONG sein.

EDIT2:
Selbst wenn beide 32 auf 32& geändert werden, ist es unterschiedlich. Es gibt nicht mal eine Fehlermeldung a la Overflow (obwohl eingeschaltet) und liefert unterschiedliche Werte. Aber ok, im Programm werden die Werte ja nicht ausgegeben und die Berechnungen Variablen zugewiesen. Somit geht das.

MB hat wohl immer einen Schwinger im Peto...

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

[ Dieser Beitrag wurde von Ralf27 am 13.01.2008 um 13:54 Uhr geändert. ]

[ Dieser Beitrag wurde von Ralf27 am 13.01.2008 um 13:57 Uhr geändert. ]

Zitat:

---

Original von Archeon:
1. Hast du bereist eine Decke mit Ständerwerk abgehängt Altbauwohnungen meist der Fall)
2. Was für ein Fußboden hast du? Laminat,Dielenboden,Fließestrich mit einfachen Teppich oder PVC-Belag.

---

Zitat:

---

3. Soll es Schalldämmend sein (Kinder wegen) oder nur als Raumtrenner.
4. Ist es eine Mietwohnung oder eine Eigentumswohnung (Haus)
5. Wieviel Geld willst du reinstecken...
Gruß Archeon

---

Zitat:

---

Original von Holger:

Zitat:

---

Original von tboeckel:
Theoretisch ja, praktisch nein. Selbst wenn man sich stückweise an die Daten oberhalb von 4GB rantasten könnte, dann scheitert es am Filesystem, das keine Dateien >4GB handhaben kann.

---

Selbst wenn das Dateisystem Dateien >4GB handhaben kann, gibt es noch das Problem, dass das alte Seek() laut Spezifikation die resultierende Position zurückgibt. Somit kann man auch nicht stückweise vorwärts springen, da beim Überschreiten der 4GB-Grenze die Rückgabewerte ungültig werden würden.

---

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?

---

Zitat:

---

Original von MaikG:
>Meinst Du nicht umgekehrt?

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

---

Zitat:

---

Original von Robin:
@Ralf27:

Aktuelle Browser erkennen PNG auch wenn du sie
auf GIF enden laesst.
Die aktuellen Browser sind auch in der Lage PNG richtig darzustellen.
Leider ist der immer noch weit verbreitete InternetExplorer 6 da nicht
ganz so gut drin. Besonders wenn du für Firmen Webseiten entwickelst
solltest du versuchen wenn du mit tranparenten PNGs arbeitest
diese auf einem System ala Windows98/Win2000 zu testen.

---

Es hat schon was mit der Firmenpolitik von MS zu tun, wenn IE da Probleme mit einem freien Format hat. MS versucht ja alles um freie Format, egal welcher Art, irgendwie vom Markt zu drängen um dann eigene, geschlossene Formate zu platzieren.
Mit so einer Marktmacht wie MS kann man schon recht viel machen und das nicht immer zum guten, es aber gut aussehn lassen.
--
http://www.alternativercomputerclub.de.vu

Zitat:

---

BSD und codeset.

---

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.

---

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.

---

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.

---

Zitat:

---

Benutzt du Enforcer?

---

Zitat:

---

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

---

Zitat:

---

Original von Barthel:
warum lacht ihr alle? ich hab dem wirklich geschrieben!!!

---

Wenn du die letzten Jahren Amigageschichte dir ansehen würdest, dann würdest du vermutlich auch einen Lachkrampf bekommen.

Du kannst ihm ruhige schreiben, aber bis jetzt hat unser Mr.Zerstörer alle Versuche unterbunden irgendetwas zum Amiga zu machen. Bzw. viel eher arbeitet er daran als noch möglichst viel aus dem Trümmerhaufen Amiga herraus zu ziehen. Wenn du ihm ein paar Millionen rüberschiebst, dann darf du vielleicht denn Kolben schwingen. Ansonst kannst du davon ausgehn, das er dir eher Schwierigkeiten machen wird.
--
http://www.alternativercomputerclub.de.vu

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.

---

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.

---

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

---

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...

---

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.

---

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.

---