World: r3wp

I am wondering if I can use this to control various applications 
I have running.  They currently run with GUIs, but I think I should 
use a web service module to control them so that I can run them all 
GUI less.

well, you can still have a gui, but all it needs to do is build URLs 
and confirm the results  :-)

the web service would communicate internally via a tcp port ... so 
that should work.

2/5-19:59:12.259281-## Error in [conf-parser] : Error in conf file 
at: !
does this look familiar to anyone?
there is no ! in the httpd.cfg of course

Never saw such error before.

im trying to put an alias into a webapp. is it possible?

In theory, it should be possible, but never tested. I'm having a 
quick look at 'alias code atm...

I don't see anything in the 'alias implementation preventing it to 
work from within a webapp.

Doing a quick test...

Works here. Here is my webapp config:
	webapp [
		virtual-root "/testapp"
		root-dir %www/testapp/
		auth "/testapp/login.rsp" 
	
		alias "/testapp/hello" %testapp/login.rsp
	]

hmm.. it doesn't throw an error if im trying to load a non-existant 
module

how do u ignore .svn dirs while grepping an svn repo? it's annoying 
to say | grep -v \\.svn all the time

Grepping: don't know. I would do a  "svn export" of the SVN repository 
in such case.

ah, it goes into the crashlog if a module is not found.

im not sure how would it be the best but it's freaking hard to debug 
like this.

1, i won't know the names of the chey-pid-*.log files and there are 
multiple of them, so i can't easily tail -F them

2, trace and crash logs are created where the cheyenne executable 
or rebol source is located. -- that place usually not writable and 
it's somewhere else, not where the application is.

3, i won't know what is logged where unless i check all of these 
logs -- i could imagine a non-daemonizing mode where every fucking 
things is just dumped onto the stderr

i won't know the names of the chey-pid-*.log files

 As the -pid- part suggests, you just need to search for the one having 
 the same PID as the current Cheyenne main process.

i mean, i can't know it in advance. now im running cheyenne with 
-w 1 and having a look at the log with less *pid*log

btw, that error at ! is logged even if my cfg file is only
$ cat httpd.cfg
modules [ internal extapp static action rsp alias ]
globals [ listen [8080]    bind-extern RSP to [ .r ] ]

I wonder why you guys are make things harder by trying to debug your 
apps under production conditions? 


Why don't you make a local development setup using Cheyenne from 
sources, lauching it from a console in verbose mode to have a direct 
look at everything that could go wrong. The only log file I need 
to look at during Cheyenne development is %trace.log file (and even 
this one is accessible from your browser in RSP 'debug mode...).

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.

what do u mean by production condition, btw? there is nothing in 
production yet

i have a global debug option just as a per-vhost one and im starting 
cheyenne w -vvv beside -w 1

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" 
?