World: r3wp

Would you put a timer in the do-task/on-done func?


Not sure what you want to achieve precisely there. In your "READ 
quotes from remote server and send them every sec" scenario, I wouldn't 
use do-task, but async HTTP (much more efficient and scalable). I 
think I definitely need to add a few async schemes and make an example 
app.

Max: " the values of those words would be substituted when they are 
encountered."


I don't get where and how precisely this is supposed to happen (at 
Cheyenne boot time in %cheyenne.r like a preprocessor or at services 
install time in %misc/conf-parser.r as a dialect feature, and what 
could be substituted and what not, etc...). This does raise a lot 
of design questions and roughly looking, doesn't seem very different 
from what I was proposing. It seems that you'ld like the preprocessing 
occurs inside Cheyenne while I was more in favour of an external 
preprocessor script as I'm not sure how often users will need such 
feature.

Ok, thanks..

Doc, will your async-call function work with ws apps?

Requires /Library component! (needs /Pro, /Command or /SDK

this has changed, no?

what are the odds of getting an async handler that supports ssl?

2) Send the READ job to a worker process using DO-TASK (but it will 
block it for 30secs, so not a very scalable solution).

Tried this.. it's not very ws:// "broadcast" friendly

I was thinking that it could be added within the dialect... I might 
look how to add it myself and I could give you an example... maybe 
not now cause I have a lot of things on my plate, but the next time 
I go deep into cheyenne's guts (next time I work on mod-remark).

I should have my new site online within a week or two, using cheyenne 
on a linode server.  I did some of the design work this week, now 
I have to build the site around it.

I suppose having non-blocking async http and ssl, coupled with timers 
could make for a nice distributed system via ws:// . Could have clusters 
of Cheyenne :)

Async-call: yes, but not suitable for scalable server because it 
is doing intermittent busy looping to wait for incoming data from 
the child process. Once again, multithreading would have solved that 
issue.

Requires /Library component! (needs /Pro, /Command or /SDK
 : right, Core has /Library since a while.

Tried this.. it's not very ws:// 

broadcast" friendly" : I don't see why it wouldn't be? You send the 
READ job using DO-TASK and broacast the result from the ON-DONE handler.

Max: adding support for get-word! for the most common config keywords 
should be easy, just patch the config words definition in mod-static.r 
(and in other mods if required). But as you can see in mod-static 
defintions, the processing part for each keyword may not work with 
a get-word!. For example, 'root-dir expects a file! and will check 
for the trailing slash.

ahh.. i didn't use the ON-DONE handler.. just broadcast from the 
do-task part of do-task/on-handler

Why are think like Javascript not prefixed with a tilda?

sorry wrong group.

err.. scratch my last remark

what can be done is to substitute the value directly in the data 
by using change on the series and then moving one step back.  then 
the nnormal parsing will occur and the loaded value's datatype would 
be used normally  :-)

something like: [here: set value get-word! (change here get value) 
:here]

I have a weird delay happneing with the tts chat demo.. there's a 
pause of exaclty 30 seconds before the broadcast? I see no reason 
for this?

do any of the rebol loops have 30 second time-outs?? very strange

Anyway, I've restructured the echo demo.. should be much more responsive 
now

If anyone cares to try.. 

http://shinyrockets.com/echo.html

(Requires Chrome beta..  http://www.google.com/chrome/eula.html?extra=devchannel
(windows)

4.0.302.2 dev

works great :-)

If you want to see the debug tools in Chrome, hit CTRL-SHIFT-i

hehe looks like they hired the firebug coder to build the debug tools 
in chrome ;-)

yeah.. i still occasionaly use Firebug.. but rarely

Terry: echo is much faster now (1-2s delay only). 


For the 30s pause, that might be caused by a network timeout on a 
sync port action. 
>> system/schemes/default/timeout
== 30

yeah, I need an async https port.. still getting overlapping tts 
broadcasts when two or more people submit at thesame time.

It's like people trying to talk over one another, using the exact 
same voice :)

The delay is quite a bit less now - not too bad. I noticed that the 
last word (or part of one) seems to get cut off? Are you guys seeing 
the same?

yeah last word often gets cut on shorter strings .. need to get xml 
via https:// POST working for a solution.

It seems Rebol is causing the problem with the last word getting 
cut off..  I use a read/binary - write/binary of an .ogg file and 
the last bit is cut somehow?

Does it work outside of Cheyenne?

the read/write is fine.. I think it might be Cheyenne's dishing up 
of .ogg files.. ?

couldn't try it ..your server was offline

hmm.. maybe Chrome

Cheyenne has nothing against .ogg files. Are you removing ogg files 
once sent?

If Cheyenne would refuse .ogg files, then it would belong to Belief 
Systems :-)

ok.. did some tests.. it's Chrome.

Try this with FF and Chrome

http://shinyrockets.com/delme.html

(running on Apache)

although i did add the ogg to Cheyenne mime-types

http://code.google.com/p/chromium/issues/detail?id=33139

huh, I have to comment something.. I went looking what curecode looks 
like .. and founc this one http://curecode.org/rebol3/view-tickets.rsp
.. when I am clicking links the page reloaded so quickly that I couldn't 
determine if you are doing an ayax call or the whole page is reloading 
and I can't see it.. I also noticed this on my cheyenne projects. 


I don't get how you managed to do this. There are numerous servers 
outthere and rebol is not the fastest language and I haven't seen 
something like that anywhere?!?!? I mean I think also the static 
pages that you load from some webserver take some more time.. ?

I don't believe that cheyenne can be **THAT** much faster so that 
it's so visibly obvous. Do you send the page in some specific way?

:-)

No AJAX calls, nor other tricks. It's very fast for several reasons 
:
- almost no images.

- no JS lib to load and no JS code to execute when page is loaded.
- server is far from being overloaded.

- MySQL backend is very fast for read accesses (MySQL has a very 
efficient caching system for queries).

- Cheyenne RSP engine *is* fast (RSP scripts are compiled to REBOL 
code and generated code is cached in memory)