World: r3wp

download and double click.... but  I'm working on mod-remark, so 
its not currently serving web pages...

still at first, i did see the standard cheyenne pages and don't have 
any logs.

yes! mod-remark has served its very first ever web page  :-)

Re: JS warning in Firebug : that's intentional, it's not a bug, but 
it is bad practice. I'm putting that in my todo list.

RETURN usage: your benchmark doesn't reflect real usage. RETURN cost 
is only significant if you didn't spent much time since you've entered 
in the function. In other terms, if RETURN is at the very beginning 
of the function, it might have a significant (means measurable, doesn't 
imply high) impact on performances, if much code has been processed 
before reaching it, I guess that you won't be able to measure any 
difference in performances.


In Cheyenne's mods, I often use a testing expression at the beginning 
and jumping out if it doesn't match. Let's try to calculate how much 
gain I would get by removing this early RETURN :
    - 500 incoming req/s (extreme load conditions)
    - 10 mods
    - 12 callback / mod (each one having a early RETURN)

    - execution time for testing expression before each RETURN : 0 (will 
    give us the maximum possible final gain)

RETURN evaluation time :  (according to your benchmark)
>> (1.032 - 0.296) / 1E6
== 7.36E-7

# of RETURN evaluated under the testing conditions during 1 sec :
>> 500 * 10 * 12
== 60000

Time spent in 60000 RETURN :
>> 7.36E-7 * 60000
== 4.416E-2			; = 44 ms, roughly 1 / 20 sec


So, under extreme conditions, having a testing condition before RETURN 
taking no time, we can have a maximum gain of 5%.

This translates in real usage in a gain of 0 to 5% depending on server's 
load and test branching conditions performances.


Looking at the testing conditions in current mods, I guess we could 
squizze between 0 and 2% (under extreme load only). I'll try to hunt 
down those early RETURN cases in future versions.


Btw, there's a drawback in not using RETURN, you end up with nesting 
IF/EITHER expressions, which gives you less readable code IMO.

Max: trace.log is only used in verbose mode or in RSP debug mode. 
Access logs are available in %log/ folder (either in Cheyenne's home 
folder or in folder defined with LOG-DIR config keyword).

Also, setting conditions and using IF or EITHER expressions has overhead 
too.

Are the paremters in request/content somehow checked after receving 
from the client if they contain malisous Rebol code or anything else? 
Or is everything just plain converted to string! and that's it?

verbose is at vvvvv (working) and pages are being served... yet I 
have no *.log files.

thanks for the log-dir config... should put ALLthe configs in the 
httpd.conf file and gray them, like apache does it... with comments 
on what each config does...

Max: good suggestion!

Robert: it's string! by default, but you can force conversion to 
other types using this RSP function: http://cheyenne-server.org/docs/rsp-api.html#def-23

Max: what Cheyenne 0.9.19 flavor are you using? Source or binary? 
Does your main process have correct rights for writing files in the 
folder Cheyenne is running from?

cheyenne source... permissions... humm its on winxp.. didn't of checking...

permissions seem ok.

Argh, lost my post due to AltMe's hiccups...

(short answer) Try using the -w option for REBOL like this :

C:\Dev\SDK\tools\rebview.exe -ws cheyenne.r -vvvvv

why the no-window flag... are you saying we can have log only if 
we startup cheyenne without console?

Currently yes. I didn't found any value of having logs both on screen 
and on disk at the same time. But if you can convince me that it 
has a value, I may support it in future.

We're talking about debug logs here, not HTTP logs.

doc... is the fact that I lost 6 hours trying to get information 
about cheyenne's errors on screen OR in log files any good reason?

if you had log option and console option within the default config 
file, (commented out or not) then users choose what they want.

my client uses the console for real-time status checking... using 
remote desktop and just noticing if the client isn't serving stuff 
anymore... but the logs then allow you unravel what led to that problem.

ooops   that would be   :     ... noticing if *cheyenne* isn't serving 
...

response/redirect: This doesn't seem to work for me. Nothing happens... 
Is there a way how I can check what's going on?

Max: I agree the main issue is not having config options documented. 
About the current logging rules, I've always found that's way handier 
to pass command-line options than having to edit a config file. I'll 
see in the next version how I can improve that. 


Btw, I recommend running Cheyenne as encapped binary on production 
servers, it's simplier to handle (especially on Unix) and more secure 
(you can't corrupt some vital source file).

Response/redirect: run Cheyenne in verbose mode using -vvv command 
line switch, to see what's wrong. You've probably passed a bad URL 
(see RSP API doc for examples).

Would a web hop interfere with virtual hosting?


I using a webhop to bring a domain through port 81 due to restrictions 
on 80.

It works on apache but I could not get it up on cheyenne...

Actually I can't get it working directly either...

If I got a virtual host:
mysite.com [
	root-dir %/www/mysite/		; documents root directory
	default [%index.html %index.rsp %index.php]			; default files
]

does it matter if i'm trying to reach it through port 83 with mysite:83

I keep getting the default page

I know in apache "virtualhost" commnad needs to be uncommented...I 
do not see anything else in the config file that idicates vhosting..

did you set the port cheyenne listens to?

in the httpd.cfg...

listen [83]


I'm using cheyenne on port 81 since I also have apache on my system 
and it works.

the url will be http://mysite.com:81/index.html 

not using vhost though.

vhost is for running more than one Cheyenne site on the same IP address 
?

I presume that all vhosts run on the same port ..

yes vhosts redirect different sites to different roots, by matching 
the domain name.

Yes its listening to port 83 and I get the default web page (Cheyenne 
test page for now)

If I URL to the "mysite" dir (www.defaultsite.com/mysite) I  get 
vhost index page...

Would use of subdomains be a the problem>>>  mysite.dyndns.com

No, but are you sure you have entered the dyndns.com domain in the 
vhost definition?

mysite.selfip.com [
	root-dir %/www/mysite/		; documents root directory
	default [%index.html %index.rsp %index.php]			; default files
]

Just as it is above...
it works for apache on port 82

selfip.com is not dyndns.com

I used dyndns as an example...sorry for the confusion...selfip.com 
is one of the domains dyndns offers..

I have no problems with subdomains, but maybe it has to do with the 
dynamic DNS

Still cannont get vhosts working:

mysite.selfip.com [
	root-dir %www/mysite	; documents root directory
	default [%index.html %index.rsp %index.php]			; default files
]

if I change my default root-dir to that above I get the corresponding 
index page for that directory...it just does not seem to reconize 
the vhost url

Does dyndns support subdomains?

The DNS needs to be configured to resolve subdomains to your IP number

It works with apache..does Cheyenne use a different method?

linux or windows?

windows