World: r3wp

(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

The only case where this method doesn't work is when you need to 
send back XML data with embedded HTML (RSS for example). So your 
request is justified.

just one detail idea for improvement .. when you intercept redirection 
in debug mode you can use javascript to set focus on the link to 
continue already so developer just presses space or enter and it 
continues. No need to leave keyboard for mouse or to press tab tab 
tab .. enter :)  
document.getElementById('java2s').focus()

It seems app works with new one now .. no big changes were needed

I can send you link and username password once I set it on the new 
VPS

Thanks for the JS advice, I'll add that too. You should read all 
the ChangeLog entries for 0.9.19 to check for potential issues with 
your code (the new RSP webapp default sandboxing is the biggest compatibility 
breaker).

but sounds also the most awesome stability feature :) ... I looked 
at it, I will again .. this is a simple app at the end so I can test 
it quickly 


so I won't only criticise the new debug/log functionality ... for 
having it on server it's awesome that the trace log is made so I 
can just look at it and see it there were any errors for users, etc 
.. for that endo of the deal it's great

IIRC, you've proposed me some test scripts for Cheyenne, I'm very 
interested in such scripts. I have my own test framework, but it 
covers only a few basic test cases. I use it mostly for stress testing 
by simulating high loads (hundred of simultaneous requests).

aha, mine is reverse, no stress testing but functionality... I made 
it for webapps but with it you could also do automated testing on 
a sample of scripts and see at any point if all the features work 
.. it is very much in devel still ... I used it for testing site-assistant 
but it's more manual at this point.. I will impove it as one of my 
clients needs it for their app. I hope it will be more edible or 
usable soon, I will show it to you then.

I was planning to write a full unit tests suite while making the 
documentation for Cheyenne 1.0. I hope to be able to reach that milestone 
before the end of this year.

I'm also planning to work (probably this summer) on a high level 
web testing dialect allowing to implement more complex use cases 
simulating the work of a real user.

Yes, unit tests are very good for pure functionality (functions that 
don't affect the state) ... this is strictly for webapps, webapps 
is basically based on some state so unit test don't make sense except 
for the algoritmic part of webapp ... you can see sometning about 
this testing engine here .. http://itmmetelko.com/blog/2009/04/24/a-peek-into-wip-trail-testing-engine/

That's very interesting and inspiring work. It's close to my own 
thoughts about a web app testing framework. You're very right, the 
main target should be the webapp API, not the UI. That's why I didn't 
invest in Selenium, I don't want to update scripts every time I change 
the UI without changing features.