World: r3wp

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.

PeterWood: I've fixed the missing setenv mapping for Mac OS X in 
revision 108. Here are the binaries for you to test:
http://cheyenne-server.org/tmp/cheyenne-r108-pro-osx.gz
http://cheyenne-server.org/tmp/cheyenne-r108-cmd-osx.gz

You can also test it using the Perl CGI test scripts from the source 
archive in %www/perl (just change the shebang line to your local 
Perl interpreter path).

Btw, Cheyenne resets all CGI ENV variables after each CGI request 
for security concerns, so don't be surprise to not be able to see 
them from shell.

Many thanks, Doc. I'll test it straight away.

It's working fine, thanks - I can confirm that I can  access the 
env variables from a Ruby CGI.

Good!

Cool Cheyenne on OSX... I will give it a try on our new server.

SVN revision 110:

FEAT: default REBOL CGI scripts are now run as normal CGI.

FEAT: new config keyword: fast-rebol-cgi. Forces running REBOL CGI 
scripts in FastCGI mode.

FIX: (Windows) CGI handler rewritten to fix environment variables 
passing.

FIX: CGI 'set-env mapping code refactored, setup errors are now properly 
logged.
FIX: CGI scripts errors are now logged in %trace.log file.

Windows binaries are available for testing:
http://cheyenne-server.org/tmp/cheyenne-r110-pro.zip
http://cheyenne-server.org/tmp/cheyenne-r110-cmd.zip

New binaries for revision 114: http://cheyenne-server.org/blog.rsp?view=24

what was the difference between pro and cmd versions? Sorry if it 
was asked for several times before.

- pro: REBOL/Pro kernel
- cmd: REBOL/Command kernel

no functionality difference, right?