World: r3wp

true, forgot about that
so since 0.9.20 .r is bind-externd to RSP?

does it take precedence over bind RSP too? because otherwise my thing 
seemd to work... even .r reloading was happening and all that

hmm.. this separated example doesnt work indeed

so since 0.9.20 .r is bind-externd to RSP?

 Yes, but in a particular way: .r are not considered "templates" but 
 plain REBOL scripts (with a REBOL header). So, if you want to use 
 RSP templates with .r, you should add a BIND-EXTERN directive (untested, 
 so I'm unsure if it would work)

I need to check the code for how .r are precisely handled, I coded 
that a few months ago and almost forgot about it.

if u note it down here tonite i will shovel ur words into the cheyenne 
wiki

I need to work on Red this afternoon, I'll do a pass on things to 
add in Cheyenne tonight.

the binary works, the source doesn't...

the source version just gives 404 to everything

can anyone get a login for the cheyenne wiki?


I'd really like to put down my trials and errors of building my own 
cheyenne mod (with handler), so that others may benefit of knowing 
the few little caveats which can make the whole thing fail .... 
maybe do something like a step by step tutorial to begin with.


I'd also like to document all the phases of each internal layer of 
cheyenne (there are many), so that we can more easily navigate the 
code, knowing what we are doing and what other phase is part of each 
type of mod,extension, service, etc.   often, we see just one or 
two parts of a system implemented per module and its hard to get 
the whole picture.   


ironically, looking at the base objects is also hard to do, since 
there is so much "internal" code that it gets REALLY hard to understand 
what is internal, what is "interface" and what is provided as helper 
funcs for your own systems to use.  Add the fact that there are many 
layers sitting over each other, some layers which aren't actually 
layers of code, but layers in the "chain of command" and various 
phases.


now that I've made sense of a *portion* of this, I think I'm well 
placed to start documenting this.   I think that having a complete 
api reference for cheyenne would be really good for adoptance.


It would allow many of us to simply create integrated tools which 
just drop into cheyenne.  (like remark)

~1.5yr ago i backed off from cheyenne because i could build a configuration 
service from the mini webserver on rebol.org. it's just ~60 likes 
of code and handles get only

My main weakness with Cheyenne is the debugging of webapp handlers. 
I simply can't tell what's going on and why they won't run in my 
webapp.

show.cgi: I can't provide a CGI script that would work out of the 
box on all OSes and every possible local configuration, so I've left 
it as-is for users to adapt the shebang line. Using onetom's setup 
script might be the best solution, I'm thinking about integrating 
it in the Cheyenne sources package.

Odd, I don't remember having to fix it before, and I didn't formalise 
it in my build scripts, but thanks

Kaj: fast-rebol-cgi issue fixed in revision 131. If you need a new 
Linux binary, I can build you one (just let me know if you prefer 
a /Pro or /Cmd version).

Pro please, but no hurry. If you can combine it with other changes, 
please do

Ah, wouldn't it be that the shebang line doesn't need to be adapted 
once fast-rebol-cgi is enabled again?

Right, in fast-rebol-cgi mode, the shebang line is not processed.

Also, I might have changed the shebang lines in CGI demo scripts 
to Windows format for local testing without reverting them to UNIX 
format once done.

I think that I'll setup some automated nightly builds, but probably 
only for Linux target as a start. I could later add Windows support 
(I have a Windows box running 24/7), but MacOS will be missing.

if you have all the setup and scripts, I have a mac machine running 
24/7... it could easily grab the lates svn and dump the build where 
you want  :-)

No time tonight to setup the automated builds, will do that tomorrow 
after finishing 8/16-bit support in Red/System.

thx for not disappearing in the depths of ur cave without a word 
;)

my jsondb works with angular now thru cheyenne, btw. no delete though, 
but not a big issue yet.

Ditto. Doc seems to work harder on Cheyenne while taking on Red. 
Maybe we should come up with a third major project for him ;-)

If you can provide me a solution to avoid sleeping, why not. ;-)

I've been working on one, but I still need to debug it. The current 
method causes crankiness

my take on sleep  :  The most useful way to waste time    ;-)

I guess you're forced to that conclusion if you have kids :-)

hehe

I don't even consider it wasted, because I know my brain programs 
on while asleep. At dawn, it will often have worked out yesterday's 
problem. The question is whether the code input of Doc's extra project 
can fit in his waking time

yeah, I know... I have 4 batch cores (which is why I often work as 
quickly on 4 projects as some do on one  :-)

but when the problems are complex, the night sleep doesn't fill up 
the whole time slot.   i.e. the solution is resolved and there is 
still a lot of batch time left.

btw folks, a funded, cheyenne-related project I'm working on has 
been green lit for public release.  I'll be doing a full announcement 
tomorrow on what it is, and possibly even a prototype code release. 
 :-D

give us a hint

a small bone will do

web api

FYI, I'm working on setting up automated Linux builds for Cheyenne.

Automated builds are now up and running (Linux only): http://cheyenne-server.org/download.shtml

I will push some changes tonight to see if it works as expected.

r u generating that download.shtml dynamically?

very nice download pages.  probably one of the most conscice page 
of this kind I've ever been to  :-)

i found the version numbers pretty confusing though and the binaries 
are not sharply separated from the source packages

newcomers have no freaking idea what is pro and what is cmd..

but i don't have any explicit idea how to make it better, so i didn't 
want to complain yet ;D

he actually does give the difference between /pro and /command on 
the page.

but do i need a keyfile to run it? is it legal to run it? if there 
is a version which knows such extra features but still miniscule, 
what's the reason having to separate versions?

I guess there is one title which might be added... 
Nightly builds:


just before "Sources tarballs of latest revision are also available"

compiled versions do not require a key, that is what paying the SDK 
is for.  there is no need to talk about license keys within the binary 
packages... 


there could be another page which lists all the various source license 
and REBOL interpreter requirements though, 
with just a link on this page.  something like:


<a href="rebol-vs-cheyenne-licensing.shtml" >notes about required 
REBOL license and interpreter version requirements for use of source 
versions </a>

(should remove the first "required" in that sentence ;-)

keys are not required to run sdk/command encapped builds