World: r3wp

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  ;-) >

I agree with you Maxim.

But on the other hand, I never allow my team to sacrifice the readability 
unless IF there is a really good reason to do that AND IF they put 
enough comment WHAT and WHY they do that. Otherwise it wastes our 
time to "solve" the optimisation a few months later.

Optimisations are good / necessary if they are (can be) in loops 
(mostly), but they are dangerous especially if you are writting lower 
level code (mostly C, even Java) because compilers use code-patterns 
to optimize your code, so your hand-optimized code prevents compiler 
optimizations on modern compilers.

And worst, if you are using assembly, your optimizations may prevent 
to use CPU caches and for example when it works faster on one CPU 
it can be even slower than the original version on another CPU.

By the way, I tested on 3 different PC with R2, while loop was always 
faster then the until loop in the above case. Of course I didn't 
test the real case (using do-sql with millions of rows)

And of course Carl should write very optimized code in REBOL because 
everything else is depend on it. 
Hmm I think we should move to another group :)

If I had the same opinion, liquid would still be 10 times slower 
than it is now.


That's big enough to matter, not just measure. I think, that's what 
Gregg pointed out. And remember, there is not a final truth about 
this, as what matters to one person, might not to another.

It doesn't really matter if you get a 133% increase in the speed 
of glass if it has been abandoned for Rebol! lol

My thoughts, too. There's also the matter of why REBOL and AltME 
are such slow memory hogs if Carl's code is so good. The reasons 
are found elsewhere. REBOL systems have aspects of penny wise, pound 
foolish. The actual code needs to be optimised to limit the damage 
a bit

Has Carl been the sole developer of Altme ?

I believe in optimizing on a case by case basis, as most do. And 
I believe in optimizing different things in any given case. Size, 
speed, felxibility, and readability are all fair game for optimization.


As far as AltME and other slow REBOL UIs, I remember Carl saying 
once that View is a miser, saving pennies, while VID is the government 
and spends millions. I think whoever designed the list model used 
in AltMe and other apps (e.g. IOS conference and messenger) chose 
to make the implementation small and quick to write, knowing that 
they might not be fast. They may also not have imagined how far they 
would be pushed.

View is a miser...

 That certainly depends on how you use VID. VIew's SHOW function is 
 a big bottleneck and the most important function of all to optimize 
 for. But yes, AltME lists are rather heavy.