World: r3wp

I'm having trouble getting Cheyenne running as a service with windows 
server 2003. I get this message when I try to start from the services 
list:
	Could not start Cheyenne Web Server service on local Computer.

 Error 1053: This service did not respond to the start or control 
 request in a timly fashion.

linode or slicehost? Marteen is for slicehost, Ken Collins is for 
linode, I like linode, any last counter advice? thx!

I liked linode but haven't tried slicehost yet

will you be using it for server or something less hungry , like crawler, 
bot.. etc? because for that there are even cheaper vps-s

I'll use it for cheyenne, web serving, thx for your advice, if nobody 
comes against linode , I'll go for it 8)

are there any noticable differences in features between the two? 
I will need a new vps too soon

I have used both Slicehost and Linode. Both provide excellent realiability; 
I did not experience any downtime with either provider. Linode provides 
somewhat more memory, storage and transfer allowance for the same 
price. I ran a benchmark against both and got about 15% better performance 
from Linode.

A big advantage for Linode is the amount of control it gives you. 
With Slicehost you have a single disk volume and your slice is either 
running or not. Linode allows you to have multiple volumes. These 
can be mounted simultaneously, which can be nice if you want to prevent 
/var/log from filling the disk.

In addition, as space allows you can have multiple different profiles. 
So you could run different distros from the same VPS, although not 
simultaneously.

yes, the different profiles is really cool feature , especially at 
developement experiment time

There are a variety of other nice features. You can have multiple 
users with different levels of control over your VPS. Another nice 
thing is that performance graphs are available over the web on the 
Linode Manager screen.

Another thing to be aware of is that Slicehost by default gives you 
a 64 bit distro. That caused me some problems I didn't want to deal 
with.

I was just talking to some client of mine and he proudly told me 
that they moved all stuff to 64 bit... and I scratched my head a 
little thinkihn about potential problems

Thank you Ken and Janko for these insightfull details.

One more question, what distro would you suggest? Any problem with 
rebol and Debian 4.0 ?

I always used debian , not sure what version and rebol always worked

Great, thanks Janko!

Amacleod: are you using the enpro or enface binary version?

I use Debian 4.0 32 bit and REBOL 2.7.6 runs with no problems.

Thanks Ken, that's what I'm going to use 8)

btw, http://journal.dedasys.com/2008/11/24/slicehost-vs-linode

Doc, I'm using Enface.
I'll try Enpro

Enpro does not work either


They work as an application but when I change over to service it 
won't start up. If I go to admin services panel I can see it there 
but I get the error message above if I try to start it.

Never tested the service mode on WS2003.  I have a WS2003 disk image 
somewhere, I'll see if I can reproduce the error.

just to say that I am still working on cheyenne based web-app .. 
I find cheyenne rsp api very well designed, everything is obvious 
and simple.. I will put out some sources of the tools I built to 
help me develop, nothing special but maybe can come handy to someone

Janko, perhaps you want to try the HTML dialect? http://www.hmkdesign.dk/rebol/html-dialect/docs/0.0.7/html-dialect.html

wow, I imagined smaller dialect but this is quite impressive. I won't 
use it for this project as I have most made it already, but I will 
look at it deeper for next. I also made a forms dialect also, which 
is not so different than yours at first sight at least.

Thanks Janko, the RSP API is very inspired by other APIs like ASP 
and JSP, so most of the credits goes to Microsoft and Sun ;-).

Does the mysql access support in Cheyenne call stored procedures 
yet?

Not yet, because that mysql driver version has not been officially 
released yet (still some bugs pending to fix).

My project will soon need stored procedure support, so I may be able 
to help you test the driver.

It would require a change in the RSP DO-SQL function to cope with 
several result sets.

Sure, more tester would be nice, you'll find the last driver beta 
download URL in the MySQL AltME channel.

Several result sets I don't need yet, but that sounds cool.

Technically MySQL stored procs require support for multiple results 
sets.

at least, at the driver level.

Fair enough.

Although I am using Cheyenne in the project itself, it has also been 
useful as a development and diagnostic tool lately :)

I'm glad it could help you.

I haven't been following here, but I have x64 if there's something 
someone wants me to try.

Brian, I'm sure you konow, but if you don't need multiple results 
you could use functions instead tehy work flowlessly with currend 
driver.

Doc, I'm going to update ws2003. Don't bother until I try again after 
updates...thanks.

I'm using stored procedures without problems

since Doc fixed some issues in his unofficial version

Updates made no difference...Having trouble with getting MySQL running 
properly too....Even XAMP is not wroking right. Must be something 
wacked on my computer or stuff running on WServer that I'm not aware 
of conflicting with this stuff.

Doc, any news on 0.9.19? I'd like to test it. Can test on OS X, OpenSuse 
64 bit, WinXP and Vista (32 bit)

I'm working on it today, I'll release a beta version in a couple 
of hours. Lot of fixes and improvements in this release.

New Cheyenne 0.9.19 beta version available for testing at : http://cheyenne-server.org/tmp/cheyenne-r0919.zip


Tested only on Windows  (my Linux image network has currently some 
issues).

ChangeLog (diff-ed from last test version) :


 o RSP: an HTTP redirection in 'on-page-start won't evaluate the page 
 script anymore.
	

 o CGI: mezz function READ-CGI now patched to be compatible with Cheyenne. 
 That's
	  the right way of reading POST data in REBOL CGI scripts.
	  
	o RSP: fixed a bug in session/add when setting a block! value.
	

 o Task-handler: fixed a network error on first packet read (high 
 load + fast hardware).
	

 o Task-handler: TCP keepalive mode activated (test workaround half-closed 
 connections).
	
	o Task-master: 
			o 'no-delay mode removed and replaced by 'keep-alive mode

   o now forks a new process as soon as one dies (not waiting for a 
   new request)

   o fix a long standing bug in queued job module name mismatching (can 
   happen under extreme load)
			o minor code cleanup
	

 o Uniserve: 'no-delay TCP network mode now switched off for all connections. 
 Fixes a

   stability issue on Vista and probably on UNIX with very high load.


 o RSP: fix a bug in 'decode-multipart when there's no file received.
	

 o UniServe: new logger service. Now all info or error logs, and debug 
 messages from

   CGI/RSP scripts are written in %trace.log. Additionnaly, you can 
   now log messages
	  using :
	  
	  		- debug/print msg 	; msg [string!]
	  		- debug/probe value 	; any mold-able value
	  		- ?? word		; works like REBOL's '?? function
	  		- ? msg		; alias for debug/print
	  

 o RSP: in debug mode, page generation time and SQL queries stats 
 now added at bottom
	  of pages.
	  
	o RSP: error in events from %app-init.r now logged.
	

 o RSP: fix a rare RSP freezing issue when an error occurs in %RSP.r 
 (for example, by
	  a user script that breaks RSP sandbox).
	  

 o RSP: sanboxing now protects from Exit/Return/Break calls made outside 
 of a
	  function context.
	  
	o RSP: %misc/rsp-init.r file removed.
	

 o RSP/CGI: New config keyword added in global sections : 'worker-libs. 
 It lists the

   librairies to load when a worker process is started. An optional 
   'on-quit section can

   be added to call cleanup code when the process quits. Examples :
	  
	  		worker-libs [
				%libs/mysql-protocols.r
				...
			]
		or	
			worker-libs [
				%libs/mysql-protocols.r
				...
				on-quit [
					%/libs/free-resources.r
				]
			]
	

 o Task-master: now you can reset all worker processes without stopping 
 Cheyenne. This

   is usefull when you need to force non-RSP/CGI files reload (helper 
   scripts, 3rd party
	  librairies,...). 
	  
	  	Usage:
	
			Windows : tray icon -> Reset Workers
		

   UNIX : kill -s USR1 <pid>	(<pid> is Cheyenne's main process ID)
	 
	 

  o Added a -w command line option to set the worker processes number. 
	 
	   	Usage:
	   
	  		$ cheyenne -w <n>		(n [integer!] : CGI/RSP process number)
	   

    Use -w 0 to help debug CGI/RSP code by resetting worker processes 
    after each request.
	   (it's like calling "Reset workers" after each request).

Complete changelog is available in %Cheyenne/Changelog.txt.

Command line option -debug has been replaced by -w 0