World: r3wp

hum  do you use it with any refinements? have you tried it specifically 
with the cgi option?

yes, and no.

ok, I guess its the stdout redirection which causes it to go wild...

(using cgi)

have you been able to print to the real stdout , allowing your encapped 
app to print within the DOS shell or be used within pipes?

never tried.

to print ... I call other applications, or send stuff to lpt1

I guess I should have said piped, or streamed to stdout.  I don't 
really want to print on paper ... but I guess you understood...

Maxim, the Detective uses the cgi option, and prints to the dos command 
prompt if you call it from there (try running "nren help"). It does 
not use call though, but async-call, but i don't remember problems 
with call + cgi options.

Is it possible to encap data files into the same .exe file as the 
script that uses them?

Louis, yes: http://www.rebol.com/docs/sdk/encap.html

Germol, thanks. I thought I remembered reading that it was possible. 
I'll read the docs again to figure out how.

#include-string and #include-binary are what you are looking for, 
i think.

Gabriele, thanks.

Gabriele: asynch-call?

Gabriele, my issue, is that I am trying to capture the output of 
the applications I call.  For this I need to use /console AFAIK. 
 but when I do so, the encapped app just goes mad and enters some 
kind of deadlock at 100% cpu usage.

async-call :  WOW !  direct re-implementation using kernel32 lib!

I will test using it.  the page talks about a polling loop which 
consumes a lot of cpu... can this be improved (like inserting a wait 
0.01) ?

anyone tried killing currently running tasks?  or now how to?  this 
could be an interesting opportunity for me.

about fixing cpu busy look :-)  found a working solution.

; wherever you insert the asynch call  to system wait list... you 
also add 0.1 (or any other appropriate value for your app)
; this will obviously quit the event loop immediately.
append system/ports/wait-list clist
append system/ports/wait-list 0.1


then, where you normally call do-events OR at the end of your app, 
if not using do-events manually... you put the following:
forever [
	do-events 
]

and you have a 0% CPU consuming multiple asynch call loop.  I tried 
with the ping demo provided with async-call and it works perfectly 
on all the tests I did.

The only thing you now need to do is trap an exit condition within 
your forever loop, otherwise the application runs in the background 
forever.

; something like:
if empty? system/view/screen-face/pane [quit]

well, I did a little bit more testing and the above procedure does 
not seem to reduce rebol CPU usage while waiting for calls.  but 
I do have a method which allows you to trade off view interactivity 
for diminished cpu usage.  This obviously also slows down the async 
calls interactivity, but in most cases, this is not a real concern.

here is a new procedure (very effective)

append ports: system/ports/wait-list call-ports-list
append system/ports/wait-list 0.001
forever [
	system/ports/wait-list: []
	wait 0.1
	system/ports/wait-list: ports
	do-events
	if empty? system/view/screen-face/pane [quit]
]

but now, the same application (ping-demo) consumes at most 10% activity 
and often under 5%  and there is almost NO discernable difference 
in view interactivity and overall call feedback !

Maxim, no, you need /output to capture the output; /console sends 
the output to the console, but there is no console if you use the 
cgi option, so probably this does not work correctly.

/output does the same thing

/wait too.

any refinement just makes call in encap go wild (on windows)  using 
dir as the command

my async-call function does polling every 0.5 seconds, there is no 
busy loop like in the original port scheme by Nenad (mine is an improvement 
over his code). note that it is GPL. (I would be ok with making it 
BSD, but the original code from Nenad is GPL). it uses timers.r though.

my version also supports linux, *bsd and mac osx. (osx we have troubles 
with though, still need to investigate it)

if only people would license librairies with LGPL ' :-/

of course i also have a kill-process function to kill the process. 
even on windows. :)

(i didn't believe it, but windows does not have any way to kill a 
process - you must create a new thread in that process with a call 
to ExitProcess... but this only on NT, older wins have no way to 
do this)

I know its one of the reasons render farm management apps on windows 
are sooooo hard to write

hehe, so where do I get your version of async-call  ;-)

you'll have to remove all the Detective dependent parts... then you 
should ask Nenad if it's ok to use it, unless your app is gpl :)

I might be able to coax him into releasing LGPL?

regarding your version...I don't mind the work...

No restriction using my version of async-call, I didn't remember 
it was GPL, it should be BSD. I'll change that .

http://www.colellachiara.com/soft/async-call-definition.r

ah, you're here. the file i had was gpl, let me check...

thanks guys  :-)

yep... my file is gpl. it's ok for me to change to bsd too. so you're 
fine maxim. :)

timers.r is on http://www.colellachiara.com/soft/libs/

together with other stuff you may need

you have some work to do... but it should be a good start.

Nenad is right, I looked in the release I got (v1.1) and its not 
gpl.  its basicelly BSD.

wrt stability have you guys encountered any limits or performance 
instability in some situations so far?

mmm, so probably the version i had - which was much before public 
release - had no license info, and i assumed gpl since the rest of 
the detective is gpl.