World: r3wp

I am using the example from the RSP API  - locale/set-lang 'fr

I had also issues posting on AltMe today.

Have you put the LOCALES-DIR directive in a webapp definition?

Yes 	webapp [
	
		virtual-root "/DocK"
		root-dir %www/DocK/

		locales-dir %www/DocK/catalogs/
		debug
	
	]

I tried a lot of combinations .... %catalogs %www/catalogs with the 
.cat files at all levels

Have you restarted Cheyenne each time you changed the configuration 
file?

I don't remember exactly right now but I think when I used cheyenne 
in multilingual I had some problems with this too, and I hacked RSP.r 
(I think) I hardcoded some path to make it work .. it's a while

MikeL: I'll write a small test using the example from the doc to 
see if there's something wrong there. I got localization working 
correctly in CureCode, but that's the only webapp where I used it, 
so unknows issues with paths are not excluded.

Thanks Doc. Keep Red first priority though.

Some other things don't work for me ...  Jobs don't fire as documented.

When I get something working I will document in your Cheyenne wiki.

Try with: locales-dir %DocK/catalogs/

That should be the correct path. Catalogs files must reside in their 
lang folders (catalogs/en/en.cat, catalogs/fr/fr.cat)

Jobs are quite experimental, but should be working in the general 
case (I'm using it on cheyenne-server.org to run a batch script every 
hour).

Testing the set-lang example locally, works ok here. With "locale/set-lang 
'fr" I get:
Bonjour Bonjour nous sommes en Mars

With "locale/set-lang 'en", I get: 
Bonjour Hello we are in March

Is that modeled after Amiga catalogs? The file structure is exactly 
the same in Syllable :-)

Maybe inspired by Amiga at an unconscious level when I wrote it. 
;-)

MikeL: I've upload my testing webapp, you can get it from: http://cheyenne-server.org/tmp/test-lang.zip
And this is the configuration I've used for it:

default [
	...
	webapp [
		virtual-root      "/test-lang"
		root-dir            %www/test-lang/
		locales-dir     %catalogs/
	]
]

Thanks Doc. No luck so far. But will keep trying. I am running Win7 
binary cheyenne-r0920-pro.exe

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.