World: r3wp

That should mean I will now be able to use the 0MQ binding

hmm... i thought i can put my shared library code above the webapp 
root, but it seem to fail without any errors.

what exactly is the purpose of the overwritten 'do function in the 
RSP handler?
i don't quite get that depth/1 and arg/3 stuff

i was moving a plain .r script which was aliased in a vhost context 
under a webapp and it started to fail because the 'do didn't seem 
to work properly

REBOL []  do %../lib/obj.r  probe to-object [a: 1]

obj.r defines to-object but i get a
        ** Script Error : to-object has no value

i moved the library stuff into on-application-start, but still it 
wasted me a lot of time to realize that the 'do is overwritten in 
RSP and works specially (as in, it does not work) in webapp context

what exactly is the purpose of the overwritten 'do function in the 
RSP handler?
 Bind the loaded code to a special per-webapp context.

A webapp execution context is isolated as much as possible from the 
rest of the vhost.

set 'do func [[catch] value	/args arg /next /global /local depth][	
...
			if arg: find apps request/config/root-dir [

looks like u r using a parameter as a local variable

I thought I've added a note about DO having special effect in RSP 
scripts, but I can't find any mention in the wiki.

i think there was some conversation about the overwriting 'do on 
altme, but i couldn't find it in the docs either... maybe in the 
changelog?..

The 'arg parameter is processed before that line by: 

    if args [return *do/args value arg]

sure, and then u overwrite it

ChangeLog: yes, you should find it mentioned there. I need to add 
a proper entry in the wiki about that anyway.

Tamas, parameters ARE local variables

Kaj: im just saying, it's a bit misleading to use an input parameter 
later as a temp variable in an other meaning

do/global works, btw, however a plain 'do fails very interestingly 
and reproducably

if i edit the file above while cheyenne is running, it starts to 
work; to-object is found

Right, words definitions that needs to be loaded in global context 
have to be loaded using 'do/global.

these are webapp specific functions though, so i would have appreciated 
if they worked ;)

Where are you loading them? 'on-application-start?

Where => From where

REBOL []  do %../lib/obj.r  probe to-object [a: 1]

this is my test.r file and im calling it from a webapp

from the root of a webapp

Ok. Will test that case locally later tonight, dinner time now.

cool, thx, i'll be here!

i want cheyenne to be less sucky, really. it's one of the nicest 
rebol projects and it's a shame if i can break it every second day... 
makes me not very proud of it... :/

There are countless ways to break one's code using REBOL scripts. 
;-)

Also, about using plain REBOL scripts in RSP engine, it was a last 
year request from Carl, it wasn't part of my planned feature list 
to support, so it can cause new issues that I have not forseen when 
building the RSP engine. You are the first one to report me issues 
with such scripts, so I guess nobody except you and Carl are using 
this approach. Anyway, your reports are helping me make it more reliable.

until yesterday the very same script was within <% %> tags actually 
and this effect was still observable.

just the latest svn version didn't accept the tags in a .r file anymore, 
that's why im showing it as a REBOL[] script.

otherwise, i was just following common sense and trying to get things 
done in an ultra primitive way :)

the script worked and still works as a CGI script btw, so i bravely 
switched over to the RSP handler as it's been suggested on the "Basics" 
documentation page and i was using the very same unless value? 'my-object 
pattern to load my libs.

what does "run Cheyenne with a non-persistent? worker." mean, btw? 
-w 0?

Yes, it means starting it with -w 0.

It works here in a vhost (not in a webapp) using:

%obj.r  => REBOL [] to-object: func [a [block!]][context a]
%test.r => REBOL []  do %../libs/obj.r  probe to-object [a: 1]

Testing within a webapp now...

>> read http://localhost/test.r
== "make object! [^/    a: 1^/]"

From a webapp, it works ok too:

%libs/obj.r  => REBOL [] to-object: func [a [block!]][context a]

%www/testapp/test.r => REBOL []  do %../libs/obj.r  probe to-object 
[a: 1]

>> read http://localhost/testapp/test.r
== "make object! [^/    a: 1^/]"

I have disabled the 'auth keyword from /testapp webapp to do this 
test, to avoid being redirected to a login page.

I have run the tests using -w 1, using -w 0, I get a "to-object has 
no value" error.

(im not sure im following u, but i guess u r logging for urself mostly)

Basically, your issue is related to the Cheyenne "debug" mode that 
restart all workers after each request. In normal mode (persistant 
workers), it should work fine.

I am investigating now how Cheyenne's debug mode can causes that 
issue in such case.

im running with -w 1. is it debug mode too?

No.

I can't get the error here using -w 1, only using -w 0.

Can you show me the content of %obj.r from : do %../lib/obj.r?

New Cheyenne revision: 138


FIX: RSP code binding issue with nested DO calls (thanks to Tamas 
Herman for
reporting it).


Please pay attention that this fix is really deep in RSP engine, 
I have tested it with all my RSP apps, but regressions are not excluded. 
Be sure to report me any odd changes in your app behaviour after 
upgrading to r138.

Dunno if this is relevant .. but I tend to use 'do* instead of 'do

do* == do/global == native 'do

There are cases where you want to bind your code to global context, 
so you will use 'do/global. For all other cases, you should just 
use 'do (especially now that nested 'do should to be fixed).