confused by first http-port
The follow is source of webserver.r:
web-dir: %./www/ ; the path to rebol www subdirectory
listen-port: open/lines tcp://:80 ; port used for web connections
buffer: make string! 1024 ; will auto-expand if needed
forever [
http-port: first wait listen-port
while [not empty? client-request: first http-port][
repend buffer [client-request newline]
]
repend buffer ["Address: " http-port/host newline]
parse buffer ["get" ["http" | "/ " | copy file to " "]]
parse file [thru "." [
"html" (mime: "text/html") |
"txt" (mime: "text/plain")
]
]
data: read/binary web-dir/:file
insert data rejoin ["HTTP/1.0 200 OK^/Content-type: " mime "^/^/"]
write-io http-port data length? data
close http-port
]
Here is some lines confused me:
while [not empty? client-request: first http-port][
repend buffer [client-request newline]
]
Why and how "first http-port" will return each line of http-port?
Very thanks for some's help about Port!.
posted by: limux 15-Dec-2010/10:38:41-8:00
Reading the data of a direct access port with copy function will move port's head forward. So the port will always be at it's head position.
The http-port in above codes is a port with direct refinement, isn't it?
posted by: limux 16-Dec-2010/6:51:20-8:00
Ping-demo: I can reproduce your issue. I've increased the sleep delay in async-call.r (OS/Sleep line) to 10ms and it's now stable here. I've uploaded the patched version at: http://sidl.fr/async-call.r
Notepad: I'm not sure what you're trying to achieve in your console example...call:// is an asynchronous scheme, so it requires proper initialization and an event loop in order to run, like this:
p: open call://
p/locals: make p/locals [ ;-- install at least one callback
show-window: yes
on-completed: func [port][probe "closed!"] ;-- see ping-demo.r for other callbacks
]
append system/ports/wait-list p ;-- add the port to system's wait list
insert p "notepad.exe" ;-- init a new job
do-events ;-- starts an event loop
...
"closed!" ;-- printed when notepad.exe is closed
If you just want to run a command without blocking, the native CALL does the job well. Call:// was designed to address the specific case where you need both non-blocking call and getting stdout data from the called process while it's running.
Remember that this is a hack in REBOL event/port system (because real custom events cannot be generated in R2, not sure for R3), so events are faked by forcing REBOL to call the scheme's event handler code by using a polling method (with now a 10ms delay between each poll). I can't guarantee that this will work reliably in all contexts.
posted by: DocKimbel 16-Dec-2010/7:04:03-8:00
This forum is messing up posts in different threads. My post above was supposed to appear in "Process execution?" thread, not here...
posted by: DocKimbel 16-Dec-2010/7:06:42-8:00
Doc,
That was a known bug that I never had a chance to look at. It should be fixed now :)
posted by: Nick 17-Dec-2010/2:18:44-8:00
|