World: r3wp

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.

'set-tray-remote-events is called only in 'do-tray-app which is called 
when Cheyenne is running as a service to install a standalone version 
of the tray icon with menus (for remote control of the Cheyenne service).

I just encapped the checkout from svn

didn't alter the source

Check if a Cheyenne service is not installed.

check to see if there is a cheyenne service already installed??

There isn't a service installed .. but now it's working!

I did try and install the old version as a service, and that failed. 
 Perhaps it left something running that caused the new build to fail? 
 and when I rebooted ... it went away?

Maybe a Cheyenne process left running?

maybe ... I'll watch out for it next time.

this is what I am using for my webapps

	webapp [
		; user1
		virtual-root "/mdz"
		root-dir %/z/pwp/www/mdz/
		auth "/mdz/login.rsp"
 		databases [ emr odbc://user1 ]
		;debug
	]
	webapp [
		; user2
		virtual-root "/mdy"
		root-dir %/y/pwp/www/mdy/
		auth "/mdy/login.rsp"
	 	databases [ emr odbc://user2 ]
		;debug
	]

seems to be working .. so far

Ok, I right clicked on cheyenne in the system tray and set it as 
a service.  It exited immediately from the system tray, and i could 
not run it again wihtout the above error.

I looked in the running processes and don't see anything.  I think 
I'll have to reboot the windows 2003 server.

No, can't get Cheyenne up and running again ... what's causing it 
to default to service mode?

Ok, there is a cheyenne service .. how can I remove it?

Run Cheyenne once with -u command line option to uninstall the service, 
then you can run it again in user mode.

The service mode is tricky, especially when the current Windows user 
is not the Administrator.

I'm getting an error that msvcr71.dll is missing

when I run cheyenne from command line

I don't think you run cheyenne from DOS prompt. Create a dedicated 
shortcut and edit the shorcut properties to add -u in the first field.

you <can> run

-u worked and I now have it running in user mode

from dos prompt