AltME groups: search

I am pretty sure I wont tackle handlers for a while...  because of 
the code sharing complexity added.

query-string: Ah, the problem comes from a wrong rewrite rule for 
GET requests. I need to figure out how to handle this case.


That's what I like about web-stuff: There are so many possibilities 
and places that something can fail...

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

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

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.

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.

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

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.

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.

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

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

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

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.

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

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

even after you access a web page??

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

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?

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.

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.

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...

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

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

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

I have no reference to it...
just localhost
and a bunch added by spybot

i don't know about spybot, but faking hosts entries is a good way 
to prevent trojans from calling home  ;-)

and if they are set to local host, then you can even trap them using 
a service expecting known ports.

I'll have a static ip by next week so I hope that solves this issue 
for me..

I have a problem, that after some running time Cheyenne seems to 
get into an unstable state and my REST shopping-cart isn't working 
any longer. I got this error in the trace.log, which seems to be 
Cheyenne internal:


5/6-10:09:48.142823-## Error in [task-handler-40014] : Make object! 
[                                                                
                 
    code: 501                                  
                                                                 
                                      
    type: 'access         
                                                                 
                                                           
    id: 
'not-open                                                        
                                                                 
            
    arg1: "Port"                                    
                                                                 
                                 
    arg2: none                 
                                                                 
                                                      
    arg3: 
none                                                             
                                                                 
          
    near: [parse/all current: fourth entry [          
                                                                 
                               
            any [                
                                                                 
                                                    
            
    end break                                                    
                                                                 
        
                | "#[" copy value to #"]" skip (        
                                                                 
                             
                    append out reform 
[                                                                
                                               
                 
       " prin any [pick cat"                                     
                                                                 
   
                        locale/id? value                     
                                                                 
                        
                        mold value #"]" 
                                                                 
                                             
                   
 ]                                                               
                                                                 
 
                )                                              
                                                                 
                      
                | "<%" [#"=" (append out " 
prin ") | none]                                                  
                                          
                copy value 
[to "%>" | none] 2 skip (                                        
                                                          
      
              if value [repend out [value #" "]]                 
                                                                 
              
                )                                 
                                                                 
                                   
                | s: copy value 
[any [e: "<%" :e break | e: "#[" :e break | skip]] e: (          
                                                     
           
         append out reform [" txt" index? s offset? s e #" "]    
                                                                 
         
                )                                      
                                                                 
                              
            ]                     
                                                                 
                                                   
        ]]   
                                                                 
                                                                 
       
    where: 'confirm                                      
                                                                 
                            
] !                                 
                                                                 
                                                 
5/6-23:01:46.501455-## 
Error in [task-handler-40014] : Make object! [                   
                                                              
  
  code: 501                                                      
                                                                 
                  
    type: 'access                             
                                                                 
                                       
    id: 'not-open        
                                                                 
                                                            
    
arg1: "Port"                                                     
                                                                 
                
    arg2: none                                  
                                                                 
                                     
    arg3: none             
                                                                 
                                                          
    near: 
[unless no-lang [                                                
                                                                 
          
            id: locale/lang                           
                                                                 
                               
            locale/set-default-lang 
                                                                 
                                                 
        ]      
                                                                 
                                                                 
     
        out: make                                          
                                                                 
                          
    ]                                 
                                                                 
                                               
    where: 'confirm 
                                                                 
                                                                 

] !

Any idea what's going on? I could install a CRON job to killall instances 
and restart Cheyenne every 24h but IMO that shouldn't be the case.

Is it a rsp problem?

Mostly nothing. Cheyenne is working as a reverse proxy and just servers 
an RSP file.

So, the load is really low couple requests a day.

Well, if it's only a couple of requests a day ... it's probably that 
IE bug which doc has now fixed.

I think it was a POST.

Ok, so I will try the newest release. Is there a Linux binary already 
available? Or do you all use the source-code version?

I'm working on it currently, I need a linux binary too for testing, 
I'll publish the link here so you can test it too.

Ok, great. Any time frame ;-)? Or can I use the source-code version 
so long? If, is there a link to dowload it?

It's just a intermediate binary, it's not the full 0.9.20 version 
I'm planning to release, there's still a lot of small fixes and enhancements 
to add.

I'll give it a try. Thanks.

amacleod: did you get vhosts working? I am getting similar reaction. 
 works fine without vhosts... then its lost if the domain matches 
a vhost definition.

doc: might I do a RFE (request for enhancement)?


add a ./conf/  dir to cheyenne and load every file that ends with 
.cfg


this would allow us to distribute a configuration file with a module 
and provide setups per mod... its much more flexible to manage.

we could also have a setup for each vhost in our system, if that 
makes sense for the web admin.

even better, add a conf-dir  item which is only available within 
 %httpd.cfg telling cheyenne where to load additional configurations.

conf-dir %conf/
conf-dir [%sites/ mods/]

cool.  and I'm reiterating the need to provide a sample file ala 
apache with a paragraph of comments or two which explain all configs... 
just in case you forgot to note it... this for me is big hassle.


for example... the subtleties behind 'BIND  and 'BIND-EXTERN  are 
not obvious to deduce just by the name... 
-what is the difference in how they are cached? 

-is an external handler explicitely needed with 'BIND-EXTERN   (no, 
in fact,  but it enables it)
-how does one use an external handler?

BIND associates one or more file extensions to a Cheyenne internal 
mod.

BIND-EXTERN associates on or more file extensions to a background 
handler (worker process through task-master service).

The handler name declare in BIND or BIND-EXTERN have to match a mod 
ID or a background handler name.
Examples:

 bind SSI to .shtml => processed by mod-ssi.r (SSI is used as a matching 
 key in the mod)

 bind-extern CGI to .cgi => processed by mod-action.r (bind-extern's 
 dispatcher), then by CGI.r external handler in a worker process.

yes... I already new... but I had to trace the code and lost some 
time wondering why my page wasn't being re-rendered when I first 
used 'BIND  ;-)

I also had to trace the logic to make sure that cheyenne wasn't actually 
expecting an external handler if I used 'BIND-EXTERN...


I ended up loosing more than an hour to figure it out myself... now 
that is just one config... there are MANY... a lot of them I don't 
even know exist.


the above is exactly the kind of information which should be included 
within the httpd.cfg file, even if an example is commented out, but 
provided as an example use.  just like apache does it.

I've scrapped the previous remark system in favor building remark 
v3 right away.  this will actually help me build the mod much faster 
and will provide 100% dataflow engine from its first release.  every 
single programmable entity within mod-remark is now based on a plug. 
 the architecture I have now is becoming very orthogonal... instead 
of building up different objects for each level of config, I think 
I'll be able to reduce it to ONE.


these models will serve as references for the !compilator to create 
persistent  !documents... note that !documents are multi-leveled... 
you build documents by linking up document together.... so if only 
part of a !document is dynamic, only that part will cause processing... 
and by dynamic, I don't mean that its cgi... I mean it has actually 
changed.  down to a single HTML element.   that's what I am aiming 
in any case.


!documents can be stored at any level... from server down to specific 
page and single session. caching is embeded in liquid so it should 
be pretty fast, and inter document data sharing should allow us to 
make it very RAM efficient too.

I hate Apache config file. Because I hate having to read tons of 
docs to just "switch on" some app. Cheyenne's config file has never 
been designed to copy the Apache way, nor to be used by average end 
user. It's just a placeholder waiting to be replaced by a builtin 
web GUI allowing a simple, fast and straightforward way to manage 
the server. That has been the plan since the beginning and one of 
the main motivation for building Cheyenne. Unfortunately, I never 
had the required time to complete that goal yet, so I'm stuck with 
that, and that's also why Cheyenne is still at 0.9.x.

Documentation can be replaced by a well designed GUI.

and GUIs are a hell of a lot more complicated to maintain than text. 
 change one little thing in the file format and you've got to redesign 
alot of code... this doesn't happen with a file, since its being 
used directly.

Well, I always thought that GUI was an improvement other text files. 
Cheyenne is suppose to work out of the box with a default config 
file. The admin web UI would be reacheable with http://server-ip/admin/
(just an example).

I have a generic configuration managing library... the documentation 
is directly embeded in the configuration engine... if you save out 
the config or print it on screen, you have all the docs right there 
with it.  if you build a gui which uses the configuration data, you 
can also pull out the text from it. 


maybe that is what should be done.... allow string types within the 
config dialect (and store it appropriately).  then you/we could easily 
build tools using that info directly.

Embedding docs that can be extracted for a GUI is a good idea.

I also have big concerns about security, such a remote admin app 
would be obviously strongly secured.

this being said, I understand the appeal for GUI-based configs, but 
most power users are much more effective with raw data than having 
to fiddle with a screen hiding the data.

screen hiding the data

 you're already supposing that the admin GUI will be badly designed...I'm 
 not talking about doing a Webmin clone (this is the typical example 
 of *bad* UI design, IMHO).

as long as the config GUI is only a tool over the files, and it doesn't 
overwrite the files automatically, I won't complain  :-)

In fact, I even thought about making a lynx-compliant admin UI for 
text-only users. ;-)

as a point of fact, it is very possible that some modules (like remark) 
will require stuff to be setup which is hard to simulate through 
a gui.  managing a system of nested parameters and list is very complex 
to handle programatically.

I'm adding words which are commands within remarks' module using 
the do variant of config definition...  this allows me to grow a 
config by calling the same command multiple times.... this would 
be very unweildy to implement any other way (but not impossible)...


maybe a function-based api could allow us to "hook" into the GUI 
but its pretty hard to cover all possibilities in any case... anhow... 
back to modulating remark.

There's a builtin "process" function in config DO blocks allowing 
to process nested blocks (see mod-static/if-loaded? definition).

ahh so that launches a new parse config on the block we give it?

when the config do is performed, I noticed you do a bind on the block... 
the thing I wonder is to what it is bound... its not obvious to me

It should have worked even without the port number. It's a bug that 
will be fixed in next release.

Any reason why cheyenne does not allow a .r file to be read via http? 
It seemed to work with apache. I had to change it to a .txt file 
to get it to work..after batting my head for many minutes.

in the http.cfg file its assigned as a cgi script:

bind-extern CGI to [.cgi .r]

and the CGI handler will execute it.

It would be nice to have Cheyenne support UTF8, I have it working 
here with some functions provided by Oldes, utf8/length? utf8/trim 
but a proper html entity converter is still missing, I think Gabriele 
has it but that's on hold by Reichart.. 8)

Cheyenne has been considered within Qtask, and tested in a test project, 
with success. The lack of server-side SSL is a deal-breaker for the 
main site but it is usable for supplementary services. RSP went over 
well too, so Maarten is updating the original RSP for use in Qtask 
(though not with Cheyenne).

Looks interesting, I hope you'll be able to publish here your conclusions. 
In theory, Apache+FastCGI should be faster than Cheyenne, but the 
application framework used in the FastCGI server, if not deeply optimized, 
might be a bottleneck.

Well, there's just a local dependency on config file to remove first 
(in my todo list) to allow remote worker process (for RSP, CGI,...). 
But you need a also a remote process manager to handle the launching 
of worker processes. Anyway, I think that using a front load balancer 
(supporting session affinity) with several servers is a simple and 
efficient solution.

What are the requirements to get a connection to a mysql database?

I have a %httpd.cfg as below   


--------------------------httpd.cfg --------------------------------

globals [  ...  worker-libs [  ...  %path/to/mysql-driver/mysql-protocol.r 
  ...  ]  ...  ]

my.virtual.host [   ....    databases [ db-name   mysql://root:[lpass-:-127-:-0-:-0-:-1]/table]	 
....   ]

----------------------------------------------------------------------


As far as I can see from the documentation and sample files, I should 
now be able to use SEND-SQL a alike on DB-NAME, but that gives nothing 
but script errors

	** Script Error : db-name has no value 
	** Where: rsp-script 
	** Near:  [print mold db-name  


I've already spent hours on this without getting a clue on what to 
do.

I've also found out that DO-SQL expects a database WORD! instead 
of a PORT! like SEND-SQL.

How did you generated the last error message? It looks like a RSP 
internal error (should have been caught at script level).

I think I was using DO-SQL with a LIT-WORD! database name and a simple 
STRING! select statement, which - hard to tell - may have had a type 
back then. Hard to tell afterwards; I'm not able to reproduce that 
particular error message now. And I've deleted the trace log once 
things started to fall into place. Putting the select statement in 
a block seemed to be what solved my problem, but I tried so many 
things that I don't recall the actual order in which I changed my 
.rsp-code.

Is there a Cheyenne release with all the new features available?

Doc, RSP by itself.. I use a version which does set word capturing 
(do you do that?) and allows page inclusion and context injection 
with "captured" words on the subpage. Do you do that?


Otherwise, a lot of Qtask "the application"  is Javascript on the 
UI calling API services - RSP is of little use there. The main web 
site... I would actually oppose REBOL. Why spend time there on e.g. 
a shopping cart when you can take one of the shelf and spend that 
time improving the real product (the service/application)?

Word capturing => yes, all RSP running inside a webapp are captured 
in the webapp execution context, to avoid global context pollution. 
This doesn't apply to standalone RSP scripts (outside a webapp), 
but that feature could be easily added.


Page inclusion => yes, you can include RSP scripts in RSP. See http://cheyenne-server.org/docs/rsp-api.html#def-21

context injection with 

captured" words on the subpage" => I don't understand precisely what 
you describe here. In Cheyenne/RSP, subpages are captured in the 
webapp unique context, like parent pages, so there's no special treatment 
for subpages. Do you imply exporting just a selected list of words 
from the subpage script to the parent context?

Graham: no, not yet. If you have an urgent need for the new version, 
I can make a snapshot of my development version.

I can only rename in current directory .. also doesn't seem to work 
in a subdirectory of current dir

I've set up a public SVN repository for the development version of 
Cheyenne, so if anyone needs the latest patches or improvements, 
it doesn't have to wait for the next release. Access info at : http://code.google.com/p/cheyenne-server/source/checkout

So, RSP is good enough, except we are more API oriented with a Javascript 
front end :-)

ie. can I have webapps inside a vhost?

vhosts are just containers, so you can have one or more webapps in 
a vhost.

doesn't look like you can get a verbose trace by default with the 
encapped version

now got a crash log

would you do a cmd encap?

Seems that there's a regression in the LISTEN config option processing, 
fixing that...

Does a binary encapped with enface or enpro work on Win2003?

'set-tray-remote-events is called only in 'do-tray-app which is called 
when Cheyenne is running as a service to install a standalone version 
of the tray icon with menus (for remote control of the Cheyenne service).