World: r3wp

I also wasn't convinced by the stablity of 2.7.7 so I've stayed clear 
of it as well.

I've switched to 2.7.7 a while ago I don't see problems with it, 
though some things which affect cheyenne more directly might not 
be issues I have relied on.

e.g. you have a different use case so it might be triggering problems 
that I don't usually encounter.

Right, Cheyenne puts /Core and /Pro at stress. 


Today, I spent almost an hour to spot a bug in the RSP engine (it 
was a regression bug), but no way I could figure out the cause or 
what part of the code was producing it. The error raised by REBOL 
was inside ATTEMPT, saying that SET/ANY in ATTEMPT couldn't set the 
value...?? The whole mess was caused by a missing AS-STRING after 
a LOAD/HEADER, branching the RSP engine code into a faultly path 
leading to a corruption of RSP own code and probably of some REBOL 
global words too (my raw guess, but it could have triggered an internal 
REBOL bug as well). That's the dark side of having a fully modifiable 
language, a very small mistake can lead to a total session corruption 
with a cause very hard to track.

Encmd binary 2.7.6 for Windows: http://cheyenne-server.org/tmp/cheyenne-cmd-r103.zip
I'll release the other missing binaries tomorrow.

I've been running my sites on 2.7.7 without problems

On Linuxes where View 2.7.7 crashes, you need the other build (probably 
Fedora instead of Linux/Ubuntu)

That may mean you'd need two Cheyenne encaps if you want to encap 
with View

Doc - R3 might be better in that regard - it is a bit less "modifiable", 
more precisely defined, and it has modules too. But - there will 
probably be no Cheyenne for R3, so :-)

Modules will surely help secure the environment at runtime, but you 
can still accidentally corrupt your own code, it's part of REBOL 
nature.

0.9.19.103 binaries for main platforms available now: http://cheyenne-server.org/blog.rsp?view=21

Doc, only an hour? That's a good day for me with rebol sometimes:-) 
thanks for the new version.

an hour?

From your Wed 3:01 PM post where you mentioned you "spent almost 
an hour to spot a bug..."

Ah, yes, I guess I was lucky.

SVN r104: 

- FIX: port-id's relocation for multiple Cheyenne instances support, 
wasn't working correctly.


Do not use r103 binaries to run multiple instances of Cheyenne. I'll 
update the binaries asap.

Doing a little catch up here...

I'm having a little fun trying to set far future expiry dates from 
Cheyenne.


There seems to be some conflict between the httpd.cfg and the script 
as to whether the anem is expire or expires.

Having changed expire to expires, I get the follioing messages when 
I start up Cheyenne:


29/10-11:48:27.025934-## Error in [uniserve] : Cannot open server 
RConsole on port 9801 !

 29/10-11:48:27.053752-## Error in [uniserve] : Cannot open server 
 Logger on port 9802 !

 29/10-11:48:27.060870-## Error in [uniserve] : Cannot open server 
 MTA on port 9803 !

 29/10-11:48:27.061148-## Error in [uniserve] : Cannot open server 
 HTTPd on port 8000 
!

29/10-11:48:27.061893-## Error in [uniserve] : Cannot open server 
task-master on port 9799 !

anem -> name

Using RebCmd 0.9.20 with mod-expire.r from 0.9.19

Peter: the error you get is caused by trying to run multiple sessions 
of Cheyenne at the same time, see my post at Thu 19:04 about that.

About mod-expire, I'm not sure to see where precisely the conflict 
you're mentioning happens?

Thanks  Doc. I must have forgotten to stop a previous session before 
starting a new one.

I ferlt the conflict with mod-expires was:

htttpd.cfg

modujles [
   expires   ;; initially commented out
]

%mods/mod-expire.r

I'll check again.

I have mod-expire(s) working now - I changed the script name to mod-expires.r

I also have it working with by using expire in the list of modules 
with the script named mod-expire.r

I guess you had an old version, from SVN repo, it's "expire" in httpd.cfg.

Maybe I mistakenly added the s - not too worry, it's working fine 
now. 

Thanks for your help.

For Cheyenne fans, finally some logos to spread everywhere. ;-) 
http://cheyenne-server.org/blog.rsp?view=22

Nice.

Yes, nice ones

I'm having problems with post data and Rebol CGI scripts under Cheyenne. 
I ran a simple test scipt to simply echo back the post data:

#!/usr/bin/rebol -cs



REBOL []


data: make string! 1020

buffer: make string! 16380

while [positive? read-io system/ports/input buffer 16380][

    append data buffer

    clear buffer
]


print "content-type: text/plain^/"

print data


The script echoes back the post data when run under Apache but prints 
an empty line under Cheyenne.


(Just to check I ran a similar Ruby script which successfully echoes 
back the post data in Ruby).

I'm running 0.9.20 encmd.

I think this would work if you would force Cheyenne to execute it 
as a real CGI script

But normally, Cheyenne recognises a REBOL script and executes it 
as Fast CGI, in the UniServe process itself

Cheyenne has then already read the post data, and makes it available 
in the word INPUT

I think you can see this in the show.cgi example

Thanks Kaj. I'll take a look at it.

I would prefer to force Cheyenne to execute the script as a real 
CGI Script as I am trying to run REBOL/Services as a CGI script under 
Cheyenne. Ideally, I don't want to have to change the REBOL/Services 
code. (I am migrating a REBOL/Services application away from its 
existing web server and hopefully to Cheyenne. In the longer term, 
it may be possible to convert it to a Cheyenne web app).


Any hints on how to force Cheyenne to run a .cgi file as a real CGI 
script?

But why? It's a lot slower

Are there conflicts between REBOL/Services and Cheyenne?

REBOL/Services uses POST data and I'd prefer not to have to change 
the actual REBOL/Services code.

Or does REBOL/Services have a CGI interface?

Ah, then IIRC you have to add at least 256 bytes of junk before the 
REBOL header

Thanks, I remember now - I'll give that a try.

That works. I'll now try it with REBOL/Services.

Is it possible to disable debuging per page?

hm.. maybe it's not needed. Forget that.