World: r3wp

BrianH: about EXTRACT, there's no bug in 2.7.6 I'm aware of, it causes 
a regression on Cheyenne only because the old EXTRACT was wrongly 
returning a block! value when taking a hash! value as input.

That regression is fixed in Cheyenne 0.9.19.

I will be maintaining a patch script for 2.7.6, though it is not 
yet online. All of the patches are in DevBase for now.

No patch-in-place though - replacement functions.

doc, were you going to rambo this 'no-delay issue?

I thought that you would do that  just before sending your laptop 
to Carl. ;-)

I'll fill a new ticket right now.

Is this going to affect Cheyenne much?  It's not as though cheyenne 
would be sending lots of small packets to clients anyway.

I think that the performance difference won't be noticeable.

In the meantime I can use this way to shut down Cheyenne locally 
when my program exits :)

What Vista version are you using? SP1?

No SP installed ... no room on my hard drive to install :(

Gosh ... rambo is full of spam submissions.

You should ping Gabriele about that.

RAMBO ticket filled (#-4313)

Rambo is always full of spam submissions. I clean it up daily. :)

I'm guessing some elementary captcha code would cut down your work 
considerably!

It was discussed many times. I would use javascript to hide (enter) 
the form. It so easy. Just use document.write("<input name='submit' 
value='submit' type='submit'>"); where the input is as pure html. 
Better as external javascript. so the spambot parser does not see 
it without js evaluation (which are most such a spambots)

good idea, you don't even get the submits to start with   :-)

Have you tried http://softinnov.org/rebol/captcha.shtml?

We were getting tormented by spam at http://guitarz.org/pappgmembers/index.cgi
.  At one point I needed an immediate bandaid, so temporarily added 
a several-line cgi that just told the user to type "pappg" as the 
password, and then checked that they entered it correctly.  We've 
never had another problem since :)  Makes me think that a catchpa 
would handle a lot of grief.

You need a variety of techniques to stop all the spambots (and the 
human-assisted spambots).

Another technique is to have a hidden (by CSS) field, that humans 
don't see. If it comes back with a (changed) value, then most probably 
a bot is at work.

Our bots weren't the brightest :)

Sunanda, cute trick (as long as on mobile devices the CSS is not 
thrown away , which happens more and more now a days).

I suggested in the past a REBOL based question.

something which requires natural language interpretation.

Graham: except for scanning for actual legit tickets, it takes me 
a couple seconds to delete those (a few keypresses after logging 
in to rebol.net), so it's not much of an issue. i have to log in 
to rebol.net daily anyway in order to log in to mail.rebol.net (only 
accessible from there) and check the free space (only ~1GB left on 
the disk). so we'd have to solve both problems at once for me to 
not have to worry about those machines. :)

If you prevented those spam tickets, you wouldn't have to worry about 
space!  :)

www.rebol.net and mail.rebol.net are different machines. it's not 
the rambo spam that's filling mail :)

Reichart -- part of the hidden text needs to be a label that says 
something like "please leave this blank" Then nothing can go wrong 
.... :-)

Oops -- Sorry, DocKimbel. We're off-topic here.

There is already a separate (and less public) group for this topic.....If 
we have more to say, let's continue in:
    Bad Bots

I have a very easy trick that works for preventing spam in forms 
but it needs aiax, no captcha, nothing to enter, ping me if interested

I was just reading about SCGI today: http://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface
Would there be an advantage to implementing this in Cheyenne?

It's basically a simplified, non-multiplexed alternative to FastCGI. 
It seems to me that it may have less overhead.

having fast-cgi would be fine. But - fast-cgi does not have sense 
for Cheyenne, no? Hmm, maybe it does, when you use e.g. php ...

Cheyenne has FastCGI already, and uses it to call PHP..

Excuse me if I'm wrong, but "Accept-Ranges: bytes" is not implemented. 
Can this be done ?

I've just tried to resume a file from Henrik's server, and noticed 
that it has "Accept-Ranges: none". I know this means the web server 
is advertising "you can't resume!" My download client can use this 
information to avoid trying to resume, but it would be even better 
if the server allowed me to resume too :-)

See the roadmap at http://www.cheyenne-server.org/roadmap.shtml(at 
1.x section).

Byte-Ranges

 -- way down the roadmap list after big-sounding items :-()  I have 
 to wait. No problem.

(Hmm... isn't it pretty easy, though ?)

(I didn't say that - of course it isn't as simple as it seems on 
the surface..)

It's not difficult, but requires deep changes in UniServe layer, 
so it takes some times to make the required changes without making 
regressions. Anyway, it's more a matter of priority, and dependencies, 
I need the full unit tests suite ready to start making such changes. 
From 1.0, I need completly stable Cheyenne releases without any regression.

Umm;   Go Doc Go!   not that you haven't heard THAT one before.  
;)

Just wanted to say I've started using Cheyenne with RSP yesterday 
to make some webapp and so far it all works awesome-ly! :)

I always thought that because cheyenne is pure rebol it will be quite 
slow but http_load got me 250 req/sec on a RSP page which is unusually 
good. I rememeber when I was playing with Lua a while ago (which 
is one of few the fastest dynamic languages) and Kepler(it's default 
webapp thing at the time) and I tested lua based webserver it was 
quite slow, same is known for webrick from ruby etc.. and also my 
php with all the needed includes were well below 50 r/s. So awesome 
job Dockimbel !

Thanks for these interesting info. Cheyenne has been optimized for 
speed, caching in memory, at all levels is the key for performances. 
There's still some space for some speed improvements.

The debug mode is also very nice, catching before redirecting also 
helps a lot

the biggest blockage in developing learning was just now when I was 
making login function and it stopped setting cookie, it took me at 
least half an hour looking at the code and then I discovered I disabled 
cookies by accident in FF webdev toolbar :)

If you have propositions for improving the debug mode, I'll be glad 
to hear them. 


I'm currently working on a new Cheyenne release with a big cleanup 
of all debug and error logging done by background RSP processes. 
It will basically generate only 2 log files : error.log and debug.log. 
You'll be able to send content to debug.log file using some functions 
like : 

- debug/print data

- ?? word

Btw, I've tried to use file locking method to be able to sync writes 
to the same file from several processes. None of the file locking 
code found on rebol.org works reliably enough. At best, all processes 
can write their content to the file, but the order is messed up (each 
line starts with a timestamp), so not usable in my case. I didn't 
want to try using OS native file locking API, I'm afraid that a frozen 
process could permanently lock the file and block all the other processes, 
so it's too risky (at least using only REBOL, I could have some escape 
strategy to avoid that).