World: r3wp

I guess you could say that!

hehehe

funny cause you know how in french it sounds so similar... hahahaha

;-)

ok reading a bit more of the read/write low-level... I am sort of 
assuming by what I see that write-io is blocking? mode transfer

so for each part of data that write-io dumps, that function will 
wait for the actual tcp xfer to finish... Am I dreaming?

No, write-io is not supposed to block in async mode. The comment 
at line 433, is not accurate enough.

It should be "potentially blocking operation".

That means that the outgoing buffer is not yet empty and that the 
write-io would block in that case (but that case is not allowed in 
async mode, so an error (code 517) is raised, allowing you to escaped 
and wait the next call to awake to retry a new write operation.

R2 async mode was never really finished. The way it works looks really 
like a ugly hack on sync mode. But anyway, it works.

escaped = escape

ok so basically you can be awaken while writing is still going on 
within the previous awake call... but the first one is still blocked, 
until that first write-io is done.

have I got it right?

(the first awake call, that is)

nope, you're not blocked by write-io. It returns at once (raising 
a 517 error if a writing operation is still going on).

ok, I see.

When you issue a successful write-io, the data is placed in a outgoing 
buffer processed asynchronously the TCP/IP stack while your REBOL 
code continue execution.

and what If I don't add 'write to the port/async-modes.  will write-io 
then be blocking?

Not sure, maybe.

ok, I'll do an out of uniserve test to see.

There's maybe some info about that flying around in the mailing list 
archives from RT staff (Holger or Jeff probably).

so there really is no sure fire way to know if the write really is 
done, when in async.

does the tcp stack awake us when it has finished?

unless I do a write-io and catch the 517 error... that would be an 
ugly way to poll the system, until it stops raising an error... hehehe

basically putting the write-io in a loop with a try within... waiting 
a small amount between tries... ugly but probably functional.

Yes, ugly, but that's AFAIK the only way to know when the data has 
been really sent. Btw, IIRC, REBOL is already doing busy looping 
in async mode to fire the awake event for 'write async mode.

in the async port specs, there is question of 3 args for the callbacks... 
how is that uniserve only uses the port parameter... is this because 
the port enters async mode after its been opened normally?


cause I remember building an async-port enabled application and it 
does have a write-done action.

callbacks being called "handler" in the docs.

Can you point me to that docs?

That was maybe with the experimental 2.5.5x async Core. It was released 
as alpha only IIRC, but never made its way in the official branch.

looks like it.

It was very close (same API) to what Carl did for R3 (I think he 
just cleanup the code from that old alpha version).

I am porting an app to the latest cheyenne, I tried -vv and -vvv 
and uncommented the debug option in cfg file but I can't make output 
+ error  -- in case of error - show up in the browser. I saw trace.log 
and chey-pid*.log but that doesn't help me debug current case. Is 
there a way to show in browser while developing?

the current problem is that something is undefined which suggests 
that it doesn't load some of my library files. I did this in   on-page-start 
before (during development - I intended to move it to on-application-start 
when it's in full production mode). First thought is that that function 
doesn't execute so I put print "zzzzzz" into it and look the output, 
but I am unable to see the output before error hapened with my current 
knowledge now as browser always shows the "Sorry this page cannot 
be displayed" page and the log files don't hold that string either. 
(I tried adding print "xxxxx" above function that causes error too 
so I know it get's executed and I couldn't  find the string in any 
output or log file

( Is there a way to show in browser while developing <== Is there 
a way to show whole output + error output in browser while developing, 
like it worked before )

cool.

I don't know what I did but now I see output in browser..

now that I can see output this is what's going on... I see that on-page-start 
is called, I do " do %bin/somelib.r   do %bin/somelib2.r ..." there 
, but libs don't seem to get included

What Cheyenne version are you using?

For showing errors in the browser, just put the DEBUG keyword in 
the webapp config block.

I guess you're using 0.9.19. DO has been redefined in the RSP engine 
to bind, by default, loaded code to webapp context. If you want to 
load libs that have to be visible in the global context, you have 
to use DO/GLOBAL.

That's one of the big change in RSP in v0.9.19.

Hi Doc. I am "porting" to 0.9.19 , the main thing that was causing 
causing the confusion since I didn't yet fully get it  was that "do" 
inside one of  another file that was "do-ed" didn't seem to use path 
relative to the that file but to web-app and before that wirtualroot 
property wasn't correct, I added the folder below root path.. now 
it works, and debug makes the whole output visible so I made it work 
better also.

But I have one really really big request for future if it's not yet 
possible :) could you make another flag besides debug (like devel) 
that would not add the debug info bar to webpages but would just 
show the error output in case of it (yer olde way - without the debug) 
.. or is this somehow possible to set up already?

I'm checking the code to see if there's a simple way to do that.

I will survive if I have to be in debug mode all the time :) I thought 
it will add some output to ajax responses too and make them unworkable 
but you seem to thought of this :)

The debug menu is inserted is a </head> or <body> tags are found 
in the output. Most of Ajax responses are either JSON data or HTML 
snippets (not reloading the whole page, so without <body> tag), so 
they're not modified.

is = if

smart

There's no way to have the debug mode without the debug menu currently, 
but it should be easy to add an option to define the debug level. 
I'm adding that to v0.9.20 todo list (scheduled for releasing before 
the end of this month).

ok, thanks a lot ... one day soon I will buy rebol so I can do little 
hacks and "recompile" myself , so I won't need to bug you for smaller 
stuff