World: r3wp

How many instances of Cheyenne are you running?

The log will go to the first instance of Cheyenne started.

the trace.log appears in the chyenne directory if there is an error.

It doesn't appear in the logs/ directory

You can set verbosity in the config file - check the comments in 
the file for how.

no comments of verbosity in my config file.... no trace.log in my 
main cheyenne dir  ' : -/

I've tried to write that line SEVEN times before altme finally didn't 
eat it up or drop connection.

>: - (

It's really bad at present...

Never seen it like this before .....

I only get a trace.log when I get a RSP error.

What is your situation Max?

my cheyenne was crashing (no replies client close connection)  with 
no log, no verbosity.

but I finaly conceded victory to cheyenne and managed to setup args 
for my startup...

and exactly why can't you run it in verbose mode?

but I find it strange that cheyenne doesn't have a trace log for 
all of its accesses/errors.

there is an access.log

I have no .log file of any kind being created in any of the cheyenne 
dirs.

(or uniserve for hat matter)

including the log directory?

this is the latest release. from the web site.

yep... nothing in log

even after you access a web page??

I think that is the thing... it logs only after a succes...

but it should log errors too.  ;-(

I was studying the req object and it has a log? parameter in the 
out  subobject.

so this is a heavily modified cheyenne or straight from doc's site?

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.