Zitat:

---

Original von Holger:
buffer1&=SADD(SPACE$(size&))
buffer2&=SADD(SPACE$(size&))

---

code:

---

buffer1&=0
buffer2&=0
buffer1&=SADD(SPACE$(10))
buffer2&=SADD(SPACE$(10))

PRINT buffer1&,buffer2&

---

[ - Antworten - Zitieren - Direktlink - ]

@Ralf27:

Dann müßte auch irgendwo im Handbuch stehen, was MB mit temporären Variablen veranstaltet. Such da mal ein wenig. Sollten temporäre Stringvariablen tatsächlich auch bei MB auf dem Heap landen, bekommst Du mit ziemlicher Sicherheit irgendwann ein Problem mit dem Konstrukt. Bei GFA stand es im Handbuch, daß temporäre Stringvariablen im Variablenbereich landen und ein "unsichtbares" Label bekommen. Da bestand keine Gefahr, daß solche Strings aus Versehen überschrieben werden. Dafür wurde das Speicherproblem der Garbage Collection überlassen, auch nicht unbedingt optimal...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:

Zitat:

---

Original von Holger:
buffer1&=SADD(SPACE$(size&))
buffer2&=SADD(SPACE$(size&))

---

Hab es eben getestet und etwas interesantes festgestellt:
1. Die Daten werden wirklich hintereinander im Speicher abgelegt. Wenn z.b. size&=10 ist, dann ist buffer2&=buffer&+size&, um es mal so zu tippen. Laut Handbuch belegen die Strings einen Tabelle und von da aus geht dann wohl ein "Link" zu einem anderen Speicherbereich.

---

Ja, das ist normal. In BASIC werden Variablen halt in einer "Label-Tabelle" festgehalten (da ist auch der Speicherbedarf festgehalten), der eigentlich belegte Speicher einer Variablen befindet sich meist in einem gesonderten Bereich, dem Variablen-Bereich. Das ist u.A. der Grund dafür, weshalb die wenigsten Interpreter Strings von unbegrenzter Länge akzeptieren.

Daß bei Deinem Test die beiden Adressen schön geordnet hintereinander liegen, sagt aber noch nicht viel. Es ist halt die Frage, wo genau der Speicher dafür angefordert wurde und für welchen Abschnitt Deines Programms dieser Speicher "gültig" bleibt. Ist es der Variablenbereich, weiß der Interpreter/Compiler immer, wie lang der angelegte String ist, auch wenn der "Gültigkeitsbereich verlassen wird" (ich meine hier den Gültigkeitsbereich lokaler Variablen, temporäre Variablen, die in der Label-Tabelle erfaßt und im Variablenspeicher abgelegt sind, gelten für das ganze Programm oder global). Werden die beiden Strings auf den Heap geschmissen, weiß er das spätestens am Ende des Gültigkeitsbereichs nicht mehr und einer oder beide Strings werden irgendwann durch andere Werte überschrieben.

Da MB auch CONST unterstützt, gehe ich aber davon aus, daß es auch lokale Variablen unterstützt, die einen beschränkten Gültigkeitsbereich haben. Das dürfte dann auch auf die temporären Strings zutreffen. Genau das ist dann das gefährliche. Solltest Du den "Gültigkeitsbereich" dieser Strings verlassen und z.B. weitere temporäre Variablen anlegen, ist der Inhalt der beiden Strings für Dein Programm tabu bzw. Du kannst nicht sagen, was sich bei einem erneuten Zugriff darin befindet.

Richtig haarig wirds dann, wenn Funktionen "von außen" darauf zugreifen müssen. Du mußt diesen Funktionen mit Deinem Programm garantieren, daß sich gültige Werte in diesem Speicherbereich befinden. Bei temporären Variablen mit eingeschränktem Gültigkeitsbereich kannst Du es aber nicht, wenn der Gültigkeitsbereich vor dem Aufruf der "Funktion von außen" verlassen wurde.

Grüße

--
---

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


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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Hm, stimmt schon. Hab hier auch im Handbuch was von"Garbage Collection" gefunden.

Ich sollte wohl wirklich in Zukunft solche Konstrukte lieber vermeiden.

---

Naja, die "Garbage Collection" gehört eigentlich zu jedem BASIC-Dialekt. Das Teil räumt einfach nur den Variablenspeicher auf, wenn selbiger knapp wird. Da wird bei Interpretern z.B. der ganze Kram nur neu geordnet (defragmentiert, sozusagen), um am Ende des Variablenbereichs wieder Platz für z.B. einen längeren String zu bekommen. Bei GFA war das Problem, daß auch temporäre Variablen im Variablenspeicher statt auf dem Heap landen (lokale Variablen hingegen nicht), so daß die temporären Variablen Speicher "geklaut" haben, den man nicht ausdrücklich freigeben konnte. Da kam die Garbage-Collection bei Programmen mit vielen temporären Variablen halt sehr oft zum Einsatz, was sich sehr negativ auf die Geschwindigkeit auswirkte. Beim Compiler war das kein Thema mehr, da dieser ja "voraussehen" kann, was mit verschiedenen Variablen gemacht wird und bei Bedarf einfach wieder Speicher vom System anfordern kann.

Das Konstrukt, was Du da verwendest, ist im Prinzip eigentlich schon nützlich, aber Du mußt darauf achten, wo Du es anwendest und wie es sich im weiteren Verlauf des Programms verhält (siehe das vorherige Posting). Da solltest Du also nochmal im Handbuch nachschlagen. Bei AmigaBASIC z.B. geht das irgendwann schief, auch wenn es da ab und an verwendet wurde (wenn auch eher selten in diesem Zusammenhang).

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:

Zitat:

---

Original von Holger:
buffer1&=SADD(SPACE$(size&))
buffer2&=SADD(SPACE$(size&))

---

Hab es eben getestet und etwas interesantes festgestellt:
1. Die Daten werden wirklich hintereinander im Speicher abgelegt. Wenn z.b. size&=10 ist, dann ist buffer2&=buffer&+size&, um es mal so zu tippen. Laut Handbuch belegen die Strings einen Tabelle und von da aus geht dann wohl ein "Link" zu einem anderen Speicherbereich.

---

[ - Antworten - Zitieren - Direktlink - ]

@Holger:

Da kommt man schon drauf, wenn man liest, daß der MB-Compiler eine Garbage-Collection einsetzt. Allerdings kann man das wahlweise aktivieren, wie Ralf schon andeutete. Die Anfälligkeit für Fragmentierung ist dann wohl eher eine Frage der Wahl der Compiler-Optionen.

Nichts desto trotz sollte Ralf mal nachsehen, wie MB mit temporären Variablen genau umgeht, das muß doch irgendwo im Handbuch stehen...

Grüße

--
---

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

[ - Antworten - Zitieren - Direktlink - ]

code:

---

DEFINT a-z
 
 size&=100
 
 in_port&=CreateMsgPort&:IF in_port&=0 THEN Ende
 out_port&=CreateMsgPort&:IF out_port&=0 THEN Ende
 in_file&=xOpen&(SADD("ram:test"+CHR$(0)),MODE_OLDFILE&)
 IF in_file&=0 THEN Ende
 out_file&=xOpen&(SADD("ram:test7"+CHR$(0)),MODE_NEWFILE&)
 IF out_file&=0 THEN Ende
 
 buffer1&=AllocMem&(size&,MEMF_PUBLIC&):IF buffer1&=0 THEN Ende
 buffer2&=AllocMem&(size&,MEMF_PUBLIC&):IF buffer2&=0 THEN Ende
 buffer&=buffer1&
 
 PRINT"Kopiere..."
 bytes_read=xRead(in_file&,buffer&,size&)
 WHILE bytes_read>0
  StartWrite out_file&,buffer&,bytes_read,out_port&
  IF buffer&=buffer1& THEN
   buffer&=buffer2&
  ELSE
   buffer&=buffer1&
  END IF
  StartRead in_file&,buffer&,size&,in_port&
  WaitDosIO out_port&,dummy
  WaitDosIO in_port&,bytes_read
 WEND
 PRINT"fertig!"

Ende: 
 IF buffer2& THEN FreeMem! buffer2&,size&
 IF buffer1& THEN FreeMem! buffer1&,size&
 IF out_file& THEN x=xClose(out_file&)
 IF in_file& THEN  x=xClose(in_file&)
 IF out_port& THEN DeleteMsgPort out_port&
 IF in_port& THEN DeleteMsgPort in_port&
   
SUB StartRead(bptr&,buffer&,size&,port&)
 fh&=bptr&<<2
 IF fh&<>0 AND PEEKL(fh&+fh_Type%)<>0 THEN
  packet&=AllocDosObject&(DOS_STDPKT&,TAG_END&)
  IF packet& THEN
   POKEL packet&+dp_Port%,port&
   POKEL packet&+dp_Type%,ACTION_READ&
   POKEL packet&+dp_Arg1%,PEEKL(fh&+fh_args%)
   POKEL packet&+dp_Arg2%,buffer&
   POKEL packet&+dp_Arg3%,size&
   PutMsg PEEKL(fh&+fh_Type%),PEEKL(packet&+dp_Link%)
  END IF
 END IF
END SUB
SUB StartWrite(bptr&,buffer&,size&,port&)
 fh&=bptr&<<2
 IF fh&<>0 AND PEEKL(fh&+fh_Type%)<>0 THEN
  packet&=AllocDosObject&(DOS_STDPKT&,TAG_END&)
  IF packet& THEN
   POKEL packet&+dp_Port%,port&
   POKEL packet&+dp_Type%,ACTION_WRITE&
   POKEL packet&+dp_Arg1%,PEEKL(fh&+fh_args%)
   POKEL packet&+dp_Arg2%,buffer&
   POKEL packet&+dp_Arg3%,size&
   PutMsg PEEKL(fh&+fh_Type%),PEEKL(packet&+dp_Link%)
  END IF
 END IF
END SUB
SUB WaitDosIO(port&,rc)
 x=WaitPort(port&)
 msg&=GetMsg&(port&)
 packet&=PEEKL(PEEKL(msg&+mn_Node%)+ln_Name%)
 rc=PEEKL(packet&+dp_Res1%)
 FreeDosObject DOS_STDPKT&,packet&
END SUB

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von whose:
Nichts desto trotz sollte Ralf mal nachsehen, wie MB mit temporären Variablen genau umgeht, das muß doch irgendwo im Handbuch stehen...

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Ich komme bis "kopieren...", das wars.

---

Dann liegt Dein Fehler irgendwo zwischen "kopieren..." und "fertig!".

Im Ernst, hast Du schonmal ein paar PRINTs mehr eingefügt, um den Fehler zu lokalisieren?

Zitat:

---

code:

---

in_port&=CreateMsgPort&:IF in_port&=0 THEN Ende
 out_port&=CreateMsgPort&:IF out_port&=0 THEN Ende

---

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:

SUB WaitDosIO(port&,rc)
...
packet&=PEEKL(PEEKL(msg&+mn_Node%)+ln_Name%)

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:

Zitat:

---

Original von Ralf27:

SUB WaitDosIO(port&,rc)
...
packet&=PEEKL(PEEKL(msg&+mn_Node%)+ln_Name%)

---

Haut so nicht hin, da mn_Node eine in der Message eingebettete Struktur ist. Korrekt müsste der Zugriff packet&=PEEKL(msg&+mn_Node%+ln_Name%) lauten, vorausgesetzt, dass mn_Node% erwartungsgemäß 0 ist, da die Struktur am Anfang der Message liegt.

---

Das isses!



Jetzt läuft es! Danke!



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

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Geht das so wirklich, CreateMsgPort& ohne runde Klammern? Ich würde trotzdem CreateMsgPort&() schreiben, aus naheliegenden Gründen.

---

Das läuft so. Aber es stimmt schon, damit man es als Funktion erkennt. MBasic würde sogar jammern wenn ich CreateMsgPort als Variable nutzen würde(wenn ich vorher auch die Includes eingebunden habe, logisch).

Im ersten Beispiel hatte ich es ja auch mit () stehn. Sieht auch besser aus.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Wenn ich das Lesen starten und dann sozusagen "abbreche", dann seh ich wieviele Bytes ich bekommen habe.
Aber ganz anderst sieht es beim schreiben aus, das da wohl nicht kontrolliert wird. Und das verwundert mich etwas. Kann es denn nicht sein das bis zu diesem Zeitpunkt nur ein Teil gespeichert wurde und der Rest noch nicht sicher ist?

---

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
@Holger:
Hm, dann bringt mir das ganze ja doch nichts. Ich kann doch dann eigentlich auch genausogut mit Read() so lange warten bis ich vermutlich Daten im Buffer habe. Und dieses "vermutlich" läst mich halt auch wieder Haare raufen.

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Holger:
Mir ist nicht ganz klar, wie die Struktur Deines Programm aussehen soll. Die asynchrone I/O bietet Dir die Möglichkeit, beliebige Dinge während der Read-Operation durchzuführen, damit ist eigentlich kaum noch eine Einschränkung vorstellbar für, was auch immer Du tun willst.

---

Zitat:

---

Wenn Du wissen willst, ob Daten anliegen, kannst Du einfach überprüfen, ob am zugehörigen MessagePort eine Antwort vorliegt. Wenn nicht, sind noch keine Daten vorhanden. Natürlich musst Du irgendwann, spätestens bevor das Programm sich beendet, definitiv auf die Beantwortung des Packets warten, um dessen Speicher freizugeben und die Datei zu schließen.

---

code:

---

msg&=GetMsg&(in_port&)
 packet&=PEEKL(msg&+mn_Node%+ln_Name%)
 Bytesdiedasind=PEEKL(packet&+dp_Res1%)

---

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Hm, leider hab ich kein Plan wie ich aus dem Port die Info über die Anzahl der vorhanden Bytes raus bekomme.

---

Zitat:

---

Kann es so einfach sein?!?

---

Zitat:

---

Ich brauch nicht immer Daten, sondern nur dann wenn sie da sind.

---

[ - Antworten - Zitieren - Direktlink - ]

@Holger:

Ursprünglich wollte ich in diesem Thread wissen ob es für normal sterbliche eine einfach Möglichkeit gibt ein Programm über das Netzwerk zu einem anderen Programm zu verbinden.

Dann bin ich auf ein Programm vom Thomas gestoßen das mit diesem TCP: sogar eine Datei runterläd. Bzw. wollte ich dann auch eine Updatefunktion einbauen.

Es geht hier im ganzen Thread dann um zwei Dinge:

1. Netzwerkverbindung zwischen zwei Programmen für ein Spiel, das nicht Zeitkritisch ist.
2. eine Programmupdatefunktion

Nr.2 läuft erfolgreich
Nr.1 macht noch Probleme, bzw. wohl bald nicht mehr.

Edit:

Zitat:

---

Für die Implementierung eines Netzwerkprotokolls sind Dateioperationen nicht geeignet. Dafür gibt es ja Netzwerk-APIs.

---

Das ist mir auch klar, aber ich hab schon recht lange gebraucht das hier zu verstehn, ich will euch das mit dem Netzwerk-API nicht antun.

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

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

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

@Holger:

Also, wenn es so läuft wie es laufen sollte, dann müßte ich mit diesen Infos die Netzwerkstory im Programm einbauen können.

Ich will auch endlich wieder eine neue Version von diesem Programm online stellen, aber leider hängt es seit Wochen an der Grafik. Ich selbst bin leider ein noch schlechterer Pixler als Programmierer und ich will keinem meinem Pixelwunder zumuten. Da muß ich noch was machen.
--
http://www.alternativercomputerclub.de.vu

[ - Antworten - Zitieren - Direktlink - ]

[ - Antworten - Zitieren - Direktlink - ]

Zitat:

---

Original von Ralf27:
Ein Problem hat sich da eben eröffnet:

Ich hab schon eine schleife mit einem port&, mit dem ich das Menu, das Fenster und die Maus bearbeite. Wenn ich da keinen Input habe, dann geht der Task& mit WaitPort(port) schlafen. Aber wenn der pennt, dann kann ich ja auch nich wissen ob neue Daten vom Netzwerk, bzw. vom anderen Port reinkommen. Wie kann ich das ändern?
--
http://www.alternativercomputerclub.de.vu

---

[ - Antworten - Zitieren - Direktlink - ]

@Ralf27:
Du musst halt auf mehrere Port gleichzeitig warten. Das ist ja der Vorteil der asynchronen I/O, dass man genau das tun kann.

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

[ - Antworten - Zitieren - Direktlink - ]