r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Cheyenne] Discussions about the Cheyenne Web Server

onetom
7-May-2011
[10301x4]
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
Dockimbel
7-May-2011
[10305x2]
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.
onetom
7-May-2011
[10307x2]
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
Dockimbel
7-May-2011
[10309]
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.
onetom
7-May-2011
[10310]
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?..
Dockimbel
7-May-2011
[10311]
The 'arg parameter is processed before that line by: 

    if args [return *do/args value arg]
onetom
7-May-2011
[10312]
sure, and then u overwrite it
Dockimbel
7-May-2011
[10313]
ChangeLog: yes, you should find it mentioned there. I need to add 
a proper entry in the wiki about that anyway.
Kaj
7-May-2011
[10314]
Tamas, parameters ARE local variables
onetom
7-May-2011
[10315x3]
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
Dockimbel
7-May-2011
[10318]
Right, words definitions that needs to be loaded in global context 
have to be loaded using 'do/global.
onetom
7-May-2011
[10319]
these are webapp specific functions though, so i would have appreciated 
if they worked ;)
Dockimbel
7-May-2011
[10320x2]
Where are you loading them? 'on-application-start?
Where => From where
onetom
7-May-2011
[10322x3]
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
Dockimbel
7-May-2011
[10325]
Ok. Will test that case locally later tonight, dinner time now.
onetom
7-May-2011
[10326x2]
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... :/
Dockimbel
7-May-2011
[10328x2]
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.
onetom
7-May-2011
[10330x3]
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?
Dockimbel
7-May-2011
[10333x6]
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.
onetom
7-May-2011
[10339]
(im not sure im following u, but i guess u r logging for urself mostly)
Dockimbel
7-May-2011
[10340x2]
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.
onetom
7-May-2011
[10342]
im running with -w 1. is it debug mode too?
Dockimbel
7-May-2011
[10343x4]
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.
GrahamC
7-May-2011
[10347]
Dunno if this is relevant .. but I tend to use 'do* instead of 'do
Dockimbel
7-May-2011
[10348]
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).
GrahamC
7-May-2011
[10349x2]
my meaning being that 'do did not work as I expected ...
I should go back and see if this new build fixes the issues I've 
had