World: r3wp

Production mode: using the binary version as a daemon, instead of 
using the source version from a REBOL console.

im writing a json webservice and actually it's very annoying when 
i get a RSP error html page, instead of the usual rebol error.
 


debug/off should fix that: http://cheyenne-server.org/docs/rsp-api.html#def-65

because - normally - i shouldn't care about the webserver. that would 
be one of the great things about cheyenne. it's just a 1-file-webserver

(meanwhile i see there should be 1 vhost definition at least, so 
that's why the conf-parser fails; the error at: ! still doesn't make 
sense though :)
anyway, i keep on debugging)

I don't care about Cheyenne while coding RSP scripts or webapps, 
*but*, I always launch it in source mode (and never as a binary) 
on my local development box. That way, when something odd happens, 
I just have a look at the REBOL console and scroll up until I see 
what happened (so I never need to look at any %chey-pid* or %crash.log 
during development).

aha. and we can't start the binary in a similar mode, where the errors 
are not caught and logged, but showed in the console instead? (im 
trying to do a do %cheyenne.r now)

The Cheyenne binary version is meant for production, so all things 
are logged in files. If you want to have them in a REBOL console 
from the binary, you need to build a custom binary and change the 
encap options in the %cheyenne.r header. Removing the 'no-window 
option will redirect all logs (except %trace.log) to a REBOL console.

hm.. is this no-window thing documented?

BTW, if you launch Cheyenne from REBOL console, you can still pass 
it command line options, my local Cheyenne is launched using:

rebol -s cheyenne.r -vvv -w 0

No-window: yes, it's part of REBOL/SDK documentation.

i was trying:

onetom ~/p/ob $ rebol -qs --do 'do/args %~/rebol/cheyenne/Cheyenne/cheyenne.r 
"-w 1 -vvv"'

is this no-window option equivalent to the -w option?

IIRC, yes it is.

-w as REBOL option (to not confuse with Cheyenne's -w option).

sure

Here is the SDK documentation about encap headers: http://www.rebol.com/docs/sdk/encap.html#section-8

which means im not supposed to hack cheyenne (easily) unless i buy 
the SDK and learn encap?

because in turn that's what it means not to include this specific 
"trick" into cheyenne's documentation

and since im running it with the plain rebol/core, i wouldn't have 
thought that encap header might be relevant

You can hack Cheyenne as much as you want. The SDK is only required 
if you want to build a binary version of Cheyenne, which is not mandatory 
for using Cheyenne, even in production.

The encap header is only revelant if you build a binary, it is ignored 
if run from sources.

aahha... i was using the -w as usual, that's why i didn't see any 
output when i was starting cheyenne from source.

normally i use -w, otherwise pipeing the output doesn't work properly.
okay, everything makes more sense now.

Good. :-)

The binary is mandatory for using Library

command/core has library

Most people don't have Command/Core

nowadays, I think command is only available via the sdk, no?

should the hosts be configured via IP addresses?   it seems php has 
issues using localhost as a domain name.

## Error in [conf-parser] : Error in conf file at: !

was caused by writing a debug word outside of a vhost definition...

should = "should it be possible to configure host via IP addresses" 
?

u mean vhost? the docs says it is possible. but u can't listen on 
a specific address only -- it's a rebol limitation

yeah, but it seems php prefers using 127.0.0.1 instead of localhost, 
but my client is reporting cheyenne errors (I haven't tested it yet)... 
just want to know if its possible first.

Declaring a vhost using an IP address: yes and it is documented in 
the wiki.

onetom: thanks for reporting the cause, I will test that locally 
and see if I can improve the error message for such cases.

doc: it's not a big problem. red is a higher priority :)

Sure, but I can multiplex with small Cheyenne fixes as long as it 
doesn't take me too much time.

thx

hmm... cheyenne binary and the source works differently w the same 
configfile.
$ cheyenne --version
0.9.20.129
WORKS
latest source doesn't work with the following config:

modules [ internal extapp static action rsp alias ]
globals [ listen [8080]    bind RSP to [ .r ] ]
guan-huat [ debug root-dir %./ alias "/docs" %jsondb/to-json.r ]

im testing w $ curl http://guan-huat:8080/docs/test/1

bind-extern makes no difference

oh, the problem is im getting a 404 if i run the source version of 
cheyenne

Are you using sources v0.9.20.129 too?

Hmm, shouldn't make much differences between revision 129 and latest 
135...

You should search in the Cheyenne console logs for "[HTTPd] Translated 
file:" to see what file Cheyenne is trying to read. That should give 
you a clue about what is causing the difference.

no, v0.9.20.129 is binary

Translated file: %./jsondb/to-json.r
in case of the source version; so there is no differnece there.

http://piratepad.net/KkvkZ9AtME
i put the correct and the incorrect logs here

i pasted the command lines too

it works if i copy over my stuff into cheyenne's dir and start cheyenne.r 
from there

I guess Cheyenne should be able to figure out where are his own files 
if launched from another folder. I need to setup a test configuration 
on my linux box to investigate such case.

But tomorrow, too late now here. ;-)

Got you email, thanks.