passing references to a function

[fhein]

First of all, my solution my solution doesn't work because the function works on a copy of the buffer, so the original question was if I could send a reference (like char** in c). But is there some kind of better solution, maybe one that even works with any combination of CR and LF termination? It's quite important that an empty line returns "" or none

<code>
buffer: (binary data from a port)

line: get-line buffer
line2: get-line buffer

get-line: func [
   buffer
   /local pos ret
][
   pos: find buffer #{0D0A}
   ret: copy/part buffer pos
   buffer: pos
   return ret
]
</code>

[Gabriele]

You could put the port in /LINES mode to have this done automatically for you.

Anyway, to answer your question:

Code:

get-line: func [
   buffer
   /local pos ret
] [
   if pos: find get buffer #{0D0A} [
       ret: copy/part get buffer pos
       set buffer pos
       ret
   ]
]

line: get-line 'buffer
line2: get-line 'buffer

If you don't like using a LIT-WORD! in the function call, you could define it as:

Code:

get-line: func [
   'buffer
   /local pos ret
] [
  ; ...
]

line: get-line buffer
line2: get-line buffer

[fhein]

wo-hoo, it worked ^^

for some reason I though writing "get 'var" would try to get var from the global context, but I wrote a small test program to verify that it worked

(/LINES wouldn't work because it could mess up the binary content that might follow the header.. I think)

[Gabriele]

/LINES: what you would do is read the header in lines mode, the switch to binary mode for the content (using SET-MODES).

[fhein]

Are you good with network ports and such? I'm not 100% sure how everything works.. For example, when I wait for some ports and get an event, how much data can I expect to find in the receive buffer? If the port is in lines mode, is there guaranteed to be atleast one line there? Does tcp include some kind of block transfer, so that the client says "Hey I'm going to send 804 bytes now" and the port waits until it has received all those before it sends an event?

[Gabriele]

There is no guarantee on the amount of data being available. The port will be awaken whenever there's new data (this usually means a packet has just arrived), but you don't know how much. The /NO-WAIT mode is there just for this reason: COPY operations will not wait for the connection to be closed but just return you whatever is available.

About /LINES, I believe you should get at least one line. However, I haven't actually tested this out; it may be possible that if the other peer sent a very long line that arrives in two different packets, REBOL will have to wait for the second packet before being able to return you a line, yet the port may be awaken by the first. If this is the case, though, I'd consider it a bug and post it to RAMBO.

TCP sends data in packets. There's no way to know, byt TCP alone, how much data the other side is going to send. That's what the various protocols (HTTP, FTP, and so on) solve; for example HTTP includes the Content-Length header. The only thing TCP can tell you is that your peer sent the close connection packet, and thus will not be sending any more data.