World: r3wp

It would be great if the drivers (mysql/sqlite/odbc/postgre) included 
in cheyenne. Ofcourse external dependencies is not good for Cheyenne, 
but optional driver-included binaries would be good anyway.

Well, that's a good idea, but the SDK license is quite restrictive, 
I shouldn't distribute Cheyenne in binary form (see "REBOL API Restriction" 
part at http://www.rebol.com/docs/sdk/sdkintro.html). RT didn't asked 
me to pay any additional license so far, so I don't want to push 
it further by giving away a free /Command with Cheyenne.

Does anybody use user and group directive in httpd.cfg? When I uncoment 
it and use own user name, than I got error:
## Error in [conf-parser] : Error in conf file at:
user oldes
group oldes

Hm.. probably needs mod-userdir enabled... but then it crashes completely:/

ech.. found reason -  now the logger does not have rights to write... 
so it could be fixed

Is anyone running cheyenne, the source code version on linux, with 
the need of /Library (like sqlite / pdf / ... binding) and need to 
setup set-net (for sending email)? If, how are you running it, with 
what version of rebol and how?

Unfortunately I don't think it's possible. At least if you can't 
use /View version or don't have SDK license for Linux (needed for 
Rebol/pro).

Ask Carl to remove the library restriction.

in /core you mean... I guess.

There is no library support in Linux's version of REBOL/Core. Only 
in the /View version I guess... but that's in most cases not possible 
to use on servers as not many servers are with X server installed 
as well.

REBOL/Pro was supposed to be the /Core with the library support enabled.

The problem now is not the /Library support but the "set-net" / user.r

it is imo a bug. There is absolutly no reason why rebpro kernel should 
behave differently from other kernels in the SDK.

I think if I could make user.r execute on start this problem would 
be solved. I wasn't able to make it autoexecute on linux yesterday 
.. I already spent 6  hours before with this stuff without accomplishing 
anything so I stopped at that point. I will try with user.r again 
now. user.r didn't start on rebol/core or rebpro on linux for me 
yesterday ( I had rebol.r and user.r in same file as script, in same 
file as executables, I tried to set REBOL_HOME and REBOLHOME)

Janko - try to avoid set-net in the user.r, or just load missing 
mezzanines at the beginning of the user.r

yes, I need user.r to load the mezzaines.. I have set-net in cheyenne 
then

I should move this back to Linux probably

Pekr, rebpro doesn't behave differently than the other kernels in 
the SDK - which are rebbase and rebface - it just behaves differently 
than the prepackaged interpreters.

anyone know how I can start cheyenne automatically ?
this is what I am doing currently on Ubuntu


http://content.screencast.com/users/SynapseEMR/folders/Jing/media/fce31231-a410-4ee8-a602-0ebb891ede0c/2010-04-26_1057.swf

I'm typing the start up commands

I had this setup on one server. You have to play with etc/init.d 
folders .. I currently also don't have it setup that way because 
I had some problems then and one guy showed me some simpler way. 
(but I can't remember it right now, I can ask him tomorrow)

ok

with init.d you have multiple files for different stages of startup 
and shutdown process so it's a little complicated.. the guy (he was 
on ubuntu showed me just one file where you add cli commands and 
that's it)

Graham, which version of Ubuntu are you using? The newest version 
of Ubuntu doesn't use the /etc/init.d system anymore, it uses upstart 
instead: http://upstart.ubuntu.com/getting-started.html.Much easier 
but less powerful (but maybe enough for you) is editing the /etc/rc.local 
file. That just starts an app after booting, it doesn't allow you 
to restart or stop it with a command. Just put the command to start 
up cheyenne on a line between "# By default this script does nothing." 
and "exit 0"

Even better though would be if you wrote a small demon script in 
rebol or bash or whatever you like, that gets started by rc.local 
instead of directly starting cheyenne. This demon would check all 
running tasks every 60 seconds and see if cheyenne is still running, 
otherwise restart it. This way, if cheyenne should crash, it is automatically 
restarted.

I think there are some applications that do this.. can't remember 
their names right now

It's not my server .. .I just told them to install ubuntu server 
32 bit

I'll have a look .. but I'm having issues now starting cheyenne. 
 I'm using the latest binary from doc but it just stops

I have to run cheyenne.r to allow it to create a cache.efs file and 
then I can run the binary

ie. I use rebol core and use the source version

going to try the rc.local

Doesn't seem to be predictable ...

Is there a simple file upload script demo .... ?

Hmm.. Cheyenne is not handling HEAD correctly

>> read/custom  http://www.curecode.org/[ HEAD "" ]
URL Parse: none none www.curecode.org none none none
Net-log: ["Opening" "tcp" "for" "HTTP"]
connecting to: www.curecode.org
Net-log: {HEAD / HTTP/1.0
Accept: */*
Connection: close
User-Agent: REBOL View 2.7.6.3.1
Host: www.curecode.org
Referer: http://www.curecode.org/
}
Net-log: "HTTP/1.1 200 OK"
Net-log: ["low level read of " 2048 "bytes"]

my error .. I'm using an old version of Cheyenne

Mine is Server: "Cheyenne/0.9.18"

Guess the error is fixed now...

Upgraded to Server: "Cheyenne/0.9.19" but bug is still present.

this is with 9.19


>> read/custom  http://129.33.194.254:8080/tempsdfsfsadfasdfasf/hasfasdfsfpkkkk.pdf 
[ HEAD "" ]


URL Parse: none none 129.33.194.254 8080 tempsdfsfsadfasdfasf/ hasfasdfsfpkkkk.pdf
Net-log: ["Opening" "tcp" "for" "HTTP"]
connecting to: 129.33.194.254
Net-log: {HEAD /tempsdfsfsadfasdfasf/hasfasdfsfpkkkk.pdf HTTP/1.0
Accept: */*
Connection: close
User-Agent: REBOL View 2.7.6.3.1
Host: 129.33.194.254:8080

Referer: http://129.33.194.254:8080/tempsdfsfsadfasdfasf/hasfasdfsfpkkkk.pdf
}
Net-log: "HTTP/1.1 200 OK"
Net-log: ["low level read of " 2048 "bytes"]

this is for a non existent file

I wonder if the custom 404 handler is causing this.

Doc, any explanation as to why it can be so hard to start Cheyenne? 
 I think it is to do with the .cache.efs file

There is upload demo... check upload.html and upload.rsp files

The problems with start: check log files. Run cheyenne in debug mode 
like:  ./cheyenne -vvvv

It never gets as far as creating the pid-log files

the process just terminates

as for upload ... I used something I found that I wrote a few years 
ago :)

doc, you should focus your development on nodejs, or look at event 
driven Cheyenne version

Anyone benchmarked Cheyenne vs nodejs ?  Both are event driven.

Here's a small bug fix for Cheyenne