AltME groups: search

All I'm doing is editing RSP pages, and running them.

Nicholas "Hi, I'm new to cheyenne. I've tried http://localhost/
and I get the message It works!. But I can't view my site.  How can 
I ? Any tips?"

Are there any issues with an rsp script executing scripts in the 
Cheyenne directory?  As opposed to www and below?  I get these odd 
error messages where the script can't access them due to protected-exec

An update on my web fax portal.  http://screencast.com/t/1n1HgxKH8

When I click on a fax, it gets converted to PNG and then the Rebol 
plugin in invoked.  I bring up a new window outside of the browser 
window and display the fax.

Haven't figured out how to invert or rotate the image in place yet, 
so just bring up a new window with the rotated image.

You can change it in settings and or code. I think.

do to-file "../../config.r" should have worked
and even when I changed it to absolute path
do to-file "/opt/fgw/Cheyenne/config.r"
i still had problems.

It was very odd ...sometimes it would suddenly start to work even 
though I did not change anything, and then it would stop working.

Guess what, clients started getting timeouts because it seems that 
Cheyenne wasn't fast enough to process all events and find enough 
time to accept new incoming connections (this also had the bad consequence 
of halting Cheyenne due to an uncatched timeout error).

I take it this is fixed in next version?


Also, what are the mechanics around the connections.. at 1000 it 
just maxed out CPU or rejected connections? or ?

Same behaviour with v0.9.18 and v0.9.19 ?

ok, so it looks like an issue with the DO mezz and the new sandboxing 
system.

sometimes even

do %/opt/fgw/Cheyenne/config.r

doesn't work consistently

so I have to 

f: read sometimes even

do %/opt/fgw/Cheyenne/config.r

doesn't work consistently

so I have to 

f: read  sometimes even

do %/opt/fgw/Cheyenne/config.r

doesn't work consistently

so I have to 

f: read %/opt/fgw/Cheyenne/config.r

and then

do f

What prompted the changes in sandboxing and the do mezzanine?

As long as you run only one webapp on Cheyenne, no problem, but I 
ran a dozen apps on some of our servers and I was facing several 
cases of name clashing.

Not sure that it can work with the current version. Cheyenne is using 
READ to get static and RSP files,  I have to change that to use the 
virtual file system in memory.

I thought about doing that once, then I found that it requires some 
redesign work first on the virtual file system (%encap-fs.r) and 
also being sure that it won't affect performances when reading files 
from the filesystem in normal usage. I've planned to work on such 
feature for v1.0.

Doc.. Im just thinking scalability / benchmarking.  I plan on spending 
my spare time over the next number of months building a next gen 
webserver using Cheyenne as the core, and I want to make sure I don't 
hit a game killer 3 months in.


i posted earlier in the Rockstar group how superior Cheyenne is compared 
to vhosts and .htaccess.. night and day.

Suppose I implement the rest-mod, I want it be stateless so no cookies. 
 I want to pass the userid and password each time.  So, with no cookies, 
the user won't have access to the webapp.  So, does this mean I can't 
use a webapp with rest-mod?

and I need to re- RTM

Henrik, I've had some issues with relative paths and 'do ... in Cheyenne 
'do is a mezzainine with different bindings.

From v0.9.19, using 'do would by default bind your loaded code to 
the webapp context (and not to the global context). Btw, if you're 
using an external INCLUDE function, it may clash with RSP's global 
INCLUDE function.

/posted: thanks for the reminder, that's right, it can be binary! 
or string!. It looks like the file upload support could be cleaner 
and easier to use from RSP. Will give it some thoughts.

/posted caught me ... i keep getting image errors when writing the 
/posted to a file and then trying to view it with img src!

Maybe you can catch TAB keypress event with javascript and inject 
spaces in textarea ?

I tried that ... and got some error.

<script type="text/javascript" >
function tab_to_tab(e,el) {

    //A function to capture a tab keypress in a textarea and insert 4 
    spaces and NOT change focus.

    //9 is the tab key, except maybe it's 25 in Safari? oh well for them 
    ...
    if(e.keyCode==9){

        var oldscroll = el.scrollTop; //So the scroll won't move after a 
        tabbing

        e.returnValue=false;  //This doesn't seem to help anything, maybe 
        it helps for IE
        //Check if we're in a firefox deal
      	if (el.setSelectionRange) {
      	    var pos_to_leave_caret=el.selectionStart+4;
      	    //Put in the tab

          el.value = el.value.substring(0,el.selectionStart) + '    ' + el.value.substring(el.selectionEnd,el.value.length);

            //There's no easy way to have the focus stay in the textarea, below 
            seems to work though

            setTimeout("var t=document.getElementById('code1'); t.focus(); t.setSelectionRange(" 
            + pos_to_leave_caret + ", " + pos_to_leave_caret + ");", 0);
      	}
      	//Handle IE
      	else {
      		// IE code, pretty simple really
      		document.selection.createRange().text='    ';
      	}
        el.scrollTop = oldscroll; //put back the scroll
    }
}
</script>

my cut and paste javascript function!

As I understand it, modules implemented the task-master API.  But 
now you have mods instead of modules, and instead of install-module, 
you have install-HTTPd-extension

So, mods are able to process the various phases as described in cheyennes 
processing pipeliine. Each module can decide whether to process a 
phase, do nothing, and /or prevent another mod from processing that 
phase.

So, I guess mod-static is processing url-translate first ... and 
I need to change this to 

url-translate normal

It give up on processing the request and pass it to other mods.

If you use a url like

http://user:[password-:-localhost]/


where is the user and password captured?  I see the browsers FF and 
Chrome immediately remove the userid/password from the address bar. 
 IE complains that it's not a valid site

and it's been removed already from req/in/url

And I see my problem ... I was looking for header information in 
url-translate prior to the headers being parsed which is why I couldn't 
see that information.

Well, I made only a few changes and got this far

http://rebol.wik.is/Cheyenne/Mod-rest

I'm creating an API, and each api word maps to a single rsp page 
inside a %rest directory.  It is up to the rsp page to decide which 
actual function is being called, and to deal with all the parameters.

And also to deal with authentication.  Basic authentication will 
be used for each api call .. and the whole site will be behind https.

so, DELETE /@api/fax/jobno and GET /@api/fax/jobno both map to the 
same rsp page.

So, in summary I need this code both in app-init.r and in my login.rsp

Looks like I'm going to have a very few pages as entry points to 
the application ... and so all the code will only be in a few pages.

And i've never done PHP etc

What exactly is the difference between 'do and '*do ?

and if you're not using a webapp?

That's why I was calling since the beginning of R3, for a focus on 
R3 Core features first, to be able to port our R2 code to R3 and 
benefit from modules (and other vital features like plugins). We 
reached PITS limits a long time ago.

Uses RSP, and I think it can use some of Cheyenne's features too...

I usually kill it here and start it again. For those times where 
it mysteriously just quits, I can also just start it again. I have 
mine set up via launchd in OSX.

My quit as well... but i didn't see this message.  So I used 'kill 
to kill the pid and restarted it :(

Graham, mine just quits. I can go in and start it again without problems.

If you can access to the server through rconsole just do this : write 
%debug.log mold uniserve (and put the compressed version of the %debug.log 
file on your web site so I can download it).

I take it that this is a new bug .. I'm still running a much older 
version of Cheyenne from last year ... and I never saw this.

And mine .. do you know if anyone is having my problems?

I will ask my friend if he has the same issues ... he's running the 
same code and has not mentioned any problems

You could put a couple of debug lines around your call/wait and log 
them to a file to see if your CALL always returns.

I think I could improve such issues with a timeout on RSP script 
execution in the main process (and returning an error message if 
a time limit is reached).

no, it's not the same process and helper processes where RSP scripts 
are executed, don't load Uniserve code. They just use a small client 
(%task-handler.r).

still up ( 1 week now ) and rsp still working ...

I've noticed sometimes that when an error happens, the output buffer 
is somehow not cleared and any further output will just be appended 
to that buffer.

Right, Cheyenne still has issues with PHP FastCGI reconnection process. 
In FastCGI mode, after a given number of requests (500 here), PHP 
processes kill themselves and are relaunched. This is required by 
PHP to handle memory leaking problems.

It seems that sometimes the FastCGI TCP connection remains in half-closed 
state after a PHP process dies, and my detection method is not efficient 
enough.

Reminds me of when I installed Novel Netware some thirteen years 
ago and read in the manual that you were advised to restart the server 
every day to reclaim fragmented memory...

The Dutch website of Software Freedom Day is now running on Syllable 
Server and Cheyenne:

I downloaded the Cheyenne source. Started the Cheyenne.r. Should 
I be able to connect via a web browser and localhost? I get Internet 
Explorer cannot display the webpage. I looked on the website for 
setup/config documents, but the document section just seems to time 
out. Is there any other service I need to start or should it be straight 
forward? I am on winxp, internet explorer.

It's straight forward and you should see the default test page. If 
not, check your %httpd.cfg config file. They're no general documentation 
available yet, only RSP API is documented.

I have done the same just yesterday and it works (almost 404 page, 
if nothing else is define).

But this morning it does not work anymore !!

After some checking, I have shutdown Skype and now it works again 
(I remembering that it was off yesterday at my first try). Skype 
may use the port 80, so Cheyenne can't !

Check listening port with "netstat -a -b" in a Windows XP command 
window and search for an application listening on the local address 
"mycomputername:http"

Apart not having doc to set the httpd.cfg correctly, I have one small 
problem.

I use it to test RebelBB localy and it seems POST request does not 
work. I had to change to the GET method to have it working.
Any idea ?

And I'm unable to see the documentation on the Cheyenne website (wiki). 
I only have a neverending "wait for cheyenne-server.org" that finnaly 
ends long time after with a blank page.

404 page : yes, Skype, among other applications, reserves port 80 
for its own use, so you have to shutdown any such program before 
being able to use Cheyenne (or any other web server on port 80). 
Once Cheyenne is started, you can launch again Skype and it will 
use another port (that should be configurable somewhere in Skype).

You can also choose to run Cheyenne on another port, just look in 
the default %httpd.cfg file and uncomment the LISTEN option in the 
'globals section.

Thanks DideC. I disabled Skype and Violla! Everything is working.

Cheyenne locked up ( RSP ).

Logged into rconsole.r and tried the write %debug.log mold uniserve 
but nothing written.

Quit and tried to login to rconsole.r again, but now just hangs.

What I was doing ... I had FF in one RSP session.  Then tried to 
access the same webapp using IE ... and that seemed to cause the 
problem.

sudo rebol
and then do %rconsole.r
and there was no error when I tried to write the log file.

Cheyenne is still running, but RSP is not.  Going to kill the chyenne 
process now as I need this server up and running.

A possible explanation is : your RSP processes are freezing because 
of a file access issue. The main process  wait for the RSP process 
to finish and launch a new one for new request. Once the max number 
of processes is reached, your server is no more able to execute RSP 
requests.

I have a log which notes when I call an external app, and when I 
return.  There's no problem there so it's not 'call.

As I mentioned, it seems to crash usually when I have IE and FF both 
accessing the webapp

and faxstat
http://compkarori.no-ip.biz:8001/debug.txt

but all you need is the cheyenne distro, and rebol.

have Cheyenne ... and each person runs their own vhosts

All my stuff is hosted on http://www.webarama.com.au/and they've 
been pretty amenable to my other requests. Is it just a case of getting 
them to "install" REBOL for me much as Perl is? If so, which version 
of REBOL do I need? Can I get away with /base?

core ... and just place it in /bin directory

Also, Linode provides more RAM and disk space for the same price, 
and in my experience has somewhat better performance.

Kaj can you describe the benefit. I have seen a few sites that are 
for ORM and others against.

They're both technologies with too much overhead, and mapping one 
to the other makes it worse

Abstracting data access is useful in many cases, though. For one 
thing, you could switch between a light-weight, native REBOL implementation 
and a heavier implementation using some other technology such as 
a relational or object-relational database

I WIll look into it.  Now the question I am trying to come to grips 
with the whole abstraction of tables vs hiting services to query 
the database directly and return the data. Anyone care to weigh in?

N-Tier I get. Presnetation layer, App Logic, Database Layer. This 
ORM is another layer between the app logic and database and was wondering 
if you lose flexibility and performance. Is the real gain in crud 
style applications because I don't think I would want another layer 
in a BI/Reporting application.

I simplified the RSP Page to:

<% 
	response/set-header 'Content-Type "image/png"
	prin read/binary %temp.png
	response/end
%>


and now the browser says, "The image 'http://localhost/png.rsp'cannot 
be displayed, because it contains errors" but the previous example 
of LOADing the url twice displays the image correctly in REBOL.  
There must be another content header I need to set...  Researching...

You're right, that's an error in the example code, PRIN cannot work 
here because it will output the binary! in its molded form (with 
#{...}) and not only the raw data. Setting directly the buffer is 
the right way to send binary data (and RESET is not required in that 
case).


Online documentation fixed (RESET example changed to output a text 
content instead of binary).

For some reason Cheyenne is eating up GBs of RAM.  Once it crashed 
saying something about not enough memory (it was using 900+ MB)  
I restarted the server and it works fine except that I have seen 
it use up to 1.5GBs of RAM.  Windows Task Manager (on Vista) baseline 
RAM usage is 500MB, however, after I killed the process using 1.5GB 
Task Manager claims that only 300MB of RAM is used but it still says 
that 1.5GB of RAM is cached and says I have 7MB RAM free.  I have 
2GB physical RAM.   The problem may also be Ashley's SQLlite driver 
as I am using that to manage some images.

I saw such issue in Cheyenne a few times with an older REBOL version 
(2.5.xx) and it was caused by a REBOL GC bug. Never saw such behaviour 
since then.

Heh...  A more effecient design goes a long way.  I've minimized 
requests to the server and dropped the memory usage by about 75%


Speaking of minimized requests...  Has anyone done any AJAX/JSON 
stuff with Cheyenne?

Can you elaborate or point me to something somewhere that demonstrates 
how you did it?  I'm being lazy and I don't want to figure it out 
on my own. ;-)

I also installed the yahoo javascript libraries ... and they're using 
Ajax ... and it's all being served by cheyenne

I know what AJAX is.  ;-)  I've used it many times, I've just never 
set up the server side before.  I am planning on using the json.r 
script from the Library...  I'll just play with it and see what I 
come up with...

feature request: add on-global-page-start and on-global-page-end, 
same as on-page-start and on-page-end but executed for all rsp pages, 
not only for webapps

Has anyone written Atom or RSS output code in RSP? I am going to 
need to do so right away and every possible speedup helps.

Fast, super simple. Not the cheapest, but you definetely get what 
you pay for (which is very good, in their case). They also have good 
docs and wikis - that's an example for many services!

What's the minimum you need to run Cheyenne?  the encapped binary 
and what else?