Home   Archive   Permalink



Process execution?

Is it possible to communicate between processes which I created using call or launch.
If I use "launch" then new rebol process is created, but then may I send output to stdout and get it from the first process? or wait for output with a timeout value?

posted by:   Endo       2-Jul-2010/8:18:32-7:00



You can use a network port (see the examples at http://re-bol.com, and be sure to read the section about ports first):
    
; server (run this script first):
    
port: first wait open/lines tcp://:55555
print join "Received: "first wait port
    
; client (run this script second, in a separate instance of REBOL):
    
port: open/lines tcp://localhost:55555
insert port ask "Send: "
    
    
R E B O L [title: "Network Text Messenger"]
view layout [ across
     q: btn "Serve"[focus g p: first wait open/lines tcp://:8 z: 1]text"OR"
     k: btn "Connect"[focus g p: open/lines rejoin[tcp:// i/text ":8"]z: 1]
     i: field form read join dns:// read dns:// return
     r: area rate 4 feel [engage: func [f a e][if a = 'time and value? 'z [
         if error? try [x: first wait p] [quit]
         r/text: rejoin [x "^/" r/text] show r
     ]]] return
     g: field "Type message here [ENTER]" [insert p value focus face]
]
    
    
R E B O L [title: "Network Binary File Transfer"]
; server/receiver - run first:
if error? try [port: first wait open/binary/no-wait tcp://:8] [quit]
mark: find file: copy wait port #""
length: to-integer to-string copy/part file mark
while [length > length? remove/part file next mark] [append file port]
view layout [image load file]
; client/sender - run after server (change IP address if using on 2 pcs):
save/png %image.png to-image layout [box blue "I traveled through ports!"]
port: open/binary/no-wait tcp://127.0.0.1:8 ; adjust this IP address
insert file: read/binary %image.png join l: length? file #""
insert port file

posted by:   Nick       2-Jul-2010/10:52:55-7:00



In my VOIP example, I wrote a receiver script to a file, and then executed it. Maybe that can give you an idea:
    
R E B O L [title: "VOIP Intercom"] do [write %ireceive.r {R E B O L []
if error? try [port: first wait open/binary/no-wait tcp://:8] [quit]
wait 0 speakers: open sound://
forever [
     if error? try [mark: find wav: copy wait port #""] [quit]
     i: to-integer to-string copy/part wav mark
     while [i > length? remove/part wav next mark] [append wav port]
     insert speakers load to-binary decompress wav
]} launch %ireceive.r
lib: load/library %winmm.dll
mci: make routine! [c [string!] return: [logic!]] lib "mciExecute"
if (ip: ask "Connect to IP (none = localhost): ") = "" [ip: "localhost"]
if error? try [port: open/binary/no-wait rejoin [tcp:// ip ":8"]] [quit]
mci "open new type waveaudio alias wav"
forever [
     mci "record wav" wait 2 mci "save wav r" mci "delete wav from 0"
     insert wav: compress to-string read/binary %r join l: length? wav #""
     if l > 4000 [insert port wav] ; squelch (don't send) if too quiet
]]

posted by:   Nick       2-Jul-2010/13:18:01-7:00



Thank you for the replies and scripts. I most probably go with this network oriented way, but still curious about communicating rebol processes with other methods.
    
Is it possible to give output to stdout?
I tried to run rebol in cgi mode also but no output on os prompt:
    
rebol.exe -cs --do "print {hello}"


posted by:   Endo       2-Jul-2010/18:59:25-7:00



This may help:
    
http://www.mail-archive.com/list@rebol.com/msg09763.html

posted by:   Nick       3-Jul-2010/23:28:49-7:00



call/console is probably what you need. The doc is at http://www.rebol.com/docs/shell.html
    
And these may be useful:
    
http://eclectic-pencil.blogspot.com/2007/06/redirecting-rebol-stdinstdout-under.html
    
http://reboltutorial.com/blog/redirect-shell-to-rebol-console/
    


posted by:   Nick       3-Jul-2010/23:34:30-7:00



Unfortunately none of them work as expected (on Windows at least)
call/console redirects shell output INTO rebol console.
But redirecting rebol.exe output to Windows console don't work.
I tried:
rebol.exe -w -c --do "forever [attempt [print do ask %~]]" 2>&1
rebol.exe stays in background and nothing happens.
Or is it Window console problem?
    
Did anyone get rebol.exe output into win32 console before?

posted by:   Endo       5-Jul-2010/3:40:24-7:00



This works properly:
    
rebol.exe -w -c --do "print now/time">i.txt
    
Not sure why this gives an error - someone who knows Windows console should be able to get it working, because REBOL is redirecting the output data correctly to file:
    
rebol.exe -w -c --do "print now/time">&1

posted by:   Nick       8-Jul-2010/0:19:02-7:00



This is also obviously piping output correctly:
    
rebol.exe -w -c --do "print now/time" | cmd.exe

posted by:   Nick       8-Jul-2010/0:32:41-7:00



So it's clearly a Windows command line issue - REBOL is outputting the data properly. You need the help of someone who knows cmd.exe redirection a little better...

posted by:   Nick       8-Jul-2010/0:34:28-7:00



I use Doc and Gab's async-call extensively. It works very well.
    
http://softinnov.org/rebol/acall.shtml

posted by:   Gregg       14-Dec-2010/13:48:57-8:00



Thank you Gregg, this is exactly what I was looking for.
Unfortunately it doesn't work on my PC (WinXP Pro SP3). I tried ping-demo.r example provided in async-call.zip, it starts pinging 3 different host, then process hangs. No response.
    
I tried using it from console, it looks like port stays in busy state even process ends.
    
     p: open call://
     p/locals/show-window: true
     insert p "ping www.google.com"
     ;wait several seconds, I see that ping.exe process end
     query p ;<-- always returns true
     wait p ;hangs rebol process (no user interface response, Task Manager says "No Response")
    
I'll examine the source and try to find the problem. Thanks.

posted by:   Endo       15-Dec-2010/3:53:56-8:00



Hi,
    
I have a newer version of async-call.r available here: http://sidl.fr/async-call.r
    
Let me know if it fixes your issue.


posted by:   DocKimbel       15-Dec-2010/6:54:34-8:00



Hi, I tried this version. It works better but still have problems:
    
     p: open call://
     p/locals/show-window: true
     == true
     insert p "notepad.exe"
     == none
     query p
     == true
     ;...closed the notepad, wait a few more seconds
     query p
     == true
    
     insert p "notepad.exe"
     ** User Error: port already busy!
     ** Near: insert p "notepad.exe"
    
     close p
     p: open call://
     p/locals/show-window: true
     insert p "notepad.exe"
     ;works again
    
ping-demo.r runs better, but if I disturb the events (moving window, typing something into textboxes) it hangs mostly (after 2-3 try)
    
On my last tries, it hanged in first try, I didn't disturb the events. one of those textboxes never changed to green, but the ping processes was finished.
    
Let me know if anything I can do.


posted by:   Endo       16-Dec-2010/3:43:47-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:05:01-8:00



Hi,
Thanks a lot, now ping-demo works well.
In notepad example, I was curios about query command.
Is it normal query returns true even I closed notepad?


posted by:   Endo       17-Dec-2010/2:57:25-8:00



In your Notepad example, you don't run any event loop, so, there's no way for the call:// port to update its internal state as no event can be generated or processed.

posted by:   DocKimbel       17-Dec-2010/4:25:05-8:00



I get it now. Thank you.

posted by:   Endo       17-Dec-2010/7:16:26-8:00