AltME groups: search

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

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  :-)

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

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

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..

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

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>

ok, so I promised a little announcement about work I have been doing 
in/with/for cheyenne...

I have built a web service module (mod) for cheyenne.
  -----------------------
  features/highlights
  -----------------------

   * extremely fine tuned to cause the least cpu hit on the server process 
   since ALL processing is done in worker processes.

   * it uses an arbitrary number of rebol script files which you assign 
   to any host in the config file. (even the default)

   * once assigned, these files are compiled dynamically (as one app) 
   by the mod and are exposed via http by the server.

   * only the functions you *chose* are *ever* visible on the web, allowing 
   you to include support libs, data and function right in your server-side 
   api.

   * no direct execution of code occurs, *ever* from the client to the 
   server, all input is marshaled, and parameters are typed to your 
   function specs.

   * allows ANY type of web api to be delivered, from REST to SOAP like 
   interfaces.

   * output is programmable, so that you can output AS  json, xml, html, 
   txt, etc.

   * interface is also programmable, so that you can provide GET params, 
   POST forms, POST (XML, JSON, REBOL native data)

   * Automatic API documentation via source scanning and function help 
   strings .  there will also be some form of comments which will be 
   used by documentation.

   * No suport for sessions. this is part of your application layer, 
   which should use https and session keys in the submitted data, if 
   you require it.

   * it takes litterally 5 minutes to convert your internal rebol code 
   into web services which obey internet standards.

   * System is auto-reconfiguring... i.e.  you don't need to close cheyenne 
   to update the service, just restart the workers.

so, when will this be available?


*very soon*  I am building my first test release for my client tonight.


most of the research and prototyping is done, I already did some 
client demos for the people who are funding this project and I'm 
now in the "delivery" phase.


The most complicated parts of the system are already working (i.e. 
handler processes, dynamic compilation, automatic api interface building, 
per-host api/config, request/response chain of command, multi-format 
output, and more.)

a lot of details are still "up in the air" as far as implementation 
goes, so if you really have a need for this, PLEASE STAND UP and 
raise your voice.  tell me what you need, how you want it to work, 
etc.

so far I plan to deliver the first release with: 

  support 4 interfaces for calling : GET url, POST XML, POST Form data, 
  POST JSON.

  support 4 output formats : XML, HTML, JSON, TXT (which is in fact 
  rebol native data)


obviously this will be an ongoing project and anyone who is interested 
in helping out is welcomed to do so.  :-)

Interesting ... I just Cheyenne for pure http and don't serve other 
web services yet

and it creates the soap services for me :)

actually, you just provide the code and the WSDL would be built for 
you :-)

yeah, but you still have to put the code behind.   the web-api mod, 
provides an interface automatically based on what is actually being 
served.  you could easily build a little WSDL to REBOL api file converter. 
 just load the XML, extract the methods, the parameters and build 
an equivalent rebol function stub.


Then all you'd have to do is implement the function body....  the 
only detail is the xml datatype which don't all map 1:1 within rebol, 
but that can usually be pretty well cornered within the code itself.

anyhow... for now SOAP is a larger beast to tackle and I'm more concerned 
with REST stuff right now, but since the system will be working and 
you can easily extend it, there is nothing stopping you from building 
the SOAP interface.

For autostarting (and shutting down) you have to hook into the init 
scripts, which are very different between Linux distributions. I 
remember having trouble with finding a straightforward way on Ubuntu, 
too

I still need to add some documentation to the wiki for .r file handling 
in RSP context and to mention the new cgi-conf script (from onetom).

what does Database C drivers: MySQL 3,Oracle 8 ... mean, btw?
it doesnt work with mysql 5 and ora 10?

Those drivers are built in REBOL/Command. It depends if Mysql 5 and 
Oracle 10 servers are compatible with older drivers. I can only answer 
for Mysql, and the answer is no.

Not everybody run on Mysql 5 and Oracle 10, so it can be useful to 
some users. Also it's all or nothing, I cannot chose which native 
feature I want to include or not.

The ODBC driver and the SSL support are worth it.

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

it turns out it was a different problem... he was running core.  
 but the proper way of loading libs (and I've had to do it to make 
it work on 64 bit systems)

I was using the simple setup you are using and it woudn't work in 
all people's windows system... the above does work in all windows 
machines.

Also, IIRC, that is the first time someone mentions such issue, and 
I am pretty sure that several peoples here already tried it on 64-bit 
Windows.

yeah, it should but it doesn't it seems  ...  the code resulted from 
feedback when I shared the windows-chrono.r lib on rebol.org and 
a user reported failing lib loading.

as well as all sources and docs as a .zip which simply appens to 
the cheyenne folders.

the module handler is pretty fast, considering, we are using external 
code and user hooks to setup the process.

calling this url on my meagre 1.5core2 duo
	http://localhost:81/echo.xml?value=tadam

returns this xml


<result status="success" method="echo" time-delta="0:00:00.000723302" 
phase="format-response">
    <echo value="tadam"/>
</result>

wrt api server speed  adding up all the required cheyenne server 
handling and tcp xfer we get:


>> s: chrono-time    read http://localhost:81/echo.xml?value=tadam 
     difference chrono-time s
connecting to: localhost
== 0:00:00.010442948

doc, in req/out   I have   both a value called   mime:   and   mime-type: 
   it seems that within mod phases, we are supposed to set   mime: 
   to a lit-path   ....


why is this so?  wouldn't it be simpler to have just one and set 
it as a string directly, to be used in the header construction after?

oh... looked at it again... my bad... I'm returning mime-type: in 
my response and the probe was really confusingly showing it as if 
the mime-type: was in the same object as the req object.

for those who might be using dividers and don't look at all the groups, 
I posted the release of mod-web-api in the announce group, yesterday.

well, you can still have a gui, but all it needs to do is build URLs 
and confirm the results  :-)

ah, it goes into the crashlog if a module is not found.

im not sure how would it be the best but it's freaking hard to debug 
like this.

1, i won't know the names of the chey-pid-*.log files and there are 
multiple of them, so i can't easily tail -F them

2, trace and crash logs are created where the cheyenne executable 
or rebol source is located. -- that place usually not writable and 
it's somewhere else, not where the application is.

3, i won't know what is logged where unless i check all of these 
logs -- i could imagine a non-daemonizing mode where every fucking 
things is just dumped onto the stderr

i mean, i can't know it in advance. now im running cheyenne with 
-w 1 and having a look at the log with less *pid*log

I wonder why you guys are make things harder by trying to debug your 
apps under production conditions? 


Why don't you make a local development setup using Cheyenne from 
sources, lauching it from a console in verbose mode to have a direct 
look at everything that could go wrong. The only log file I need 
to look at during Cheyenne development is %trace.log file (and even 
this one is accessible from your browser in RSP 'debug mode...).

im writing a json webservice and actually it's very annoying when 
i get a RSP error html page, instead of the usual rebol error.

i have a global debug option just as a per-vhost one and im starting 
cheyenne w -vvv beside -w 1

im writing a json webservice and actually it's very annoying when 
i get a RSP error html page, instead of the usual rebol error.
 


debug/off should fix that: http://cheyenne-server.org/docs/rsp-api.html#def-65

I don't care about Cheyenne while coding RSP scripts or webapps, 
*but*, I always launch it in source mode (and never as a binary) 
on my local development box. That way, when something odd happens, 
I just have a look at the REBOL console and scroll up until I see 
what happened (so I never need to look at any %chey-pid* or %crash.log 
during development).

aha. and we can't start the binary in a similar mode, where the errors 
are not caught and logged, but showed in the console instead? (im 
trying to do a do %cheyenne.r now)

The Cheyenne binary version is meant for production, so all things 
are logged in files. If you want to have them in a REBOL console 
from the binary, you need to build a custom binary and change the 
encap options in the %cheyenne.r header. Removing the 'no-window 
option will redirect all logs (except %trace.log) to a REBOL console.

which means im not supposed to hack cheyenne (easily) unless i buy 
the SDK and learn encap?

because in turn that's what it means not to include this specific 
"trick" into cheyenne's documentation

and since im running it with the plain rebol/core, i wouldn't have 
thought that encap header might be relevant

Declaring a vhost using an IP address: yes and it is documented in 
the wiki.

onetom: thanks for reporting the cause, I will test that locally 
and see if I can improve the error message for such cases.

hmm... cheyenne binary and the source works differently w the same 
configfile.
$ cheyenne --version
0.9.20.129
WORKS
latest source doesn't work with the following config:

modules [ internal extapp static action rsp alias ]
globals [ listen [8080]    bind RSP to [ .r ] ]
guan-huat [ debug root-dir %./ alias "/docs" %jsondb/to-json.r ]

im testing w $ curl http://guan-huat:8080/docs/test/1

Hmm, shouldn't make much differences between revision 129 and latest 
135...

http://piratepad.net/KkvkZ9AtME
i put the correct and the incorrect logs here

it works if i copy over my stuff into cheyenne's dir and start cheyenne.r 
from there

i can't find the "switch" :) ... i hate this cert and crl based pki 
crap...

doc, I've been able to add a config for the worker count (min/max) 
within the httpd.cfg file.  it took some doing and a lot of file 
navigation to under the deep secrets of cheyenne's startup processs 
 ;-)

I thought it would have been easy, but it took a bit of doing, since 
the boot process must  *init*  the httpd.r, then setup the config 
and then init the rest.


I could have made it ugly by calling things manually or restarting 
workers, etc... but I ended up adding 2 new options to the uniserve/boot 
spec.


init and no-init which allow us to select what is initialized, without 
knowing the full list of services.

Most comments are lies. They don't start out to be lies, but gradually 
the get out of date. You might say that developers should be disciplined 
enough to maintain the comments; but this is not reasonable. Comments 
have no detectable binding to what they describe. If you modify a 
function, you have no way of knowing that 1000 lines above you (or 
perhaps in a different file) there is a comment that contradicts 
what you are doing). So comments slowly degrade and turn into misinformation.

 -- http://www.coderanch.com/t/131147/Agile/Clean-Code-Handbook-Agile-Software

u just demonstrated this principle very well ;)

That's an interesting viewpoint. He starts his post with:


I think it would be better if the code were not complex. I think 
it would be better if the code was understandable at a glance. I 
think the effort of writing a comment for complex code is misplaced. 
The effort should be expended on making the code simpler and easier 
to understand.


And we can add: produce the code using a language, that's easy to 
read and understand.

Max: I am very busy today, I am not sure I will have time to review 
your code now (you should send me a copy of the changed files first 
BTW). As you could see, supporting such feature at the config file 
level is complex because of config file being loaded only when HTTPd 
service starts (for historical reasons). I am not sure that initializing 
the HTTPd service ahead is a clean solution (the boot/ line has become 
a bit hard to read with this /no-start flag that loads and init HTTPd 
service...).


The solution I had in mind was to extract the whole config file loading 
from %HTTPd.r and put it in %cheyenne.r. This is a deep and complex 
change, that is why I was waiting to have enough time to do it in 
a single working session. Anyway, I will examine your solution first.

how can i define a common layout for my webpages? should i split 
the layout into header and footer and use include explicitely on 
each page?

or make it a webapp and wrap the buffer in the on-page-end event?

ehh... sessions are not lazily created either... and i couldn't even 
set-header 'set-cookie none session/end because it sends down 2 cookies 
then...

It depends on the definition, but that's the direction I'm moving 
in. The structure is roughly MVC, and I have a method of updating 
web pages without the browser having to know what it means

Try REBOL is the first dynamic site I've done that way. You stay 
on the same page, send in data to a service interface and get data 
back that updates arbitrary parts of the page

So you get conceptually the same effect as AngularJS, but it goes 
through the server. One of my goals is to maximise the REBOL part 
and minimise the JS part. AngularJS pulls everything in the client 
and is thus tied to JS and the browser incompatibilities that go 
with that

Obviously it's nice to be independent from the server - if you can 
get it to work cross-browser. But I always thought we have View for 
that. Also, it seems nice to have the browser do input checking, 
but if you want a robust app, you will have to get the server to 
guard its own consistency and end up writing all input checking twice

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 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)

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

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?

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 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

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?

Cool, and refreshed when modified?

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

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

sure, and then u overwrite it

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

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

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... :/

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.

I should go back and see if this new build fixes the issues I've 
had

I have mutiple users using a web app on different ports.  Each has 
their own vhost, and their own pages but to keep things simple, each 
web app is the same.  I include a config file each time a rsp page 
is loaded with the db definition instead of in the app-init.r where 
it did not work

Also, could you run Cheyenne in verbose mode (-vvvv) and check the 
boot logs for any error message?

The only cause of the error you've reported above, is that something 
unexpected happened when trying to access and parse %/etc/passwd 
and %/etc/group. Anything special with these files on your system 
(compared to e.g., Ubuntu)?

One difference is that the root user and group are called "system", 
but I didn't find a problem with that in my Cheyenne patch a year 
ago

Could you extract the mod-userdir/get-id function and try to run 
it from a REBOL console using:

    col: #":"
    get-id "www"

Ok, I think it is not needed anymore. It seems that the set-gid call 
is failing on your system for group "www". Set-gid returns a logic! 
or none! value if running on a 2.7.8 kernel and an integer! for previous 
kernels (due to different mappings), that is what's causing the error.

the funny thing is im trying to "debug" from the command line and 
i have to login to the app 1st but if the debug flag is on, im getting 
back and error page and multiple session cookies

so it's worth learning.

i was a wget user earlier, but since macs come w curl and i can easily 
apt-get install curl and even syllable comes w curl, i don't give 
a fuck anymore how an inefficient bloatware is curl, im still trying 
to use it and only it :)

u know if rebol would come w a nicer header dump, cookie, https and 
url encode/decode support by default, i would advocate it as a curl 
replacement probably... :/

maybe an extension script would be enough, which anyone can remember, 
like http://json.org/json.r

btw, let me micro-interview you here: why the hell are u still using 
windows!? especially for development? :)


I consider that GUI are an improvement over CLI that make my life 
easier and computers simpler and more fun to use. I stick with Windows 
as my main platform because I never got used to Mac OS UI (tried 
for a few weeks, but gave up rapidly) and I found the other UNIX 
GUI less "efficient" than Windows. Also I found Windows to be quite 
transparent for my work, it just doesn't get in my way as other OSes 
tend to do, so I can focus on my work and forgot about the rest (especially 
since Vista days, I am now a very happy Seven user).


I must also add that I was an Amiga and BeOS user for more than a 
decade and spent all my college days on AIX, X-Windows and SunOS.

:) thanks. interesting.

i was doing DOS, TurboVision, then tried Win3.0. used Turbo Pascal 
in 2 dos windows under Win3.1, programmed serial equipement with 
Delphi 1.0 under Win95, but then i just fell in love w the fvwm2 
theme of icewm and the big virtual desktop which even worked on trident 
8900 isa cards, using suse linux. i was forced using windows until 
the xp version and i even saw delphi 4.0.

no windows interface can compete with icewm with autofocus and saying 
this as someone who still can handle windows without a mouse faster 
than anyone else i know.

i found vista and win7 particularly disgusting. those dim windows 
w huge decorations just make me annoyed.
im the fullscreen terminal window in black&green kinda guy :)

i want console in web browsers too. i think lisp machines were great 
examples that how the character based interface can benefit from 
graphical capabilities.

plan9's acme is also a nice example; although i never had the chance 
to use it for anything real. never really seen an expert using it 
either...

btw, this is how im listening to netradio rightnow:
$ mplayer http://lounge-radio.com/listen128.m3u

and the good thing is, i could do the very same under windows, while 
i had my windows netbook

hmm.. cookies are accumlating again... Cookie: RSPSID=GWKAQXFYMANHFHNXLXXKVVWL; 
RSPSID=VDWMLITKUVGDAFQBHJHHCQDH

but the app still works. am i confusing it somehow, by restarting 
cheyenne... but im closing the tab and reopening it too...

The encapped version of Cheyenne needs to be started from the directory 
of the configuration file in order to find it. Then it produces its 
log files also in that directory. This is both against the structure 
of Unix and modern Windows systems