World: r3wp

I've just tested with the same binary on Win7 32-bit...works ok.

Thanks Doc.  Clearly something I'm doing wrong. I will work through 
it. .... Now back to Red! :-)

Works if I follow the instructions ... don't know which one went 
awry but functions per Doc-umentation.

Cheyenne revision 126:


FIX: (Windows) issue with current OS path in source mode and REBOL 
v2.7.8.

FIX: (Windows) 'set-env function not redefined if already available 
as native.

FIX: (Windows) CGI now properly uses call.r instead of native CALL.


Windows binaries re-released on http://cheyenne-server.org/download.shtml

This new version was required to workaround the native CALL/OUTPUT 
corruption bug that was affecting CGI binary output in Cheyenne.

Many thanks Doc.

You're welcome.

this will seem like a dumb question but....


anyone know how I can get worker threads in cheyenne to actually 
open a console and allow on-screen tracing?


right now I've got 4 workers and no one opens up a console screen... 
I really need this real-time tracing, since the server is being monitored 
in real-time using remote-desktop or vnc.

- v v v v v v v v v v

The main thread is running with -vvvvv and its showing some console... 
but I am expecting 5 console windows to open.

(one for each rebol process)

I think you only see one console

there's a single logging process I think

my client had one console for each process on his cheyenne setup... 
I need to see what is happening independently from each other.  trying 
to follow 5 high-speed traces in a single file, is like using altme 
without any groups  it would be impossible.  ;-)


if one worker has a fuck up i need to be able to see why *it* is 
failing.

my client
  (as in a customer who was using cheyenne)

even more important in development

you can still set debug to the trace log

but that is a single file for several thread... its impossible to 
use when there is traffic.

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?