World: r3wp

Graham: Is this a cheyenne issue?
Robert: Yes, I just checked the LOG files. [...]

So, no, it's not an issue with Cheyenne.

I didn't think so

No, it's not. The LOG files are correct but I didn't saw the double 
" ?" ... Sorry, as said: To many places where something can go wrong.


Perhaps, it€s possible to throw an error if a male-formed query string 
is found.

I'd rather throw parties on *female* formed queries   ;-D

It's hard to define "mal-formed" precisely. If you strictly apply 
the RFC rules for URL, you'll find out that a lot of web sites are 
using "mal-formed" URL.

its actually a global property of php that you can change the url 
parameter separators for your site in order to fight back against 
bots and make hacking a bit more complicated.

Wouldn't that break most of JS/AJAX frameworks?

not if you edit the code so the urls match your site's separators. 
 I have come across some sites with strange separators.

but as written in the php docs... obfuscation isn't a replacement 
for real security.

so most people put their time on tackling the real problems like 
sql injection and https use properly

and use https properly.

doc, I have noticed a usage in your mods which you might want to 
change for speed reasons.


you use the word return a lot... and in my tests, it causes a BIG 
performance hit on function calling... I really mean noticeable when 
you do loop profiling ... a minimum of 20% slow down IIRC.

so instead of:

    phase: func [svc req conf][
        if declined? [return none]
        ...
        if let-others [return false]
        ...
        true
    ]

you really should be doing 

phase: func [svc req conf][
        if accept? req [
              ...
             true =  let-others? req
       ]
] 

just my two cents.

oops... reversed the emaning of that last return value...  this is 
better

phase: func [svc req conf][
        if accept? req [
              ...
             end-phase? req
       ]
]

so just drop off the end?

Doc.. just a tiny bug report.. when I am working with latest version 
in debug mode firebug reports me javascript warning: I haven't been 
digging into if this is supposed to be a bug or intentional...
>> test for equality (==) mistyped as assignment (=)?

>> [Break on this error] if (node = document.getElementById('menu' 
+ id)) {\n

yes graham, all functions return a value, a rare few return unset!.

'IF, for example,  returns none when the condition isn't true.

well, I wasn't aware of a hit using 'return.

returns enables the catch/throw as does break IIRC, so there is overhead 
in the function's calling.

so 20% of what?

let me do an example

>> s: now/precise a: func [][return none] loop 1000000 [a]  difference 
now s
== 0:00:01.032

>> s: now/precise a: func [][none] loop 1000000 [a]  difference now 
s
== -0:00:00.296

in this case the difference is 70%

now if I have a 1000 line function that either teminates in a return 
or just the value .. how much does it affect it?

the larger the func, the less hit, you can see that each function 
call is taking more time to initialise because of the return.

its just a question of maximising performance, and I know dockimbel 
is very serious about improving cheyenne's .

so, in reality it may matter very little

he is using return everywhere, without possibly realising that it 
might be affecting the whole by 5% overall.

in all processing loops I've measure a resonably high latency, to 
actualy ban it from all of my code.

so how do you break out of a loop ?

I rarely need to do so... I implement the loop conditions properly, 
usually.


obviously there are cases where you really can't live without out 
it... but as a general rule, I rarelly ever need break.

isn't there a way to set the verbose level in the httpd.cfg file?


  I want no arguments to running cheyenne, only config... using args 
  for persistent app is the first point of failure in panic maintenance.

my god cheyenne needs docs.

don't read the above as multiple instances of Doc (although that 
might be the real answer  ;-)

help! cheyenne has no trace.log file in logs, and I can't get the 
verbosity to work without using command-line args which isn't an 
option in my current setup.

what do you mean no trace.log ?

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?