World: r3wp

Graham - Cheyenne is not good enough, if it can't repair HD itself 
:-))

That's a planned feature for Cheyenne v2 ;-)

We have some trouble with our provider, it hasn't yet answer to our 
HD replace request :-/. So still down...I'll set up a temporary download 
page on our softinnov.com server.

After some serious hardware troubles, and a complete system reinstalling, 
softinnov.org is up again, sorry  for inconveniences.

I'm testing and packaging the new Cheyenne beta release, it should 
be online in an hour.

Cheyenne release v0.9.17 beta. Download at http://softinnov.org/tmp/cheyenne-r0917.zip

See the changelog.txt file in the archive for more info.

As always, great great stuff! Thank you Dock!

Cheyenne beta v0.9.17 encapped binaries are also available for testing 
:

Windows: http://softinnov.org/tmp/win/cheyenne.exe
Linux: http://softinnov.org/tmp/linux/cheyenne
OSX: http://softinnov.org/tmp/osx/cheyenne


Remember that Linux and OSX versions require root privileges to listen 
on ports < 1024.

Thanks Will !

For OSX users, if you experience "invalid compressed data" errors, 
see http://www.rebol.net/cgi-bin/rambo.r?id=4306&

Test this release well before using it in production. Please report 
any bugs or issues in the online bugtracker : http://www.softinnov.org:8000/curecode/project.rsp?id=4

BTW, the binary versions are built using ENFACE, so View subsystem 
is available (but VID is not included).

For linux users that don't have X11 installed, the released binary 
won't work unless you install the X11 support libraries.


Here's how-to install the required libs without installing a full 
X11 desktop (Debian/Ubuntu users only) :

  > apt-get install libx11-6
  > apt-get install libxaw7
  > apt-get install libstdc++5
  > apt-get install libfreetype6

For non-Windows users, PHP need to be patch in order to work with 
Cheyenne. I'll post here a small HOW-TO in a few minutes.

...PHP needs to be patched...

HOW-TO make Cheyenne work with PHP for non-Windows OS


The purpose of the following patch is to make FastCGI in PHP work 
the same on all OSes.


1) If you have PHP v5.2.1 or higher with sources, you can skip 2) 
& 3) else :

2) Download latest PHP sources from http://www.php.net/downloads.php
3) Untar the archive anywhere yo want
4) Go to PHP install folder
5) Patching PHP source :

	Open a REBOL console, then :

;---- cut'n paste the following code in REBOL's console ----

patch-php: has [buffer pos][
	target: %sapi/cgi/fastcgi.c
	if none? attempt [buffer: read target][
		print "unable to find the file to patch!!"
		exit
	]
	either parse buffer [
		thru "int fcgi_accept_request("
		to "if (req->fd >= 0) {"
		pos: to end
	][
		insert pos "^/^-^-^-^-break;^/^-^-^-^-"
		write target buffer
		print "patch applied."
	][
		print "failed to locate the line to patch!!"
	]
]

patch-php
;---- end of code ----
		
6) Once the patch is applied :

	> ./configure --enable-fastcgi
	> make
	> sudo make install
	
7) Check if everything is ok :

	> php-cgi -h
	...
	you should see a -b option listed meaning you got proper
	FastCGI support.
	
	If it fails (occured on OSX), try with a full path instead :
	
	> /usr/local/bin/php-cgi -h
	

8) Edit Cheyenne's config file (httpd.cfg) to set the correct option 
in the PHP section. Non-Windows users have to also set the new 'delay 
option.

Great stuff .. and lots of new stuff too!

Not needed for me, but perhaps encmdface would be better than enface?

The issue with encapping with a /Command binary is that Cheyenne 
through CGI and RSP expose the REBOL dialect and expose all /Command 
stuff, for free...IIRC that's forbidden by REBOL license. Did this 
changed for latest SDK ?

Cheyenne v0.9.17 re-released. Now includes the source code for the 
%service.dll library. As a remainder, all the Cheyenne source code, 
including the service.dll source is release under BSD license.

hmm, I have Apache installed on port 80. So I manually changed httpd.r 
port setting in the object section but it did not work. So I tried 
via conf file and now it works. I wonder if directly setting port 
number should work too?

you can change the listening port(s) using the command-line :

cheyenne -p 8080

Conf file is ok too, using the 'listen keyword. You should not change 
it directly in the source code (the HTTPd.r port-id value is override 
by the following line in %cheyenne.r : foreach p any [port-id [80]][control/start/only 
'HTTPd p]

aha .. btw - how do I get to admin portal?

How close do you think you are to 1.0 relese candidates?

I would not prolong it for much longer :-) If ppl see alpha, they 
might be scared. If you feel it is solid enough already, I would 
go for 1.0.

btw - any chance of AddHandler like directive?

AddHandler: it's on my Todo list for 1.0 :-)

I'd really like to have the admin control panel in 1.0. So maybe 
I'll delay until I'll add, at least minimal, control panel.

In the meantime, I have also on my todo list a dedicated web site 
for Cheyenne. I'll work on that in the next days.

Doc, I've had talks with Carl about this, and i think he's more relaxed 
about it.  But you're probably right, so just leave it enfaced.

About Service.dll .. is this just for Cheyenne, or is there a general 
way for all Rebol apps to run as a service?

As a remainder, all the Cheyenne source code, including the service.dll 
source is release under BSD license.

=> "as a reminder ... "

Thanks for the fix :-)

Re service.dll : it could be used to add NT-Service support for any 
REBOL app. But currently, there's a few hardcoded parameters in the 
C source, so it would need at least a recompilation to work for another 
app. I was thinking about packaging this into a simple library...I'll 
see if can find some time to do that. But, in all cases, it requires 
at least /Library component.

that sounds great.

If it is solid, I could use such a dll right away.

It's in the latest Cheyenne distro.

Have you looked into srvany, seen how it interacts with the process 
it is loading?

not me .. I normally use fire daemon to run rebol scripts as services.

Maybe we could have service support in R3 as well?

There will be. It is planned.

I'm a little curious as to what service.dll does. As Dockimbel said, 
it is currently Cheyenne-specific, and it currently doesn't come 
with source (that I can find yet), but looking at the calling source 
it seems that it does not handle all of the service-related functions, 
just "ServiceLaunch". I wonder if there would be some merit to putting 
wrappers for the other service functions in that dll, or converting 
the ServiceLaunch function to REBOL and just doing calls to system 
standard dlls. Pulling the existing REBOL wrapper functions out into 
a seperate script and generalizing them would probably be a good 
idea, at the least.

See Cheyenne/service for the C source

The 0.9.17 beta source that I had doesn't have that directory, but 
upon redownloading the file it does. Thanks tor the heads up.

Yes, he said that he re-released that archive with the source.

service.dll does has a minimal effort to support services. It has 
only starting and stopping support. Stopping triggers a UDP packet 
sent to Cheyenne process to notify the shutdown message. That's the 
only way to communicate with a REBOL process. Windows message cannot 
pass because it requires a permanent window structure (not possible 
in service mode). Pipes coud be a solution but they don't trigger 
events in REBOL wait loop.

To be more accurate, it's possible for a service to have an opened 
window  (even if it's not visible) to receive messages, but in this 
case, I never was able to make it survive a session logoff / logon 
sequence. In Windows, there's also threads message queues, but REBOL 
doesn't seem to trigger events from that channel too. If SYSTEM port 
was able to support that way to communicate, that would be a better 
way for the DLL to transmit messages from the service manager.