World: r3wp

and it's failing somewhere?

some processes will... right now I am implementing my own handler 
module, which means the code will be running in an external process. 
 I want that process (all four, in fact) to open its own console 
and print there.   


its MUCH simpler to debug, and follow what is happening.  trying 
to merge all the feedback from uniserve and all the threads in parralel 
is not optimal.

uniserve is working ok... its my code running outside of the uniserve 
process which will fail.

so I'm not using rsp, or cgi ... its my own handler.

maybe a system/words/print or somethng like that

does each process have its own process id ?

yeah they are physically different.

and the logging doesn't give the process id?

I don't want logging... I need to look at it live... these services 
actually do network calls and wait on other servers... I need to 
look at them run each on their own... if one blocks... I don't want 
all the other logs to push of the view.


also, the worker process might be having mutually exclusive or causal 
side-effects.   with a different console view opened side-by-side 
its easy to see all these effects.  (one window jams when another 
runs... continues when the other is done... etc.

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?