World: r3wp

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

when you run program.exe, rebol start, and it has to load the code 
for script.r, which is embedded into program.exe

the current implementation needs to actually read the file program.exe 
to extract script.r from that

so if it cannot find the program.exe file (i.e., itself), it cannot 
extract the rebol code, and won't work.

but how can it launch itself, and not know where it is... I mean, 
the application actually loads! can't it just use appdir by default?

or is this something only the Shell can provide?

normally it can find itself because the os passes the file path

but, if the os doesn't, then it can't. (that's why, as you say, you 
need to provide a current dir)