Zitat:

---

Original von NoImag:
Deine Aussage war absolut. Nicht bei jeder längeren Aktion kann der User sinnvoll im selben Programm weiterarbeiten und um auf Abbruch zu reagieren, ist kein extra Task notwendig. Ok, du meinst das Programm kann bei Verwendung verschiedener Tasks leichter gewartet werden.

---

Zitat:

---

Zitat:

---

Jeden Task für sich macht es einfacher. Ein Hintergrund-Task, der von jeglichen GUI-Code freigehalten wird und ein GUI-Task, der nichts über die Art des Hintergrund-Tasks wissen muß.

---

Grundsätzlich leuchtet dies ein, aber wenn der Hintergrundtask eine Rückmeldung vom User benötigt, dann handelt man sich eine umfangreiche Kommunikation zwischen den Tasks ein.

---

Das hängt davon ab, welche "Rückmeldung vom User" Du dem Hintergrund-Task schicken willst. In den meisten Fällen reicht es völlig, den Task abbrechen oder neu starten zu können, der Task ist sozusagen "williger Sklave des GUI" und hat recht eingeschränkte Möglichkeiten (es macht halt keinen Sinn, diesen Task z.B. auf eine Eingabe im GUI direkt reagieren zu lassen oder gar IDCMP auszuwerten o.Ä. Er wartet nur auf Signale vom GUI-Task, z.B. "Leg los mit Rechnen, die Daten findest Du an gewohnter Stelle" oder "brich ab, womit Du gerade beschäftigt bist und warte auf neue Anweisungen". Ein schönes Beispiel für solche Konstrukte sind Raytracer. Sobald im Editor ein Objekt einer gerade in der Berechnung befindlichen Szene verändert wurde, bekommt der Trace-Task ein Signal, die Berechnung mit den neuen Daten neu zu starten und die bisher berechneten Daten zu verwerfen. Er braucht keine detaillierten Daten über User-Eingaben, muß sich nicht um die Einzelheiten der Dateneingabe durch den User kümmern, er berechnet einfach, was ihm vorgeworfen wird, wenns verlangt wird).

Für solche Zwecke genügen per Semaphore geschützte Flags und Speicherbereiche, da braucht es nicht einmal (relativ) kompliziertes Message-Handling. Schwieriger wird es erst, wenn Du Daten zur Berechnung übergeben willst, die Du nicht in einem gemeinsam genutzten Speicherbereich unterbringen kannst oder willst. Da werden dann recht umfangreiche Basteleien mit Inter-Task-Messages notwendig.

Mir fällt da aber jetzt auf Anhieb kein überzeugendes Beispiel ein, das auf diese Methode zwingend angewiesen wäre.

Zusammenfassend kann man wohl sagen, daß es manchesmal durchaus sinnvoll sein kann, das GUI und den großen Rest auf Task-Ebene zu trennen.

Grüße


--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
... Du benötigst einen zusätzlichen Messageport für die Signale des Berechnungstasks usw.).

---

Für Signale braucht man natürlich nur Signale, keinen ganzen MessagePort. Den braucht man, wenn man Messages austauschen will. Klingt vielleicht auf den ersten Blick nach Haarspalterei, bedeutet aber einen gewaltigen Unterschied, weil Tasks über Messages kommunizieren zu lassen innerhalb eines geschlossenen Programms ein ziemlicher Overkill sein kann.

Da reicht u.U. eine per Semaphore geschützt globale Variable vollkommen aus.
...

---

Da hast Du natürlich Recht. Ich wollte Reth nur an wenigen Beispielen aufzeigen, was für zusätzliche Arbeit auf ihn warten kann. Ich weiß ja nicht genau, was er vorhat. Wenn ein gemeinsam genutzter (und per Semaphore zugriffskontrollierter) Speicherbereich ausreichend ist, benötigt man natürlich keinen Messageport bzw. Inter-Task-Kommunikation per Message. Das vereinfacht die Geschichte dann doch um einiges

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Reth:
Hi Holger,

Zitat:

---

Original von Holger:
Doch, es ist exakt so: es gibt einen Event-Handling Thread, und solange keine neuen Events anliegen, ist dieser Thread blockiert.

Anwendungen werden mit dem main-Thread gestartet und wenn kein GUI verwendet wird, enden sie auch mit diesem. Aber 99% aller Java-Anwendungen benutzen den main-Thread nur zur Initialisierung und laufen dann fast ausschließlich im Event-Handling Thread.

Und ein beliebter Fehler von Java-Programmierern ist es, lange dauernde Aktionen innerhalb eines Event-Handlers durchzuführen, womit der Handling Thread nicht mehr auf neue Messages reagieren kann, womit dann nicht mal mehr das Neuzeichnen der UI stattfindet.

Korrekt wäre es, dafür dann einen neuen Thread zu starten. Ist exakt genauso wie bei Amiga Programmen.

---

Aber sehe ich das richtig, dass ich in Java meine GUI aufbauen kann, die Elemente mit Listenern versehen, die auf Eingaben reagieren, aber solange keine Eingaben kommen, kann ich ausserhalb meiner Listener weiterhin Code ausführen (z.B. permanent Infos rausschreiben etc.), wobei die Listener bei Auftreten von Ereignissen ihre Behandlungsroutinen dennoch ausführen?!

---

Ähnliche Späße kannst Du auch mit einem separaten GUI-Task (bzw. separatem Berechnungs/Ausgabe/Was-weiß-ich-Task) machen. Ich habe mich weder mit Java noch mit Threading ausführlich beschäftigt (das Task-Konzept war für meine Zwecke bisher immer mehr als ausreichend), aber ich denke mal, daß ein eigener Task für länger dauernde Verarbeitung irgendwelcher Daten und das Warten auf das Signal dieses Tasks im GUI- bzw. Main-Task für Deine Zwecke passen müßte.

Geht vermutlich nur nicht ganz so komfortabel wie das Java-Thread-Konzept (beim AmigaOS mußt Du u.A. dafür sorgen, daß das Beenden der einzelnen Tasks "sauber" erledigt wird, also z.B. Warten, daß der Berechnungstask sein Ende kundtut, bevor von diesem Task mitgenutzte Resourcen freigegeben werden, Du benötigst einen zusätzlichen Messageport für die Signale des Berechnungstasks usw.).

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von MaikG:
Habs dann mal versucht in Basic umzusetzten:

REM $include exec.bh
REM $include input.bc

LIBRARY OPEN "exec.library"

REM $INCLUDE Blib/ExecSupport.bas

PortN&=1
port& = CreatePort&(NULL&, NULL&)
IF port& THEN
InputIO&=CreateExtIO&(port&,IOStdReq_sizeof%)
IF InputIO& THEN
device& = OpenDevice&(SADD("input.device" + CHR$(0)), NULL&, InputIO&, NULL&)
IF device& THEN
POKEW(InputIO&+IORequestio_Command%), IND_SETMPORT&
POKEL(InputIO&+IOStdReqio_Length%),1&
POKEL(InputIO&+IOStdReqio_Data%), VARPTR(PortN&)
POKEL(InputIO&+IOStdReqio_Flags%), IOF_QUICK&
IF DoIO&(InputIO&) THEN PRINT "Fehler4 DOIO":GOTO 1235
CloseDevice InputIO&
ELSE PRINT "can't open input.device"
END IF
DeleteExtIO InputIO&
ELSE PRINT "cant create IO"
END IF
DeletePort port&
ELSE PRINT "can't open port"
END IF

1235

Dann kommt "can't open input.device", wahrscheinlich ist es hier
mit 26°C zu heiss für sowas...

---

Nein, Du bist nur dem "Spaßvogel OpenDevice()" aufgesessen. OpenDevice() liefert 0 (den Wert, keinen Zeiger) zurück, wenn alles glett gelaufen ist und einen Fehlerwert, wenn es Probleme gab. Also genau umgekehrt wie bei anderen Open()-Funktionen.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:

Zitat:

---

whose:
Hm, wäre vielleicht an der Zeit für ein aktuelleres Beispiel, evtl. unter Benutzung der SDI-Includes?

---

AFAIK gibt es auch eine Beispielbibliothek von Dirk Stöcker. Ansonsten mal den quellcode von mpega_libmad anschauen ;-)

---

Im Prinzip ne gute Idee, aber durch die reichlich verteilten #ifdefs doch etwas schwer zu durchblicken. Da wäre ein klares, einfaches Beispiel doch besser, finde ich. Jeweils eins für alle Systeme, dann blickt man vermutlich alle leichter.

Aber nichts desto trotz, wer sich ansehen will, wie ne Library für verschiedene Systeme und verschiedene Compiler erstellt wird, dem sei mpega_libmad ans Herz gelegt. Geht sogar mit StormC4

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von thomas:

http://www.aminet.net/package.php?package=dev/c/CLib37x.lha

Das ist aber IMHO noch viel zu kompliziert gemacht. Es ist mit vielen vielen #ifdefs an so gut wie alle Compiler angepaßt. Das hätte man lesbarer machen können.

---

Hm, wäre vielleicht an der Zeit für ein aktuelleres Beispiel, evtl. unter Benutzung der SDI-Includes?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:

Zitat:

---

whose:
Hm, ich sehe schon, die Vertreter der "reinen Lehre" gewinnen die Oberhand Nun ja, die Leser dieses Threads werdens lesen und hoffentlich auffassen. Ich sehe das ganze zwar leicht anders (IORequest vs. IOStdRequest (da gibts keine Warnings? ), völlig unterschiedliche Bezeichner etc.), aber um solche Sachen will ich keinen Streit auslösen.

---

Warum mußt Du jetzt mit "Birnen" anfangen? Wir haben über "Äpfel" geredet :-( Das diese beiden Strukturen nicht zueinander passen, sollte klar sein. Warum mußt Du andere fragen. Eventuell kann Olsen ja was dazu sagen.

---

Hm, da unterscheiden sich vermutlich unsere Sichtweisen, deswegen vielleicht... ich sehe das Ganze als "Benutzen eines AmigaOS-Devices auf dem empfohlenen Weg" und nicht als "wir übermitteln ohne jeglichen Bezug zum API die Adresse einer Struktur" (woher weiß man auf Anhieb, daß tr_node eine struct IORequest ist, wenn man länger nichts mit dem timer.device zu tun hatte?).

Bei allem Verständnis für "formal korrekte" Wege, es wird oft vergessen, daß viele Leute kein fotographisches Gedächtnis besitzen und manche Dinge schlicht vergessen werden (weil selten benötigt).

Die IO-Funktionen für Devices erwarten nun einmal den Zeiger auf eine Struktur vom Typ "IORequest", da kann ich nichts für.

Ich hätte vermutlich weniger Probleme mit Deiner Sichtweise, wenn Deine Vorgehensweise für alle Device-bezogenen Strukturen zutreffend wäre. Das ist sie aber nun mal nicht. Deswegen mein Vergleich von IORequest und IOStdRequest (spätestens da muß man ja so oder so wieder casten,um die Warnings loszuwerden. Da kann man das auch gleich konsequent tun, finde ich).

Möglicherweise ist das aber ein Punkt, den man nun (mit OS4 z.B.) ändern könnte. Einheitliche Typen und Bezeichner für die IORequests, Erweiterungen der Strukturen dahin, wo sie hingehören. Ans Ende der Device-spezifischen Struktur.

Wenn bei allen Devices mit Erweiterungen der IORequest-Struktur diese zu Beginn mit (device-Kürzel)_Node stehen würde, dann wäre das kein Thema. Man weiß, daß bei jedem Device zu Beginn der IO-Struktur ein IORequest mit dem Bezeichner bla_Node steht und gut.

So verwirrt es aber nur beim Lesen (wie gesagt, wer weiß schon, das tr_node eine struct IORequest ist? Man kanns "vermuten", weil es sich um eine Device-IO-Funktion handelt, aber "Vermuten" beim Lesen eines Programms? Ich weiß ja nicht...).

Meiner Meinung nach sinds einfach nur zwei verschiedene Sichtweisen des (mehr oder weniger) gleichen Vorgangs, die uns hier beschäftigen.

Du siehst es mehr aus der formalen (und keineswegs falschen) Sicht, ich mehr aus der Sicht des "Otto Normal"-Entwicklers, der eben nicht die Zeit und die Möglichkeiten hat, sich bis in alle Einzelheiten in ein API einzuarbeiten (nicht falscher als die formale Sicht, meiner Meinung nach).

Fallstricke in Sachen Cast gibt es genug, zweifellos, aber genauso gibt es Fallstricke in Sachen "nichtssagende Bezeichner". Ich glaube, das gleicht sich irgendwo aus.

Um es auf den Punkt zu bringen: Ich sehe ein, daß Du (im Hinblick aufs reichliche Casten) Recht hast. Nur bringt uns das nicht weiter und den Anfängern hilft es relativ wenig bei dem Versuch, AmigaOS zu verstehen und zu verwenden, wenn sie mit Formalien zugeworfen werden.

Was nicht heißen soll, daß erfahrene Leute wie Du nicht darauf aufmerksam machen dürfen, daß da einiges im Argen liegt. Ich bin mir sicher, daß das von den Mitlesenden aufgenommen und verwertet wird.

Nur meine 2 Cent...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233



[ Dieser Beitrag wurde von whose am 30.06.2006 um 15:49 Uhr geändert. ]

[ Dieser Beitrag wurde von whose am 30.06.2006 um 16:11 Uhr geändert. ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von NoImag:
Zur Verwendung von 2 Joysticks: Wenn ich mich richtig erinnere (habe die Dokumentation hier nicht zur Hand), dann kannst du problemlos Port 0 auf "Joystick" stellen (gameport.device). Das hat aber mit deinem Problem nichts zu tun.

---

Ich weiß auch, daß man dem input.device sagen konnte, daß die primäre Maus am anderen Port hängt. Da gab es auch schon zu a500-Zeiten tools für, damit man auch weiterarbeiten konnte, wenn der port kaputt war. Und ich denke mal, wenn man den port redefinieren kann, kann man die Maus auch komplett abmelden, um die resource frei zu bekommen.

---

code:

---

BYTE port = 1;

InputIO->io_Data = &port;
InputIO->io_Flags = IOF_QUICK;
InputIO->io_Length = 1;
InputIO->io_Command = IND_SETMPORT;
BeginIO((struct IORequest *)InputIO); /* sry für den Cast */

if(InputIO->io_Error)
    printf("SETMPORT Fehler: %dn", InputIO->io_Error);

---

Das zweitere dürfte wohl schon mit dem gameport.device machbar sein, indem man für den Mausport (Port 0) GPCT_NOCONTROLLER setzt (mittels GPD_SETCTYPE). Soweit ich gerade aus dem Gedächtnis sagen kann (habe nie groß was mit dem gameport.device gemacht), sollte man GPD_ASKCTYPE (richtig?) vorher senden, um den Typ des bisher "angemeldeten" Controllers zu bekommen (und später wieder darauf zurücksetzen zu können). Das Ganze muß wohl auch in einem Forbid()/Permit()-Paar ablaufen.

Genaueres kann ich aber auch erst später sagen, habe das RKM nicht zur Hand. Ich weiß also nicht, ob der Port dann tatsächlich "frei" gemacht wird oder nicht (aber die Wahrscheinlichkeit ist hoch).

Nachtrag: Mir fällt gerade ein, daß das input.device da ja noch mitmischt... muß man das dann "austricksen"? (sprich: Mausport auf Port 1 setzen, Port 0 auf NOCONTROLLER, Port 0 allokieren, input.device "veralbern" und Mausport wieder auf Port 0 zurücksetzen (der dann ja "belegt" ist), und dann das gleiche Spiel mit Port 1. Was aber, wenn das input.device das "Zurücksetzen" auf Port 0 nicht zuläßt (weil bereits "belegt")?). Das weiß ich nun gerade nicht

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 30.06.2006 um 15:14 Uhr geändert. ]

Zitat:

---

Original von MaikG:
>Für Sprengstoff lautet die Zauberformel "T2-Schein" (Mengenbegrenzung),

Eine Vorstrafe und den bekommt man nicht oder?
Und ich denke auch mit den schein dürfte man es nicht unbedingt
zur Einbrecherabwehr einbuddeln.

---

Zitat:

---

>für Laser mit Personengefährdung "Gewerbeamt, Umweltamt, TÜV und
>Berufsgenossenschaft" (ohne Leistungsbegrenzung)

Der Hinweiss mit Gewerbeamt steht bei ELV, in den Ebay Auktionen
steht davon nichts...

---

Muß es ja auch nicht. Da ist man als "Anwender" in einer Holschuld... man muß sich sachkundig machen, ob und unter welchen Auflagen eine solche Anlage betrieben werden darf.

Wie so häufig gibt es da eine gewisse "Verkehrung der Welten". In Sachen Laser (und anderen Dingen, u.A. Sprengstoffe) ist verboten, was nicht ausdrücklich erlaubt ist.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Alles eine Frage des richtigen "Scheins". Für Sprengstoff lautet die Zauberformel "T2-Schein" (Mengenbegrenzung), für Laser mit Personengefährdung "Gewerbeamt, Umweltamt, TÜV und Berufsgenossenschaft" (ohne Leistungsbegrenzung)

---

Und Plasmakanonen?

---

Ich schätze, da langt eine Professur an einer Fakultät für Nuklearphysik

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von MarkusPohlmann:
...
Oder Projekt Crashsite.
Immer wieder wenn ich da irgendeine Neuigkeit zu vermelden habe heisst es erstmal
"Wird ja eh'nie fertig" und "Müll-Grafik!".
Ich meine, ich habe ein Privat- und Berufsleben neben dem Amiga und bin "nur" Programmierer, kein Grafiker.
Interessiert einfach niemanden. "Kann ja nur Mist oder gar nix werden so wie das bis jetzt aussieht."
Mal davon abgesehen, dass Du als Entwickler 20 mal schreiben kannst, dass Du Grafik X, Sound Y und Routine Z im finalen Release noch tauschen wirst.
Hat man sich erstmal in bestimmten Foren darauf eingeschworen genau diese Kritikpunkte runterzuputzen, wird jede Neuerung mit immer den gleichen Parolen niedergemacht.
Und Du wirst immer angemacht weil V0.x immer noch nicht perfekt auf dem Stand von V1.0 ist.

Der Mehrheitlichen Meinung nach sollte ich unbedingt das Handtuch werfen weil bei mir nur Müll raus kommt.
Hab'ich bei BatDefense auch schon getan...

---

Vielleicht ist genau das der falsche Weg? Im Grunde spielst Du den "Berufsnörglern" da doch genau auf den Fuß und die brauchen nur noch zu "versenken" ("Hab ich doch immer gesagt...").

Ich denke, im Amiga-Bereich muß man sich, was die eigenen Produkte harter Arbeit angeht, einfach ein dickes Fell zulegen. Heimlich still und leise ist sicher mancher der Nörgler doch erfreut, wenn die öffentlich kritisierte Software weiterentwickelt und verbessert wird.

Abgesehen davon, die Nörgler sind doch gar nicht Deine Zielgruppe, es sind die, die entweder Feedback geben oder schweigen (weil sie entweder zufrieden und faul sind, oder das Programm aus verschiedenen Gründen, die Du evtl. abzustellen gedenkst, nicht nutzen).

Meiner Meinung nach könnte man als Entwickler für den Amiga entschieden zufriedener zu Werke gehen, wenn man sich nicht auf Mail-Feedback versteift sondern evtl. auf andere Methoden, den Erfolg einer Software zu messen. Download-Zahlen beispielsweise. Oder für die, die ihre Software verkaufen möchten halt die Verkäufe gemessen am wahrscheinlichen Marktvolumen (welches ja nicht allzu gigantisch ist derzeit). Das dafür notwendige Feedback kommt ja doch, wenn auch in sehr geringer Zahl. Aber wie heißt es bei der Agentur für Arbeit in Sachen Ausbildungsplätze? "Jedes Bisschen hilft".

Die Gemeinde ist derzeit nicht mehr das, was sie früher einmal war, darauf muß man sich als Entwickler einstellen. Früher hieß das Motto wohl "Releasen auf Teufel komm raus", heute lautet es wohl mehr "mit Geduld und Spucke"...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Holger:

Zitat:

---

Original von MaikG:
Der hatte nur eine Laser, Sprengstoff darf man in Deutschland
nicht herstellen und auch nicht besitzen.

---

Aber eine tödliche Laserwaffe?!

---

Alles eine Frage des richtigen "Scheins". Für Sprengstoff lautet die Zauberformel "T2-Schein" (Mengenbegrenzung), für Laser mit Personengefährdung "Gewerbeamt, Umweltamt, TÜV und Berufsgenossenschaft" (ohne Leistungsbegrenzung)

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Holger:

Zitat:

---

Original von gni:
timerequest enthält am Anfang einen engebetteten IORequest und genau den übergibt man mittels &req->tr_node. Damit hat man ohne cast den richtigen Typ. In Amiga-Programmen wird viel zu oft mit Casts gearbeitet...

---

Amen.

Zitat:

---

Original von whose:
So kann man es natürlich auch machen. Mit dem Cast geht es auch, noch dazu für beinahe jedes Device gleich, ohne jedesmal in den Strukturen schauen zu müssen, wie der eingebettete IORequest nun gerade heißt...

---

Wenn Du mit einem spezifischen IORequest arbeitest, dann im Allgemeinen, weil Du dessen erweiterte Struktur benötigst. Dann mußt Du so oder so in die Dokumentation der Struktur schauen. Wenn Du allerdings nur den Basistyp brauchst, kann Du auch den Basistyp benutzen.

---

Hm, ich sehe schon, die Vertreter der "reinen Lehre" gewinnen die Oberhand Nun ja, die Leser dieses Threads werdens lesen und hoffentlich auffassen. Ich sehe das ganze zwar leicht anders (IORequest vs. IOStdRequest (da gibts keine Warnings? ), völlig unterschiedliche Bezeichner etc.), aber um solche Sachen will ich keinen Streit auslösen.

Ich kann ja das Beispiel entsprechend ergänzen, kein Problem.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Ralf27:
@thomas:

code:

---

warning 54 in line 167 of "ram:Testk.c": ; expected

---

Ok, danke, dann ist mir auch klar was da oben steht. Dann ist das also der Fehler im Code vom Maddog. Und wenn ich das richtig verstanden habe, ist das nur eine Warnung, das ganze läuft aber dennoch.

@MadDog:

Bugreport: Hab da en Fehler gefunden.

---

Der Fehler passiert aber schnell, wenn man mehrere Klamotten in einer Zeile unterbringt. Kleiner Tipp fürs nächste Mal: Gruppier die Zeilen so um, daß alles in einer eigenen Zeile für sich steht. Dann sieht man recht leicht, wo ein Semikolon fehlt. Auch ungleiche Klammern fallen dadurch etwas schneller auf.

Und wenn Du mal ne Warnung bekommst, deren Bedeutung sich Dir nicht erschließt (weil Englisch ), frag einfach mal, reißt Dir keiner den Kopf für ab, denke ich

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:

Zitat:

---

whose:
Sofern man dem Compiler mitteilt, daß man die entsprechenden Warnungen nicht sehen möchte, kann man das.

---

Nix mit Warnungen unterdrücken! timerequest enthält am Anfang einen engebetteten IORequest und genau den übergibt man mittels &req->tr_node. Damit hat man ohne cast den richtigen Typ. In Amiga-Programmen wird viel zu oft mit Casts gearbeitet...

---

Zitat:

---

Zitat:

---

Danke für den Tip mit dem blanken Speicher-Kopieren... irgendwie rostet man ein, wenn man nicht hin und wieder Museumsstücke benutzt, glaube ich

---

Du kannst auch CopyMem aus Exec verwenden ;-)

---

Ja, kann ich auch. Oder von Hand jedes einzelne Byte kopieren... ich sag ja: man rostet ein, wenns zu viel Komfort gibt

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Ralf27:

Also, es gibt laufend Probleme die umschifft werden möchten. Das meinte ich mit Nahkampf mit dem Compiler...

---

Naja, bis auf die Zeichenprobleme (Shift-Space) und Vertipper gibts die Probleme mit Cubic nicht. Das läuft "direkt aus der Kiste" und die Optionen der Compiler sind einigermaßen verständlich aufbereitet (z.B. C99-Option für vbcc). Das Gleiche gilt für die GCC-Installation.

Das Verstehen der Optionen ist allerdings ne andere Sache (verdammtes Englisch )... aber da hilft Nachfragen

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Ralf27:
Hm, ich hatte eigentlich nur eine einfache Frage nach dem Sekundentakt gestellt und wie ich nun in diesem Thread kann, ist dies unter umständen recht kompliziert.

---

So kompliziert ist es eigentlich gar nicht. Es gibt halt nur recht viele Möglichkeiten, das zu realisisieren und je nach Anspruch einiges zu beachten (z.B. Genauigkeit, Gleichlauf mit der Systemzeit etc.). Für Dein spezifisches Problem hat sich ja ne Lösung gefunden, das andere ist mehr theoretischer Natur

Zitat:

---

Bzw. finde ich auch die Diskusion unter C-Profis schon recht interesant, die sich sogar bei diesem Thema noch Hürden finden.

---

Wie gesagt, das ist mehr eine Frage der Ansprüche. Je höher die Ansprüche, desto höher die Hürden

Zitat:

---

Und genau so geht es mir als noch mit C, leider. Ich komme zwar langsam voran (sehr langsam), aber ich bin da hin und wieder dennoch im Nahkampf mit dem Compiler. Aber das ist ja ein bekanntes Problem.

Deswegen laufen zur Zeit alle meine Projekte noch unter MaxonBasic. Und vermutlich auch noch die nächsten. ...

---

Eventuell wäre Cubic ne Idee... das installiert die Compiler ordentlich, man kann zwischen verschiedenen Varianten wählen und die Konfiguration ist auch verhältnismäßig simpel zu erledigen.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:

Zitat:

---

whose:
Andererseits beherrschen manche der älteren Compiler das Kopieren von Strukturen ja nicht.

---

Was für Museumsstücke verwendest Du denn? ;-) Du kannst immer "zu Fuß" kopieren, zb. mit memcpy.

---

Ich verwende keine Museumsstücke mehr Aber es soll noch Leute geben, die mit dem Lattice/SAS5.2 arbeiten, der kanns z.B. nicht.

Danke für den Tip mit dem blanken Speicher-Kopieren... irgendwie rostet man ein, wenn man nicht hin und wieder Museumsstücke benutzt, glaube ich

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von gni:

Zitat:

---

whose:

Zitat:

---

gni:
Und ohne Casts wäre es noch viel besser...

---

Würde aber reichlich Warnungen bringen

---

Soweit ich weis, hat timerequest einen eingebetteten IORequest. Damit kann man sich solch unsinnige Casts wie in dem Beispielprogramm sparen.

---

Sofern man dem Compiler mitteilt, daß man die entsprechenden Warnungen nicht sehen möchte, kann man das. Wie an so vielen anderen Stellen auch. Aber ich caste lieber, statt "Kleinigkeiten" zu verwechseln und mich dann zu fragen, weshalb etwas kracht

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von thomas:

Zitat:

---

Schon, aber bei verschiedenen, asynchronen IORequests mußt Du die Request-Replies selbst noch einmal unterscheiden. Sonst weißt Du ja nicht, auf welchen Timer-Event Du nun reagieren sollst.

---

Ok, das liegt wohl daran, daß du den IORequest kopierst und dann den selben Message-Port für mehrere Timer benutzt. Dann hast du natürlich das Problem, daß du beim Auftreten des Signals erstmal nachschauen mußt, welcher Request denn jetzt zurückgekommen ist. Dann kannst du auch schlecht mit WaitIO arbeiten, sondern mußt die Messages mit GetMsg abholen und kannst dann am Pointer erkennen, welcher Request es ist.

---

Zitat:

---

Das ist alles einfacher, wenn man das Device mehrmals mit je einem eigenen IORequest und MsgPort öffnet. Dann hat jeder Request ein eigenes Signal und man kann bereits am Signal erkennen, welcher Request es ist.

---

Ja, auf die Art ist es ziemlich simpel

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von thomas:

... und gleich nochmal verbessert (jetzt hat es zwei Timer, allerdings mit unterschiedlichen Units).

Zitat:

---

das ist aber nicht das Gleiche wie asynchrone IORequests

---

Wieso nicht ? Du hast eine Wait()-Anweisung, in der du auf alle Signale wartest. Wenn ein Signal erkannt wird, reagierst du entsprechend. Ob das nun ein Fenster, ein Timer, eine Soundausgabe, eine Message von einem Sub-Task oder ein Break-Signal ist, die Behandlung läuft immer gleich ab.

---

Schon, aber bei verschiedenen, asynchronen IORequests mußt Du die Request-Replies selbst noch einmal unterscheiden. Sonst weißt Du ja nicht, auf welchen Timer-Event Du nun reagieren sollst. Das ist doch schon ein kleiner Unterschied zu den bekannten Signalen, finde ich. Kann jedenfalls nicht schaden, das mal zu demonstrieren

Zitat:

---

Zitat:

---

wozu dient das Dragbar-Gadget?

---

Ähm, als Drag-Bar... Damit kannst du das Fenster durch die Gegend ziehen, obwohl es keinen Rahmen hat (WFLG_BORDERLESS). Um zwei Uhren miteinander zu vergleichen, sollten sie möglichst nahe beieinander sein und dafür muß man mindestens eine der Uhren bewegen können ;-)

---

Ach je... gar nicht registriert, daß das ein Borderless-Window ist

Danke für den Augenöffner

Edit: Hehe, das war Gedankenübertragung, oder? Auf das "Nachlaufproblem", wenn die Systemzeit zurückgestellt wird, wollte ich Dich gerade aufmerksam machen

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 26.06.2006 um 21:17 Uhr geändert. ]

Zitat:

---

Original von thomas:

Ich finde es nicht unelegant, das timer.device mehrmals zu öffnen. Wie gesagt, wenn du dich später entschließt, die Unit eines Requests zu ändern, mußt du sonst das ganze Programm umschreiben.

---

Zitat:

---

Für das Demonstrieren mehrerer Signale, finde ich, reicht es aus, wenn man auf den Timer, auf das Fenster und auf Ctrl-C wartet, das sind ja schon drei asynchrone Sachen.

---

Naja, das hatten wir vorher ja auch schon, immerhin wurde auch aufs Close-Gadget gewartet... das ist aber nicht das Gleiche wie asynchrone IORequests

Zitat:

---

Ich habe hier auch mal ein Beispiel für eine Uhr gebastelt: http://thomas-rapp.homepage.t-online.de/examples/uhr.c

---

Gewohnte Qualität... eine Frage hab ich aber: wozu dient das Dragbar-Gadget?

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von thomas:

Ich weiß nicht genau, was du meinst. Wenn du mehrere Timer brauchst, solltest du das timer.device auch mehrmals öffnen. Könnte ja sein, daß du unterschiedliche Units für unterschiedliche Genauigkeiten brauchst. Und wenn sich das erst zu einem späteren Zeitpunkt während der Programmentwicklung herausstellt, dann mußt du das ganze Programm umbauen.

---

Zitat:

---

Wenn du mehrere Requests nacheinander machst, reicht natürlich ein OpenDevice, dann kannst du den gleichen IORequest weiterbenutzen.

---

Zitat:

---

Speziell für GETSYSTIME würde ich eher die Funktion GetSystTime benutzen, die ist auch ausdrücklich als schneller dokumentiert. Oder gleich DateStamp oder CurrentTime, was man eben braucht.

---

Ja, das sehe ich ein. Für das Uhr-Beispiel ist es aber ganz praktisch, wenn man die Verwendung mehrerer, asynchroner Requests demonstrieren will. Ich habe das Beispiel schon darum erweitert, aber mir gefällt die Sache mit dem mehrfachen Öffnen ein und derselben Unit des timer.device halt nicht so besonders.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von thomas:
@whose:

Zitat:

---

Zum WaitIO(): Aus welchem Grund muß denn, wenn das timer.device das Signal gesetzt hat, nochmal extra auf Beendigung des Requests gewartet werden?

---

WaitIO wartet nicht, wenn der Request bereits beantwortet wurde. Aber es räumt auf und das fehlt in deinem Programm.

Zitat:

---

Darf man nicht davon ausgehen, daß der Request bearbeitet wurde, wenn das gewünschte Signal eintrifft?

---

Der Request wurde bearbeitet, aber du mußt die Antwort noch abholen.

Zitat:

---

Ich frage so dusslig, weil ich zum WaitIO() an dieser Stelle weder in den RKMs noch in den AutoDocs was finde...

---

Doch, das steht da irgendwo.

---

Ach, Du meinst das Räumen des MessagePorts von unterschiedlichen Replys, jetzt verstehe ich. Na, das ist hier doch aber nicht gegeben. Es kommt immer der gleiche IORequest zur Anwendung. Da wäre das Aufräumen etwas Overkill, vor allem für die, die gerade hineinschnuppern. Da sollte man besser ein Beispiel mit mehreren asynchronen Requests aufsetzen, da läßt sich das (meiner Meinung nach) viel besser zeigen, wozu die GetMsg()-Mimik überhaupt gut ist.

Das könnte man evtl. auch so machen, indem man für TR_GETSYSTIME einen eigenen Request nimmt und dann in der Wait()-Schleife TR_ADDREQUEST an erster Stelle in der Bearbeitung setzt. Da wäre dann ein WaitIO() vor dem DoIO() fällig oder auch ein GetMsg(TimerMP), um die unterscheidlichen Requests aus dem Port zu bekommen. Besonders verständlich wäre es aber wieder nicht, denke ich. Dafür ist das Programm an sich einfach zu simpel (soll heißen: Zu geradlinig im Ablauf. Das kann kaum einer nachvollziehen, warum man dann so ein "Tamtam" um die Replies macht).

Grüße

Edit: Ich habe das Beispiel nun an die Anregung angepaßt und den dussligen Fehler beim Test auf die Signale beseitigt.
--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 26.06.2006 um 16:28 Uhr geändert. ]

Zitat:

---

Original von gni:

Zitat:

---

thomas:
Korrekt muß es also so lauten:

code:

---

/* Die Uhr hat sich gemeldet... */
if(Signale & (1UL << TimerMP->mp_SigBit))
{
   WaitIO ((struct IORequest *) TimerIO);

   TimerIO->tr_node.io_Command = TR_GETSYSTIME;
   DoIO((struct IORequest *) TimerIO);

---

---

Und ohne Casts wäre es noch viel besser...

---

Würde aber reichlich Warnungen bringen

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von thomas:

Ich sehe gerade, in eurem Code ist noch ein Fehler drin: nach dem Aufruf von SendIO muß unbedingt WaitIO aufgerufen werden, bevor der IORequest wieder verwendet werden darf.

Korrekt muß es also so lauten:

code:

---

/* Die Uhr hat sich gemeldet... */
if(Signale & (1UL << TimerMP->mp_SigBit))
{
   WaitIO ((struct IORequest *) TimerIO);

   TimerIO->tr_node.io_Command = TR_GETSYSTIME;
   DoIO((struct IORequest *) TimerIO);

---

---

Ja, mit "==" war Bockmist, Weiß auch nicht, wie ich da drauf gekommen bin, hier bei mir stehts richtig im Programm

Zum WaitIO(): Aus welchem Grund muß denn, wenn das timer.device das Signal gesetzt hat, nochmal extra auf Beendigung des Requests gewartet werden? Darf man nicht davon ausgehen, daß der Request bearbeitet wurde, wenn das gewünschte Signal eintrifft? Ich frage so dusslig, weil ich zum WaitIO() an dieser Stelle weder in den RKMs noch in den AutoDocs was finde...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233