World: r3wp

To open a console window for each worker process, you need to change 
the CALL command line from %UniServe/uni-engine.r:

    call join form to-local-file system/options/boot [" -qws " cmd]

Replace:
* CALL with CALL/SHOW
* -qws with -s


Also, in that case it is also more practical to reduce the worker 
number to 1 using Cheyenne command line option: -w 1

thanks doc.

guys, how can i get rid of these chey-pid-*.log files? or at least 
i would like to put them under a %log/ dir

No way to redirect those log files yet. You can change their path 
by patching %cheyenne.r file. You can also just delete them once 
Cheyenne started, if all goes well, they shouldn't reappear until 
next restart.

thx, doc. we are working on all win/lin/mac and i don't have the 
sdk :/ i was advertising cheyenne as an awesome, simple, cross-platform 
solution which is just 1 exe + 1 config and now i should either run 
from source or wrap it :/

As a quick fix, I can patch %cheyenne.r to redirect %chey-pid* files 
to %log/ folder and upload a new Windows/Linux binary (OS X would 
take more time). Would that suit your needs?

well, it sounds awesome for me, but i don't know about the others

our main development platform is mac, though

and btw, i tried to run it from source and i got this

Script: "Cheyenne Web Server" (2-Mar-2011)
Script: "Encap virtual filesystem" (21-Sep-2009)

** Access Error: Cannot open /Users/onetom/rebol/cheyenne-server-read-only/Cheyenne/libc.dylib
** Where: do-cache
** Near: all [
    libc: load/library %libc.dylib

onetom ~/rebol/cheyenne-server-read-only/Cheyenne $ svn up
At revision 127.

I'll boot my Mac 10.6 image (takes some time) and test it from source.

Will probably do that in a couple of hours (after lunch).

good apetite, im having lunch-dinner too. tom yam kung soup. i'd 
be happy to invite u to have some :)

I would be pleased, but unfortunately, Phuket is a bit far from Paris. 
:-)

half a day... think about it ;)

Dockimbel: i sent u an email with some background story which can 
help to think about a good solution

feature request :  I would loke to have some configs (in httpd.cfg) 
for controling things like the verbosity and logging.

i would help making these patches but i can't run cheyenne (on a 
mac) from source. can u, maxim?

I'm just doing windows these days.

Cheyenne source & OS X: I can reproduce the error. Looking for the 
cause...

OK, the right path for the Libc is: %/usr/lib/libc.dylib

why do we need it at all?

rebol/core can't use libs anyway, can it?

No, it can't on OS X.

but pro can no?

Pro: yes

/Library component is needed on UNIX (including OS X) to map: set-uid, 
set-gid, chown, kill and get-pid

aha... so i need /view. it would be great to insert this line on 
the download page.

or into the source code at least

but isn't it required only if i use the mod-userdir?

(which i would like to see an example about too. any urls about it?)

Carl has introduced 'access-os native in 2.7.8 to map internally 
all those external dependencies, I haven't tested if it was available 
on OS X too, doing it now...

kill( ) and get-pid( ) are needed in all cases

(running rebview -qws cheyenne.r even with -w 0 is really ugly under 
osx, because of the 2 black app icons which doesn't even have a window 
associated.... :/)

but it works with rebview. would be nice to still have a /core only 
version

there was no need for changing the %libc.dylib

The OS most probably uses its search paths to find it

Right, library loading works OK with rebpro too without any change.

It seems that 'access-os is active under OS X too. I'm adding the 
support for it right now, so that Cheyenne can run on /Core too.

so, i can't run it from source on a headless linux server, right?

that would be awesome

i will test it immediately

Dockimbel: did u get my email too?

Yes, it can since 0.9.20, thanks to 'access-os native, and it will 
in a few minutes on OS X too (requires /Core 2.7.8)

onetom: yes, I will look into it right after fixing this issue.

doc, having issues with a handler I am building.  


my mod is using send-msg (taken from the RSP mod) in the make-response().


the handler actually pops-up and it runs the proper code, I can see 
the printing in the console.

when my god gets its task-done called, it has the proper code in 
the result....
 all seems good..   :-)

except:

   the browser doesn't get the response and it hangs (telling me that 
   its waiting for the server).

any clues?

god = mod   hehehe

Maxim: r u returning true at the end of make-response?

Max: have you copied the calls to service/* in mod-rsp/task-done? 
(Will check that after fixing this issue)