World: r3wp

Looks like a user permisson issue?

#!c:\dev\sdk\tools\rebol.exe  --cgi
and this is the cgi issue

and no exec flags either

-rw-r--r--  1 onetom  staff  1128 Apr 18 00:41 www/show.cgi

svn can only assign exec flags in a post-hook, right?

I am not enough familiar with svn on UNIX to answer that question.

and i use darcs and occasionally git, but i hate git :)

ok, it works after

onetom ~/rebol/cheyenne-server-read-only/Cheyenne $ chmod +x www/show.cgi 

onetom ~/rebol/cheyenne-server-read-only/Cheyenne $ head -n1 www/show.cgi 
#!/usr/local/bin/rebol -c

is this hash bang thing under windows also a cheyenne feature?

yes

Ok, let's have a look at your log files proposition...

Doc, thanks... had only the service/process-queue... added the process-next-job() 
function and calls... 

seems like I'm getting an error elsewhere now (later in the reply 
chain), so that's a good sign.  thanks.

it would be nice to have a little options in the cfg file... something 
like

-trace-log %/path/to/folder/

Max: wait...process-next-job is RSP specific (RSP requests queue 
management)

What is the issue with having %trace.log in the same folder?

well, it took me a month to realize where it was.... in my REBOL.exe 
folder.   :-)


the problem with using "current-dir" is that it can be anywhere, 
especially on windows where the concept of a current-dir is pretty 
clueless.

just for example, depending on how you start a rebol application 
(shell, drop icon, link), there can be 3 different current dirs...

You can change that easily if you're running it from a shortcut icon. 
Edit shortcut properties and set the "working folder" where you like 
it to be.

yeah, but I want that kind of thing to live within the configs... 
 since... its a configuration  ;-)

anyhow.. I can hack it in quite easily... its not that big a deal.. 
just a suggestion  :-)

wrt handler... yes.. I just looked in more detai and the error is 
related to the process-next-job().

I won't make a per log file configuration option, that wouldn't make 
much sense. When I'll had such option, it will redirect all log files 
to the same folder. Still need to finish reading onetom proposition 
to see if there's a better solution.

it should also go to a %log/ folder

meanwhile i wrote a little script to fixup the cgi hash-bang lines 
and give exec flag on them

Doc,    wrt handler.. it really was a stupid error on my part... 
I didn't set the   req/out/code   so I guess it stays in limbo in 
its worker handling, since its not valid for request handling, but 
it has no return error code for reply handling either...

CGI scripts run from Cheyenne don't require the executable flag to 
be set.

Cheyenne extracts the shebang line and CALL it, passing the script 
name as argument.

even on unix?

Yes, all CGI scripts are running on my Linux box, with 644 permissions.

Max: req/out/code is used by HTTPd.r service to know if the request 
is ready or not to be sent back ;-)

yeah, I figured it out by re-reading the rsp and action mods.

So, not only it stays in limbo, but it also blocks other requests 
that might be in the pipe coming through the same HTTP connection.

ah ok.

onetom: even the Perl CGI scripts from %Cheyenne/perl/ are running 
OK without +x flag on my Linux.

(I just need to adapt the shebang line for Linux thought, the one 
in the archive is for Windows)

If I have a single wish, it would be for all of the mods and handler 
scripts to have a verbose rebol header.  it would help a lot understanding 
the hierarchy and purpose of some of the mods.

I agree about the headers: REBOL [ ] is a bit short. :-)

well, the path still should be correct, right?

there are so many layers and un-obvious dependencies ( and little 
details like the error code return on top of it ) in the structure 
of the server that it gets really

onetom: yes the path in the shebang line usually needs to be adapted 
for each local configuration.

Maxim: please throw together a blog entry at least about your rambles, 
so later we can use it to extend the documentation

Mods hierarchy: there's no such relation between modules, it is more 
an event matrix as described here: http://cheyenne-server.org/blog.rsp?view=25
(slide 5)

Priorities are fixed per-mod and/or per-callback.

Running Cheyenne with -vvvvv (should be enough) will give you a view 
of the matrix (line by line, per event) when Cheyenne starts.

Dockimbel: I have to thank you for your presentation. Just saw it 
yesterday finally. Now I understand Cheyenne a bit more. Im curious 
about the tricky parts though. Like how do u handle forking and the 
communication between the master and the forks and stuff like that. 
I know it's handled by UniServe

Just hinting what should you write and talk about the next time; 
not asking for explanation now, of course :)

Forking is done when Cheyenne starts, more precisely when the task-master 
service is loaded by UniServe. It starts with a default of 4 workers 
processes. If more than 4 simultaneous RSP or CGI requests are received, 
one or several workers are forked (up to 8). You can change those 
values in %cheyenne.r (search for pool-start and pool-max). It is 
planned to expose those values in the config file for easier access.

Oh, well, you got a quick explanation right now. :-)

Doc yeah... I'm starting to be pretty knowledged on the phases (though 
some things still elude me a bit).


I'm just saying that some mods... like extapp, expire, action, alias, 
internal, etc...  probably have non-negligible effects in the chain 
that some other modules might react to or not (depending).  and its 
currently quite tricky to understand what effects the mods actually 
have on requests and response.


anyhow, as usual, Its not critique its just observation from someone 
"outside the box"   :-)