World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
| older newer | first last |
| Dockimbel 18-Apr-2011 [9867] | Agreed. |
| Maxim 18-Apr-2011 [9868] | (no need to go down the RoR path ;-) |
| onetom 18-Apr-2011 [9869] | Dockimbel: the alias "/" %x.r works too. beautiful. |
| Dockimbel 18-Apr-2011 [9870] | Good! :-) |
| 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? |
| older newer | first last |