World: r3wp

Well, what advantage does using R3 have over R2?

none in an alpha state

If you don't use it, it will stay in alpha state

By the way, my Boron demos are running on Cheyenne in traditional 
slow CGI mode

I doubt my personal use of R3 with Cheyenne is going to affect the 
alpha status at all.

Maybe, but we started out talking about Carl's intended use

Long ago, there was a RESET function in REBOL.  It would restore 
the runtime environment without reloading the exe.


This allowed REBOL to run as an apache mod, because the process would 
persist and could start "clean" each time.

Such a thing could be done in R3.

And switching away from root still doesn't work with Core
... I've not tried it in Core, but it works nicely in rebpro.

I have a 2.5 K web server here that opens port 80, then switches 
to www uid, and runs fine.

Core still doesn't have the Library component, which Cheyenne uses 
for a number of functions

SVN r95

FIX: boot log improved, now every warning/error during boot will 
be logged in file even when verbose mode is not set

FIX: (UNIX) chey-pid-*.log files are now CHOWN-ed to target user 
when required (fixes verbose mode issue)

FIX: (UNIX) when user ID was not found in system file, it was accidently 
set to root ID resulting in no error reporting

This new revision should fix all known issues with running as non-root.

SVN r96 -> r103 (most of new features were suggested by Carl)  


FEAT: encapped Cheyenne binaries now returns 0 (or, in case of panic, 
a REBOL error code) on exit

FEAT: (UNIX) Added a new command line option: -V or --version. Displays 
Cheyenne's version, then quits.

FEAT: (Windows) Cheyenne's version is now displayed in the tray icon 
help message.

FEAT: RSP debug mode extended to display tail of trace.log file using 
a new [show trace] button.

FEAT: RSP debug bar look improved, menu horizontal alignment fixed, 
direct link to RSP API online
documentation added.

FEAT: RSP errors are now displayed in an overlay popup instead of 
being inlined in the page.

FEAT: RSP debug bar javascript code footprint reduced to a single 
object: rspdbg (avoids polluting global namespace)

FEAT: new RSP API function: debug. Switches the debug mode on or 
off, for the current RSP script.

FEAT: new API function: debug?. Returns TRUE if debug mode is active.

FEAT: 'debug config keyword definition extended to accept an optional 
block of parameters.

FEAT: RSP session/start now returns the session/active? flag as result.

FEAT: (UNIX) Added a new boot option: -h or --help. Displays the 
command line syntax help and quits.

FEAT: Improved RSP function 'validate to accept default values for 
optional parameters when using
the /full refinement.

FEAT: now plain REBOL scripts can also be run by the RSP engine! 
(see www/show.r)

FEAT: new RSP API function: emit. Does a REDUCE on its argument before 
APPENDing to response/buffer.

FEAT: added new RSP syntax for emit-action : <%? ... %>. Does the 
same as 'emit, but inlined in a
template page.

FIX: (Windows) improved child processes termination with a more graceful 
method using JobObject API

FIX: (UNIX) optimized child processes termination using a kill() 
routine! wrapper instead of CALLing the shell command
FIX: flush HTTP logs in cache on exiting.

FIX: mod-userdir was still commented in config file modules list, 
disabling user/group keywords in httpd.cfg

More info on the new RSP functions in changelog.txt file.

I'm freezing the code now to make a new official release in a few 
days. I'll provide the test binaries asap. If you find any bug or 
issue in this version, please post them here.

Revision 103 binaries, encapped with enpro 2.7.6:
- Windows: http://cheyenne-server.org/tmp/cheyenne-r103.zip
- Linux libc6 : http://cheyenne-server.org/tmp/cheyenne-r103.gz

Hi Doc, nice list. But would like to ask you, what about a way how 
to terminate long time unused worker processes? They are started 
automaticaly when needed, but there is no way how to stop them when 
the server has no activity.

Hi Oldes, good point, I was thinking about adding a worker processes 
user-controlled killing policy since years now, but it  has never 
bothered me on my production linux servers. 


Also, if you use the -w command line option, you can (in theory) 
set the threshold for workers kept alive after each request. In practice, 
a worker gets killed only if the threshold is reached and after a 
request is processed, so you might have cases, where more workers 
than should be, remains temporary after a burst of requests.


If it's really an issue for you, I can have a look at this feature 
to see if there's a simple way to implement a killing policy (would 
decrease the number of worker processes using 1 / t or e^(-t) function 
classes). See function plots at :
http://www.wolframalpha.com/input/?i=1+/+t
http://www.wolframalpha.com/input/?i=e^-t

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 !