World: r3wp

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.

Nenad, would you like me to supply the improved ping-demo.r to you? 
 cpu useage is much more reasonable...

I heard once or twice that some exe won't run correctly under asyn-call 
(freezing or no output).

the detective does a lot of calls, and is fine. there are gc bugs 
in older rebols though. the latest sdk should be fine but i haven't 
tested it a lot yet.

If the solution is generic, you can send it here: [dockimbel-:-free-:-fr]

doc, iirc the cpu problem you had was with using async-modes: 'write, 
which is a busy loop. am i right?

yep :-)  just a plain drop in replacement to your app.  and can be 
applied to any other app.

i'm just doing a poll every 0.5 secs or so.

but Gabriele might have a better (real) solution

correction, 0.25

using my timers.r, real timers would be much better of course...

real timers - part of R3 Core? :-)

i really hope so :)

although with tasks they're much less needed, ie you can just use 
multiple tasks and wait.

Gab: it's not using 'async-modes at all, it's related to REBOL calling 
automatically 'get-sub-port when port/in/state/inbuffer points to 
a string! value.

will tasks be threads or processes?

threads

sorry (should be in R3 group)

doc, i see.

handlers really need a network subport, although you can do a lot 
of things without.

The busy loop is generated by REBOL itself, it's a side effect i 
was using in async-call to do busy looping on the pipe while allowing 
other port events to be processed.

yep... that's why i made it a function instead of a port.

i'm using a different trick to implement timers :)

then timers to do polling on the pipes. on linux instead, you just 
get a signal when the command finishes, and read from the pipe - 
no polling needed.

doc, did you have kill too? i think that's only on my code, but the 
distinction is so blurred :)

Nope, 'kill support was your code only ; )

well, here is another strange SDK issue.

after encapping, an application works well ONLY if I supply the full 
path to the binary !?!?!?

If I setup the path environment and use an encapped application using 
only the filename, windows resolves the path for me, but I get the 
following error:

PROGRAM ERROR: Invalid encapsulated data

doing more testing, I have figured out that it seems like if the 
app has no "current working dir".  This I achieved by launching it 
through another app in which I have the option of launching with 
or without an explicitely set current working dir .

does this mean I cannot create command-line tools with encap?

encap needs to find itself. if it can not do that, it will not work.

huh?

can you explain more?  cause in the example I am doing... there is 
no dependency on anything external.

say you encap script.r into program.exe