World: r3wp

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

Thanks.

Do vhosts work with stunnel ?  ie. I can redirect incomming https 
to different vhosts?

I've just started testing the latest cheyenne out of SVN.   No matter 
what port I run it on, it always says it is runing on port 80 when 
you hover over the system tray.

I encapped cheyenne.r and now my cheyenne server just terminates 
without any entries in the crash log :(

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

http://pwp.s3.amazonaws.com/checmd090801.exe

is the encapped binary of cheyenne using rebviewcmd encap

Try running the encapped version with -vvv as command line argument.

it just shuts down with no explanation.

1/8-10:32:43.093-[boot] Cmdline args : -vv
1/8-10:32:43.093-[boot] Processed    : [verbosity 2]

1/8-10:32:43.093-[boot] Boot flags   : [no-screen verbose tray-only]
1/8-10:32:43.093-[boot] Data folder  : %./

oops .. another v

now got a crash log

1-Aug-2009/10:34:38-7:00 : make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'set-modes
    arg2: 'target
    arg3: [file! url! block! port!]
    near: [set-modes sys remote-mode]
    where: 'set-tray-remote-events
]

Same here, but runs ok if I encap from my personal repository, so 
it's maybe caused by an out-of-sync file in the svn repository.

oh ....

would you do a cmd encap?

or checkout from the repository and try encapping again from new 
checkout?

It's ok with enface, but fails as yours with encmdview.

older cheyenne is okay with encmdview

Crash located in %uni-engine.r at this line :

get in new 'on-received

Encmdview chokes on my IN native spec block patching.

oh...

I think it runs okay under rebcmdview though

Hope I haven't ruined your weekend now!

Code path for IN patching differs when running encapped.

No, I've just patched the code to take account on the new encap behaviour, 
just testing it. ;-)

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

Did you notice it gets the port wrong when you hove over it?

Yes, that's fixed. It was working ok if custom port was specified 
from command line (-p option) but not if set in the config file.

Updating the svn...

Done.

I'm trying to run cheyenne on EC2 ...

more problems than I thought I would have

What OS are you running Cheyenne on?

windows 2003 datacenter edition

now have this error when using the test appp

1-Aug-2009/23:37:10+12:00 : make object! [
    code: 507
    type: 'access
    id: 'no-connect
    arg1: 127.0.0.1
    arg2: none
    arg3: none

    near: [server: open/binary/direct rejoin [tcp:// server-address ":" 
    server-port] 
        set-modes
    ]
    where: 'connect
]

this was after checking out head 4

Ignore ... I was running two copies of cheyenne

Latest now works on Windows 7 but still fails on Windows 2003

1-Aug-2009/11:54:59-7:00 : make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'set-modes
    arg2: 'target
    arg3: [file! url! block! port!]
    near: [set-modes sys remote-mode]
    where: 'set-tray-remote-events
]

This is the latest build encapped http://pwp.s3.amazonaws.com/checmd090802.exe

Works under windows 7, dies under Windows 2003 - anyone else can 
confirm?

Works ok on Vista SP2.

Any suggestions then?

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

yes.

and encmdface

as i mentioned above, the old encapped command version of cheyenne 
works fine under 2003

Did you tried to run it in service mode?

no

But my old version doesn't run in service mode.