World: r3wp

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.

But I've found a bug in the current version:
5/11-10:57:51.468-## Error in [mod-static] : Make object! [
    code: 500
    type: 'access
    id: 'cannot-open

    arg1: {/F/SVN/cheyenne-server/Cheyenne/log/h-arch.desajn.web:8080-access.log}
    arg2: none
    arg3: none

    near: [write/append join log-dir [req/vhost #"-" log-file] second]
    where: 'do-handler
] !
The #":" is not a valid char for a file name.

Is it possible to disable debuging per page?

Yes, that's a new feature of revision 103, use debug/off (see Changelog.txt).

Thanks for the bug report, I'll fix it before publishing the new 
revision.

SVN r105

FEAT: debug mode can now be restricted to a given client IP address: 
debug/options [ip: 1.2.3.4]
FIX: debug menu now inserted only in pages with HTML content-type

FIX: (regression) debug menu and RSP errors now displayed even if 
response/buffer is empty

FIX: inlined colors for debug trace window (to avoid CSS overloading)

FIX: bad log filename generation when using a virtual host definition 
that includes a port-id
FIX: Cheyenne logo updated for default test pages

I'll do some more testing tonight before releasing new binaries.

Revision 107 binaries now available: http://cheyenne-server.org/blog.rsp?view=23

Thanks

WOW.. I've been away for a while and cheyenne moves years ahead!! 
very cool!

Is anybody running cgi scripts under Cheyenne on OS X? It seems that 
the environment variables are not getting set as the driver only 
seems to load the set-env librarires for .dll and .so

Is anybody running REBOL/Services as a cgi script under Cheyenne 
?

What set-env libraries?

Do you mean the binding to the set-env function in the C library?

Is the REBOL Library component available and being loaded in the 
version of REBOL you're using?

Yes the binding to the set-env function in the C libary. I'm using 
the encapped REBOL/cmd version.

The code in the Cheyenne cgi.r handler will only create the library 
binding for Windows and Linux.

I could patch cgi.r if I was certain that I should use /usr/lib/libc.dylib 
in place of /lib/libc.so.6 or .5

So do you have the Library component on OS X? That's what's needed 
to do it

Yes it has the Library component:

Is OS X detection missing in Cheyenne, then?

This is the code is cgi.r that creates the binding;

any [
				all [
					system/version/4 = 3			; Windows
					libc: load/library %kernel32.dll
					_setenv: make routine! [
						name	[string!]
						value	[string!]
						return: [integer!]
					] libc "SetEnvironmentVariableA"
					body: [_setenv name value]
				]
				all [								; UNIX
					any [
						exists? libc: %/lib/libc.so.6
						exists? libc: %/lib/libc.so.5
					]
					libc: load/library libc
					_setenv: make routine! [
						name	[string!]
						value	[string!]
						return: [integer!]
					] libc "setenv"
					body: [_setenv name value 1]
				]
			]

As you can see it is missing OS x

Detection is in misc/os.r. It's very simple, so I think it should 
work

It's not the detection that's missing, it's the binding to the correctly 
named lib that is missing.

Tracing it. That's odd: the general binding is done in misc/macosx.r. 
I don't see why cgi.r should do it double

You can copy the relevant code from macosx.r to cgi.r

Thanks, Kaj  - I'll try to check that out later.

Tracing it. That's odd: the general binding is done in misc/macosx.r. 
I don't see why cgi.r should do it double

The CGI.r code is run in a separate process, it inherits OS bindings 
from misc/macosx.r only when encapped. It should have worked using 
the  /cmd binary, I need to look into it and patch the CGI code to 
not bind twice when encapped.

Just to confirm that I am running the /cmd binary.

.. and am running CGI scripts not fastCGI scripts - I even checked 
that the env variables are getting set by running a trivial Ruby 
cgi,.

.. and they are not getting set.

and am running CGI scripts not fastCGI scripts

 REBOL scripts are run directly by CGI.r, the CGI interface is emulated, 
 set-env is not used for REBOL scripts. I'll do some testing with 
 non-REBOL scripts on OS X today.

Doc - I am trying to test running REBOL/Services CGI under Cheyenne. 
It looks as though REBOL/Services will not run as fastcgi so we are 
running as an ordinary cgi.

The actual system will run under Windows but we've encountered a 
strange problem. I'm trying to do some testing on my Mac to try to 
isolate the problem.

The problem is that the response back to the client is getting corrupted 
but we haven't isolated where yet.

This is a debug print of a correct response:
req/result [

    done [reply seq 1 service "Generic REBOL Service" commands 1 time 
    0:00] 
    ok [date 9-Nov-2010/2:16:33-7:00]
]

Quite often we get something like:

req/result [?done [reply seq 1 service "Generic REBOL Servidb" commands 
1 time 0:00] 
    ok [date 9-Nov-2010/2:16:35-7:00]
]

What are you using REBOL/Services for?

As an archive for images collected from remote cameras. (I didn't 
write the system). The system has been live for a few years. It currently 
runs under Xitami and I'm trying to help move it to a more modern 
web server. We are hoping to move to Cheyenne.


After the system has been migrated, we would then have the possibility 
to convert it, or parts of it,  to a Web App.