World: r3wp

need a diagram to understand this ...

and if you want for the awake handler to be called again, you need 
to be sure to read event/port

i think you can easily cause a deadlock this way

WAIT on a port

this blocks on ports that were scheduled with read earlier on

now somewhen the awake handler will get called

return false from the awake handler, but do _not_ re-schedule the 
port

voila, you're deadlocked

the WAIT will keep on blocking, but the port was not re-scheduled 
with a read, so the awake handler will never be called again

wait [ port timeout ]

yes, as a user :)

as a scheme author, we have to be careful to avoid those deadlocks

to i think, awake should only finish with one of the following sequences:
1.) read event/port return false
2.) return true

except for 'lookup and 'close events, of course

re the bind: i store the stuff the awake handler needs in order to 
work in port/locals

as a context. with the bind i can make those values appear as if 
they were local words, i.e. buffer refers to event/port/locals/buffer

... ah ... I missed the client/locals there ...

when the second parameter to a function is more than 10 lines down 
the page ... .it escapes my eye!

yep, it's not that i'd consider it good style anyway ...

this world is playing busy again :(

http://www.rebol.net/wiki/TCP_Port_Details

very low-level, most of it a bit below our concerns :)

but it's good to know that we don't have to take care of partial 
writes

read reads a max of 32,000 bytes ... so does this mean if more data 
is coming, another read will be triggered?

yes

and i don't think that the 32,000 bytes given in this document are 
realistic

tcp packet size is typically limited to 1500 bytes, so for any significant 
transfer many 'read events will occur

but maybe the "Note: not 32K" comment wants to tell us that the default 
buffer size is 32 :)

I see that the buffer is shared for both reading and writing

A few issues a couple of years old http://www.rebol.net/wiki/Ports_and_Schemes:_Issues#Issue_4:_WAIT

remove the #

interesting, thanks

Managed to get a directory listing with my ftp scheme :)

Things are definitely looking up ....

a directory is just a file .. so this means I have file transfer 
"working "

Just looking at what R2 does .. .each time it does a file/directory 
transfer, it opens the data connection, sends the command and then 
closes it again.

Hmm. I did a LIST and only got 4000 characters back.  I tried it 
again, but delayed the read a bit longer and got the full 8000 characters 
or so.  So, wonder why the data arrriving is not triggering the read 
event

maybe I need to read the number of bytes from the buffer, clear that 
number and try reading again until none

http://rebol.wik.is/Rebol3/Schemes/Ftp
Updated ... I really need a rebol syntax formatter for this

Heh .. the ruby syntax colouriser colors the text strings mainly.

This isn't going to work unless I queue the user commands and process 
them once a command has completed.

It works on my server, but I tried it on one of the linux distro 
sites and there it doesn't.... as my write commands are written to 
the port before the previous commands have completed.

And the state machine becomes very confused ..

Probably, we should think about a framework to build state machine 
oriented processes.
A new dialect ?

Gregg made a cool FSM dialtect years ago.

dialect

is there a trick to read R3 dns:// ?  I haven't found it.  Didn't 
see any tickets in cure-code.  Should something be submitted there? 
 (last year was 100% R2 product design...I am wanting to port some 
Core stuff to R3, but I need as much network stuff as possible.  
I did write a real-time video codec for R3 a couple years ago...I 
might see if it can hook into the new codec stuff, too.

on-topic as it was also networked...;-)

There isn't a dns:// scheme written yet.

there is a low level dns lookup occuring in the tcp device ...

fish ... naughty .. you haven't released your video codec for R3