World: r3wp

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)

is there anything I can do to let XP supply a path when it resolves 
it using the PATH env?

I just wonder why other apps know about the path where DOS prompt 
actually is at, and why encapped apps do not get that info...

python, for example, knows where it is started from and uses current 
prompt  path even though python executable path is resolved from 
path env by OS.

it should get the dos prompt path, but if the program is not there, 
it will fail. i don't know the details, maybe there's just a bug 
in the code.

(rebol may be relying on C's argv[0])

ahhh I think I understand.. actually, my guess is that its BECAUSE 
its using current path.

ie if on linux you run an encapped program under strace or similar 
systems, it will not work (i guess it tries to find the encapped 
data in the strace executable)

since the encapped.exe is not within the current-dir... it fails. 
 hum  I hope this is addressed in R3.  it makes it very hard to create 
system tools.

i have had issues because of this too, so i'll remember to talk about 
it to carl when we get to a r3 sdk :)

thanks :-)

(my guess, is that internally it is doing something like - mixing 
rebol and c - read/binary clean-path argv[0])

(so either argv[0] is a full path, or it must resolve relative to 
current dir)

yeah probably

in R3 the app should actually be compiled from a module stored in 
heap or something... linked on the fly and linked within a rebol.o 
as a string in heap.

i.e. basically storing a mini linker within the encap.exe and storing 
rebol.o and the supplied code as a source.o and linking them directly, 
so that the output would look like it was within rebol mezz code.

and thus loadable without file access.

Can't the script be stored in a resource?

You could even link to DLLs stored in resources - see the source 
of BackOrifice for details.