World: r3wp

Doc: Same error with latest r173 version.

I just put the databases block into webap block, didn't change anything 
in the testapp,

	webapp [
		databases [
			cdr	odbc://sa:[qwe123-:-cdr]
		]
		virtual-root "/testapp"
		root-dir %www/testapp/
		auth "/testapp/login.rsp"
		;debug
	]
error is:
    code: 515
    type: 'access
    id: 'invalid-path
    arg1: {/E/cheyenne-sources/Cheyenne/www/testapp//index.rsp}

Note that the double slash in arg1.

Chrome shows "No data received"

Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection 
without sending any data.

Thank you for the test, I'll will try to reproduce it here.

Doc: I found where the bug is:
It is in mod-fastcgi.r file line 65:
new: rejoin [cfg/root-dir req/in/path file]

cfg/root-dir: %www/testapp/
req/in/path: "/"
file: %index.rsp
new: %www/testapp//index.rsp

But it is not the only problem because if I replace // with / in 
"new" then it doesn't produce error but gives 404.

rejoin [cfg/root-dir req/in/path file] exists in mod-static.r file 
but it works well. So there should be something wrong in req/in/path 
IF there is databases section in webapp. I don't know how related 
they are.

Thanks for digging this up, I'll have a quick look on it later today.

I'm trying to send an email within an .rsp script. Is this not possible 
because I keep getting errors: 


** User Error : Server error: tcp 503 AUTH command used when not 
advertised 
** Where: none 
** Near:  [smtp-port: open [scheme: 'esmtp]

Looks like a ESMTP scheme issue. Is it working from console (using 
same REBOL version)?

Code works on same machine in rebol console but I'm using exe version 
of cheyenne. Does that make a diff?

Alan, you do know Cheyenne has a built in mail server ?

No

How's it configed? I don't see it in the docs

You can use that to send email instead of using 'send

Check the mail demo that is included in the distribution

ie. www/email.rsp

will do...thanks again

What exe version of Cheyenne are you using?

I was using an older version (not sure which) so I upgraded to newest 
version and email works! but now I have some .rsp scripts failing 
: #[object! [ code: 311 type: script id: invalid-path arg1: MTA arg2: 
#[none] arg3: #[none] near: [port-id: any [ all [ value? 'servers-port 
block? servers-port servers-port/MTA ] 9803 ]] where: context ]]

I'm using the same httpd.cfg . Any configs that are diff that may 
need to be changed?

only path in that error is servers-port/MTA .. have you probed this?

Got it mostly working. Most scripts seem to be ok but one script 
keeps giving following error:

#[object! [ code: 303 type: script id: expect-arg arg1: copy arg2: 
range arg3: [#[datatype! number!] #[datatype! series!] #[datatype! 
port!] #[datatype! pair!]] near: [cmd: copy/part skip header 2] where: 
on-task-received ]]

The above error is on a .cgi script. cgi is on by default right?

The module needs to be enabled in the config file

fastcgi is uncommented in module list in config file

I converted the script to .rsp and it still gives an error. Must 
be something in the script but the same script runs on previous version 
of cheyenne and the new version does run other .rsp scripts.

Got .rsp working fully but .cgi still bombing...good enough for me 
for now.

I found out recently that Cheyenne has trouble with the PHP-based 
DokuWiki. Using FastCGI, it will work until you open the Media Manager 
and then Cheyenne will "hang". You have to restart Cheyenne. I haven't 
had time to troubleshoot yet.

I use Cheyenne to keep myself from PHP:)

Same for me :) keep away from PHP, IIS, Apache, CGI.
RSP is the best ;)

I agree, but DokuWiki is written in PHP. I was just trying to avoid 
Apache.

what do you see in Cheyenne's trace.log or crash.log file?

Is it still necessary to patch PHP for Cheyenne?

I have a problem running cheyenne-0920-cmd.exe as a service on Windows 
Server 2003 (32Bit)
Same version runs on XP/Pro (SP3). 
Crash.log:
10-Feb-2012/12:07:10+2:00 : make object! [
    code: 500
    type: 'access
    id: 'cannot-open
    arg1: "/C/cheyenne_tt/service.dll as library"
    arg2: none
    arg3: none
    near: [do make routine! [] load/library]
    where: 'launch-service
]

My Win2003 issue is still not solved, but I have one additional question,

RSPs can read/write anywhere in the server, even they are in a webapp. 
Is it not a security hole? If someone able to upload an rsp file 
and execute it, he can delete a vital file from the system, or read 
whole directory structure.
Is there a way to run Cheyenne (or a webapp) in a sandbox?

Oh ok, I can run Cheyenne in other than LocalSystem account such 
as Guest or another limited user account so it cannot read/write 
other directories.

It's better to create a user for Cheyenne to be able to control fully.

I have another issue, Cheyenne hangs if do-sql/flat used and the 
result is empty. if no /flat it works, returns empty block.
result: do-sql/flat 'test "select top 0 * from mytable"

Even if I stop the service (or Quit from tray menu, if runs as app) 
one of the Cheyenne processes stays in the background.

Problem occurs in latest SVN version as well.
It hangs on line 487 on file handlers\RSP.r

until [if data: pick port 1 [append out data] data]

I think pick port 1 waits forever.

I've fixed the problem. PICK port 1 returns NONE if the result is 
empty, so UNTIL never finishes.

DOC: I've fixed the do-sql/flat bug if the result is empty.
In RSP.r file on line 487:
    until [if data: pick port 1 [append out data] data]
should be
    while [data: pick port 1] [append out data]

this should also work  (and should theoretically be faster:

 until [not if data: pick port 1 [append out data]]

WHILE reads much better there though.

They give very close result, WHILE looks a bit faster.

;b is a block of some numbers, benchmark func loop 1'000'000 times.

>> benchmark [i: 1 until [not if x: pick b i [++ i x]]]
== 0:00:38.953

>> benchmark [i: 1 while [x: pick b i] [++ i]]
== 0:00:35.688

On my EeePC 1.6 Ghz N270, XP/Home.

with R3, I guess

gregg, true, but with cheyenne, performance is more important than 
readability  ;-)


Endo, I am surprised they are so close in your test... in mine, while 
is usually about 25% slower than until (but obviously, what you put 
within the loop has some incidence on the results, so it may just 
be that in this setup the condition is quicker to setup within the 
while.

Performance, anywhere, is only important if the difference is big 
enough to matter, not just measure. :-)

Well said

My test was on R2, may be would be different on R3.
I'm mostly agree with Gregg.

This line is in do-sql/flat function (if you use R2 native drivers, 
not in Softinnov's mysql driver) so if your resultset has millions 
of rows you gain 3-4 seconds on a slow machine.

Gregg, I know your take on optimisation... ;-)


<start rant  ;-) > If I had the same opinion, liquid would still 
be 10 times slower than it is now.   each little part of the changes 
add up and after years it really adds up.  I have some new changes 
which will probably shave off another 5-10% when they are done.  
 It requires several changes (some probably removing  less than a 
%).  its been like that since the begining.  the relative impact 
of any optimisation is always bigger the more you do it.  


the first 1% looks like nothing when you compare it to the original 
100% but after you've removed 25% its now 1.33%... but when your 
app is 10 times faster, that 1% is now 10 % of the new speed.


btw, I'm not trying to justify this specific optimisation, but I'm 
trying to balance the general REBOLer consensus that optimisation 
(in speed, code size and RAM use) isn't important when compared to 
other Reboling tasks... 
 

Have you (using "you" in the general sense, not gregg specifically) 
ever looked at Carl's Code?  its some of the most optimised and dense 
code out there... it hurts the brain... and its very enlightening 
too.  all the little variations in the series handlers often are 
there by  design and all balanced out against the others.  Carl uses 
all of those little variations profusely... to me its in the very 
essence of REBOL to be optimal and constantly be refined, improved, 
and this usually means by shrinking it in all vectors.  

<end of rant  ;-) >