World: r3wp

#[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.

Altme is a slow UI? Just don't make me laugh, those who claim so. 
Have you tried Azureus? That's Java. Altme just runs ok. We all know, 
that the UI is not OS compatible, so there are things to be desired. 
And altme server can run for months without a restart.

Altme is consistent speed wise. I have 3 years not reinstalled my 
Vista, so once my ntb boots, it takes 5-7 minutes to be usable.I 
click on many apps to start, and Altme definitely starts first. Stuff 
as Outlook, Firefox, etc., take usually tens of seconds!

Well, this belongs to Altme, or advocacy, sorry.

The most important thing in optimization is to decide which part 
should be optimized.

If you optimize INSERT, even 0.1%, this gives a huge difference. 
But optimizing something in your INIT function which will be called 
once when the app. start.. I would say don't sacrifice the readablity.

So optimizing core is almost always necessary (like R2/3 function, 
functions in frameworks like LIQUID),

Optimizing the functions in your app. or the app. itself, only if 
it worths.

Maxim: you are mostly talking about the overall performance gain 
in the whole system. But the case above (Cheyenne, do-sql bug) we 
gain 2-3% performance just in do-sql function, IF it's used in a 
millions loop (or returns a few millions of rows) AND only IF you 
use native drivers AND only IF you use /flat refinement. which leads 
very rare cases. So the overall perfornance difference is  very very 
low. (well, still WHILE faster than UNTIL in above case anyway..)

Doc: I've solved "Cheyenne cannot be installed as a service on Windows 
2003 Server" problem.

service.dll requires msvcr71.dll to run, if not present Cheyenne 
crashes with "** Access Error: Cannot open service.dll as library" 
error.

msvcr71.dll file should be present in same folder with service.dll 
or better it should be in %windir%\system32 (or the correct path 
if 64bit OS)
I think we should note this dependency somewhere on the web site.

Right, I should also recompile it with a more recent version of msvcrt 
library I guess.

Its better Cheyenne should write (create) a msvc71.dll if it is not 
already in the same directory. Because when I search for that library 
I see that almost  every program has that dll in their own directory.

Because we cannot trust that the correct version will be in the system 
folder.
OR a better error handling/message for this error  :)

SQL Server, Office, Java, SVN, Photoshop.. they all have it in their 
own directories.. But older versions of Windows don't have it default.

It would at least double the size of the Cheyenne binary, for a feature 
only a few use. I would rather prefer to provide links for downloading 
the right DLL for each Windows version.

All the software you are listing are bloated software that don't 
care to follow the basic rule of sharing libraries, especially when 
it's the libc.

I think that the following package installs the msvcr71.dll file: 
http://www.microsoft.com/download/en/details.aspx?id=5638

You are right, giving a link is better than including the whole dll.

What do you think about making a setup package for Windows? Including 
that dll and some configuration options during the setup, service 
mode default, etc.
If do you think its worth to do, I can do it.

One of Cheyenne's selling point is: no installation required :-)