World: r3wp

Peter: When Cheyenne is in Service mode, the tray icon app is a second, 
separated instance of Cheyenne. If Win7 is not starting the second 
instance, you need to start it manually to get the tray icon.

Thanks.

Streaming: Cheyenne is sending big files in chunks of 1KB up to ~64KB, 
depending on the connection. It can serve multiple big files, but 
the scalability might be limited by the blocking disk read accesses 
delays. Other C-based servers can use OS API for async disk read 
accesses that we can't integrate into REBOL native ports.

onetom: "i don't really understand what is all this resistance" Well, 
you will probably be the only one to use that feature. Others would 
just install nginx and have maximum performances for static files, 
compression and SSL support.


I will add the compression feature in main process today, but will 
strongly discourage everyone from using it in the documentation (to 
avoid deceiving users in the general use case).

fair enough.

I have tested successfully config file relocation/renaming and Cheyenne 
working directory relocations both on Windows and Linux. Let me know 
if something is not working as expected.

I have tested using the encapped version only, it might work fine 
from the sources too, but it is not guaranteed.

I'm getting a *very* weird problem launching cheyenne from win7.


using a clean download of the latest build sources, if I try to start 
up the cheyenne.r by double-clicking on it in windows, it fails. 
 

no tray icon appears, the rebol process is running buts its dead 
(no pages are served, and no workers are launched).


if I try to run it a second time, I get the console which tells me 
it can't open the rconsole and logger ports (so cheyenne actually 
did start)., but the "no response" flag appears on the window title 
and its as dead as the first instance (I even get the busy mouse 
cursor treatment). 


but if I start it from the command-line, using the exact same command-line 
that I see in the task manager, I have no problem!


to make this even more strange, dragging the cheyenne.r script icon 
on the rebol.exe icon, launches cheyenne without any issues!

launching it from my editor's automated script launching setups also 
works without issues.

all of these show the exact same command-line in the task-manager 
(which includes the -qs rebol flags).

note, I am *not* running cheyenne as a service.

Questions:
1) can any one else replicate this (am I going mad ?  ;-)
2) why does this happen?
2) can this be solved?

I never tried that, as all my .r files are associated with my code 
editor.

Changed association to point to rebpro.exe 2.7.8, clicking on %cheyenne.r 
launches and it responds flawlessly.

I must add that my user account has admin privileges, so your issue 
might be related to user rights restriction.

Maxim, I wonder if there is anything in the system log?

i happen to have a win7 laptop around. i will git it a try, if u 
can be more specific about the versions of ur environment
run http://cheyenne-server.org/tmp/cheyenne-sources-r146.zip
with http://www.rebol.com/downloads/v278/rebol-view-278-3-1.exe?

i happen to have a win7 laptop around. i will git it a try, if u 
can be more specific about the versions of ur environment
run http://cheyenne-server.org/tmp/cheyenne-sources-r146.zip
with http://www.rebol.com/downloads/v278/rebol-view-278-3-1.exe?

rebol-view-278-3-1.exe doing an svn checkout  (r146) which should 
be the same as the .zip

win7 (not yet upgraded to sp1)  with UAC turned on.

dir opus has a mode where you can elevate the explorer to have administrative 
rights enabled (which is independent of being an admin user) and 
this doesn't change anything.

In the database connections, can Cheyenne connect to an odbc dnsless 
connection?

dsn-less

Cheyenne just calls "open" on the URL you pass in the databases block, 
so if you can connect from console, Cheyenne can too.

It has to be a url?  In a dsn-less connection you provide a spec 
block

You are lucky, Cheyenne does not check the syntax of the 'databases 
config block, so a block! should work (as long as it is accepted 
by OPEN).

:)

Config question on stack overflow:
   http://stackoverflow.com/questions/6367201

Maarten, this is the Cheyenne group.

Yep, didn't see it first.

Question stands: can I encap an embbed Cheyenne, and if so, how?

Should be possible by following the embed documentation, but I've 
never done it

In httpd.cfg, activate embed module :
modules [
embed
]

From http://cheyenne-server.org/wiki/Config/Struct:

Note that the embed module, if activated, will disable all the other 
ones (required for proper working of embedded mode).

So far, that's I don't know either :(

Hi Maarten, been quite busy these last days, nice to see you back 
in REBOL world.

About your question: Cheyenne has its own built-in preprocessor for 
encapping. So you should be able to encap Cheyenne using just an 
#include %cheyenne.r

But you need to run Cheyenne from sources at least once to force 
the generation of the %.cache.efs file (result of the preprocessing).

About %httpd.cfg file, it will be written down on disk if not present, 
so if you want to avoid that, you need to patch the sources. For 
that, just edit %Cheyenne/misc/conf-parser.r and comment line 69:

        ; write file data

I never tried encapping Cheyenne in embedded mode, so you might encounter 
other issues though.

Ah, another important thing for encapping: you need to edit %Cheyenne/encap-paths.r 
and configure the paths to your local SDK folder.

OK, I may take a look. What I eed is a really simple web server, 
so if it takes too much time I'l just do a 10-liner. That's good 
enough in this case.

If you need a really simple one, they are several on rebol.org that 
could work for you, like Carl's micro web server script.

back to my problem from april 19th: is anyone using webapps under 
a virtual host?

I have tried to use the testapp on Dockimbels request, but it serves 
only non-functioning rsp pages on http://hmkdesign.dk.

Henrik, if you haven't solved yet your configuration issue, you should 
send me your working directory archived along with your configuration 
file, so I can see where is the issue.

Unfortunately that woud take a while to pick apart as I have other 
pages running on that server.

The testapp script makes this error:

22/6-21:54:04.832205-[RSP] ##RSP Script Error:

        URL  = /show.rsp
        File = /home/henrikmk/sites/testapp/show.rsp


        ** Script Error : empty? expected series argument of type: series 
        port bitset
        ** Where: rsp-script
        ** Near:  [either empty? session/content [
print "<LI>No session variables</LI>"
] [
foreach [name value] session/content [
print [<LI> <B> name ":" </B> mold value </LI>]
]
]]

Are you overwriting 'session word somehow?

Strange error, having a quick look in RSP.r code.

A session has not been started, which is not possible if it's in 
a webapp.

Is this not the same as if app-init.r was never run?

it's the same as for my webapp. app-init.r never runs, when it's 
inside a virtual host.

The session is controlled from the main process, the %app-init cannot 
interfere on session/content loading.