r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Cheyenne] Discussions about the Cheyenne Web Server

ChristianE
18-Apr-2011
[9871x4]
Should the following .rsp script work and deliver something like 
... <p>123</p> ...
<html>
  2   <head>
  3     <title>Test</title>
  4   </head>
  5   <body>
  6     <p>
  7       <%= ajoin collect [repeat i 3 [keep i]] %>
  8     </p>
  9   </body>
 10 </html>
(sorry, ignore the line numbers)
I tend to use COLLECT a lot in REBOL scripts, but it seems it can't 
be used with Cheyenne.
Dockimbel
18-Apr-2011
[9875]
Which Cheyenne version are you using?
ChristianE
18-Apr-2011
[9876x4]
All I get is
#[object! [ code: 302 type: script id: no-arg arg1: arg1 arg2: keep 
arg3: #[none] near: [err/arg1] where: reduce-error ]]
wheter I'm in DEBUG mode or not..
I'm running version 0.9.20.125
Dockimbel
18-Apr-2011
[9880]
Seems that the RSP error catching has some trouble with COLLECT.
ChristianE
18-Apr-2011
[9881x6]
Another error I'm running into fairly regular is
#[object! [ code: 502 type: access id: cannot-open arg1: %/usr/local/bin/cheyenne/ 
arg2: #[none] arg3: #[none] near: [change-dir save-path compress-output 
unless response/buffered? ] where: #[none] ]]
when doing something
like
<% ... query: "select * from database.table" ... do-sql query ... 
%>
Cheyenne doesn't like the QUERY word being overriden. But doing so 
is probably just silly on my behalf.
Dockimbel
18-Apr-2011
[9887x2]
QUERY is a REBOL native function
You should *never* redefine such word that is used in several mezzanines.
ChristianE
18-Apr-2011
[9889]
Yeah, so, as I said, just silly on my part.
Dockimbel
18-Apr-2011
[9890x9]
The issue with COLLECT is caused by DO. In RSP environment, DO is 
redefined to bind argument code to webapps execution contexts. The 
 RSP mezz DO has a fixed arity (= 1) while the native DO has a variable 
arity (= 3 inside COLLECT), hence the error.
I see no simple way to fix that on the RSP side as they is no reachable 
way to emulate the "variable arity" at mezz level.
So, I'll see if I can patch COLLECT instead.
Hard to fix COLLECT without destroying Brian's code pattern...
I will ask BrianH for that.
Ok, I've found an (obvious) patch for COLLECT. A reference to the 
DO native is kept in RSP (*do). So the following patch (run in global 
context) would solve the issue:

if pos: find second :collect 'do [pos/1: '*do]
I guess other new mezzs in 2.7.8 might be using DO internally too, 
they would need to be patch one by one by Cheyenne to be used in 
RSP context.
ChristianE: I've commited a fix to Cheyenne public repository. It 
will be available as a new source package in http://cheyenne-server.org/download.shtml
in about an hour. But I won't build new binaries now (takes too much 
time).
If you're using the binary version and don't have the SDK, you can 
put the one-line patch in a REBOL script and load it in your app's 
startup code or better, load it using the 'worker-libs config keyword.
ChristianE
18-Apr-2011
[9899]
Nenad, that's great! Thanks for all the work and effort you put into 
Cheyenne! And don't even think of taking any extra time to build 
binaries for just a little fix like this one, really, I can wait 
and happily use the patch.
Dockimbel
18-Apr-2011
[9900]
Cool :-)
Maxim
18-Apr-2011
[9901x3]
Doc, one thing I have not yet fully mapped out in my mind wrt handlers.

Q1:

how do the handlers actually compile/get their source code... is 
it sent over tcp and run there, or does the handler load a file on 
its own?

Q2:
when exactly does this happen?

Q3:

can I configure the handler source or data in some way before it 
gets compiled/executed,  (at the mod conf parsing stage).


I neet the handler to share some data with the mod which manages 
it in some way.


I don't want to send this config data via the request, at each request 
(makes no sense)
ah... don't bother, I just figured out... I've been reverse engineering 
the whole task-handler/master code for a few hours... finally found 
the magic lines I was looking for.  


its neet, you load the files on demand, loading each module, only 
if its actually required.  best of both worlds.
so I guess, the best way to configure the handlers through cheyenne's 
httpd.cfg system,  is to save out a temporary configuration file 
on the fly when the conf parser is run.  


this file would be executed by my handler when it is launched by 
any of the worker processes.
Dockimbel
19-Apr-2011
[9904x2]
Looking at COLLECT code again, DO's arity is not 3, it is 2 or 10, 
depending on how one count arguments.
Temporary conf file: right, that should be the simplest solution.
Maxim
19-Apr-2011
[9906x2]
yeah... I've changed my solution a bit.   the handler now has a variable 
to know if its been configured yet, and if it has, it skips that 
part of the code.   so even if I get the cfg at each request, I ignore 
it.


The cool thing is that my mod really doesn't need much configuration 
and most other standard configs are useless to it, so I commented 
just about all of them in my httpd.cfg and my mod still works.  :-)


very lean on the cheyenne side.  I do all the heavy lifting in the 
handler, so it can scale pretty well.
one strange thing though... in the task-master.r  lib I set workers 
like this:

		pool-start: 1	; number of helper process when Uniserve starts
		pool-max: 	2	; maximum number of helper process


and it always opens up 4 anyways.  is there anything else to do?
Dockimbel
19-Apr-2011
[9908]
These default settings are superseded by the ones from %cheyenne.r.
Maxim
19-Apr-2011
[9909]
ah.
Dockimbel
19-Apr-2011
[9910]
You need to change them in %cheyenne.r (I should add them to the 
config file some day).
Maxim
19-Apr-2011
[9911x3]
maybe I could add a little cfg option for them... my client is going 
to need this.
yep... works  thanks
btw, I'm starting to feel like a cheyenne mod/handler code ninja 
 ;-)
Dockimbel
19-Apr-2011
[9914]
You can, except you, I think only Philippe Legoff got that far :-) 
BTW, he wrote a few nice articles (french only) on Cheyenne usage: 
http://pl.legoff.free.fr/dotclear/rebol-fondation/index.php/?q=cheyenne
Henrik
19-Apr-2011
[9915]
I'm having a strange problem with one virtual-root that works and 
another that doesn't. The one that doesn't simply sends back a 404.
Dockimbel
19-Apr-2011
[9916]
Can you show me the config definition for these two webapps?
Henrik
19-Apr-2011
[9917x2]
privately
What's the best way to debug app-init.r now? I can't see whether 
a bug happens or whether it runs ON-APPLICATION-START at all.
Dockimbel
19-Apr-2011
[9919x2]
Use 'debug/probe or 'debug/print to emit debug logs in %trace.log 
file.
If an error is caught in 'on-applicaion-start, it will appear in 
%trace.log.