World: r3wp

Any reason not encapping with encmd?

Sounds great Doc. A lot of changes in there.

It's not a big issue for me, but sometimes I think about it, that 
the unused processes just sit there with allocated memory. "The threshold" 
sounds good imho.

Graham: I can provide encmd binaries too if it's allowed by RT?

I don't see the issue ... View now has cmd functionality and is free

I've been releasing cmd encapped binaries for cheyenne for a long 
time now

Ok then, I'll provide them asap.

Are  you encapping with 2.7.6 ?

Yes

Me too ... :)

keeps our RSP code at 2.7.6 as well....

All my code in production has been tested with 2.7.6, if I release 
binaries encapped with 2.7.7, I won't be able to test them as well 
as with 2.7.6.

All my code in production has been tested with 2.7.6
 => All my code in production relies on 2.7.6

2.7.7 didn't looked as stable as 2.7.6 when I first tested it (View 
crashed on linux, CALL's code seems to have changed). As I can't 
take any risk with my code in production, I've sticked to 2.7.6 so 
far. Maybe I should give it a more serious try now.

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