World: r3wp

In general, I notice that almost all web platform projects (and operating 
system projects for that matter) are either very focused on the server, 
or very focused on the client, apparently depending on the preference 
and abilities of the founders. This doesn't make sense to me: a network 
app by definition needs to deal with both sides of the connection, 
and find the best balance

i wish rebol/view was that good to replace the browser, but im typing 
this on a mac w ugly, aliased, miniature fonts and i can't even use 
the maximize button because it fucks up the screen size and layout...

angularjs is surprisingly backward compatible, btw... but serverside 
validation is still a must of course.

in this particular project we tried view, btw, but we need it on 
a tablet later in a warehouse, so /view is not an option at the end 
:(

is the source code for TryREBOL available somewhere?

Only the client code

Yeah, we're waiting for R3/GUI/ReBrowser...

AngularJS specifies a minimum of IE6, and IE7 for CSS, and no word 
about Opera and less popular browser engines. My system works from 
IE5 on (anything with AJAX)

Why wouldn't you be able to run View on a tablet?

by tablet, i meant something usable, like ipad or galaxy tab... do 
u know any tablet pc w capacitive touchscreen, half day battery life 
around ipad price?

No idea, but there are many now, so there must be a number of choices 
for the price of an iPad

im loading libraries from on-application-start, then i was hoping 
to load some static data too, but the words i assign there can't 
be found in my script later.

the script is called via an alias though which was specified within 
a webapp section.

on-application-start: does [
do %some/lib.r
db: %db/dir/some/where/
]

httpd.cfg:
vhost [
  webapp [
    alias "/xxx" "db.r"
  ]
]


db.r can't access the db variable, although it can use the words 
defined in the library loaded by 'do

ok, probably im trying to do something forbidden there


6/5-17:27:41.971934-[Logger] New request: T6/5-17:27:41.948903-## 
Error in [task-handler-55484] : Make object! [
    code: 312
    type: 'script
    id: 'cannot-use
    arg1: 'path
    arg2: 'none!
    arg3: none
    near: [switch debug-banner/opts/error [
            inline [html-form-error err file] 
            popup [debug-banner/rsp-error: make err [src: file]]
        ]]
    where: 'protected-exec
] !

which part of this code might cause the - otherwise not very informative 
- error above?

  parties: map-each f read db [to-object load db/:f]

now, i got back the source of the aliased rebol script

wow!!!! there was an extra closing bracket before the end of the 
script and it completely derailed processing and i got back the script 
source itself as a response

Can you send me a minimal version of your script producing this error? 
I would like to see how it can affect the internal code so deeply.

im chopping it down now

did u get it? no immediate thoughts?

I got it but was busy with other tasks. Will look into it in a few 
minutes.

Error reproduced. Tested with similar code within RSP: <% ] %> is 
producing an error, but it is handled nicely.

onetom: fix pushed for the issue you have reported. Let me know if 
it works ok for you.

im getting different errors now, but trying to dig to its roots

confirmed: my script works w r135 but not w r136 (this is a different 
script)

** Syntax Error : Missing [ at end-of-block 
    ** Where: none 
    ** Near:  "(line 5) ]" 
thats all i get as an error msg

hmm... it's a .r file but it's in rsp format, so no rebol header 
but <% %> tags.
so i guess it's the right behaviour

if i was calling the script .rsp and also bind-extern .rsp to the 
RSP handler then it worked too.

is it something hardwired in cheyenne, if the extension is .r then 
is should be handled as a plain rebol script?

bugfix worked. thx

s it something hardwired in cheyenne, if the extension is .r then 
is should be handled as a plain rebol script?

 Yes, .r scripts are processed as plain REBOL scripts but with the 
 addition of the whole RSP API since r100 (http://code.google.com/p/cheyenne-server/source/detail?r=100).


It has been officialy documented on the wiki only recently: http://cheyenne-server.org/wiki/Rsp/Basis
("No-template scripts" section).

Doc, did you get a chance to debug fast-rebol-cgi?

my quesstion was rather: where and how is it hardwired that .r is 
executed in rsp context? is there an internal bind-extern RSP [ .r 
] happening. do i need the rsp module for this alone or do i need 
that action module too? stuff like that. otherwise it feels pretty 
magical

we have even experienced very strange behaviour with the
unless value? 'some-func [ do %../lib/obj.r  do %../lib/oid.r ]

tactic. our to-object function defined in obj.r didnt have a value.

we modified the script, did not restart cheyenne and it started working!

it was just happening with the binary version of cheyenne, iirc, 
so i dropped the case...

Kaj: I thought it was fixed since r131: http://code.google.com/p/cheyenne-server/source/detail?r=131

AFAIR, mod-action is required for mod-rsp. bind-extern RSP .r is 
required to send .r scripts to the RSP handler in workers.

See April 25 above. I used r135:

It recognises the fast-rebol-cgi keyword in the globals now, but 
it doesn't seem to do anything. It seems to try to execute REBOL 
code as real CGI. It tries to use the shebang line and has permission 
problems with CGI files that it didn't have before

so, if there is no bind-extern RSP [ .r ] then where are the .r files 
get executed? within the main cheyenne process?

onetom: They should be just served as a static resource if the 'bind-extern 
directive is not used.

Kaj: I'm looking into that issue right now.

Kaj: I've pushed a fix in r137 for fast-rebol-cgi. It was wrongly 
defined as a Globals section keyword instead of a Host section one.

Ah, I was wondering about that

So I have to define it for every applicable host?

Yep.

Thanks, I'll try

By the way, I still want to get rid of the loading of the REBOL CGI 
script on each request, even though I've minimised its size. It's 
a fallback script that now executes in the not-found handler. If 
I would change it from a fast-rebol-cgi script to an .r script, and 
put it in an ALIAS handler, would that preempt the loading of the 
script one each request? I'm not using the RSP interface, so the 
loading of that would be extra overhead. Would it still be faster 
than loading the small fast-rebol-cgi script?

Hard question for past midnight, I think you've lost me after the 
first sentence. :-)

Oh, I thought I was the amateur. :-) Maybe a night sleep will enable 
you to answer it?

What are you calling the "not-found handler"?

404 status

Ok.