World: r3wp

yet It seems impossible to even do a proper stdout call, so that 
another application can use my app's output ... (on windows).  I 
mean its just the most basic thing in any language.

can anyone tell me how I can encap something which would duplicate 
using the -c switch from standard rebol?  (which seems to allow me 
to pipe out )

http://www.rebol.com/docs/sdk/encap.html#section-8

thanks Volker, I have been trying to get to grips with the SDK.  
Somehow, I am lost when trying to find specific information... many 
times I try subjects, and I either encounter unfinished, incomplete 
or missing docs.   I do find some usefull tidbits here and there.... 
but its a pretty dry ride so far...

so far cgi in the header seems to work like a charm.  THANK YOU volker 
 :-)

now, why does using 'CALL within an encapped app cause it to freeze 
up and use 100% system CPU?

hum strange... the DOS prompt returns, yet I still have my encapped 
app running in the task list (at 100%)! my god, how is this possible?

call doesn't make encapped apps to freeze .. I use it all the time.

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...