World: r3wp

Very nice Doc!

looks pretty 8-)

Excellent. The graphics look really good.

Cool

If I have a proxy server made in Uniserve, what is the best way to 
join it with Cheyenne?

1) Add you service in %UniServe/services/
2) Edit %Cheyenne/cheyenne.r

3) Add in the 'set-cache block inside the %services/ section, the 
name of your service.
4) In 'do-cheyenne-app function :


- find the line "do-cache %HTTPd.r" and add after that : "do-cache 
%your-service.r"

- find the line "control/start/only 'task-master none" and add after 
that :
    "control/start/only 'your-service-name none"

That way it will work both in source mode and encapped.

I will try it.. thanks.

How much time will you be spending on Cheyenne Doc?

Hard to answer, but as it's propably the most important software 
component for my company, quite a lot I guess.

And where I should add protocol? If I used to start the proxy using:

uniserve/boot/with/no-loop [services [proxy-http] protocols [http]]

I see... do-cache uniserve-path/protocols/HTTP.r

On the web site linked above in the Chunk-encoding section: transferts 
-> transfers

With PHP I often use code like:
<? if(something) { ?>
 normal HTML is here
<? } else { ?>
 something else here
<? } ?>

Don't you miss some way to do such a conditions?

And as I'm now writing RSP I found the RSP's <%%> tag much more difficult 
to write than PHP's <??>

remap your keyboard??

or, remap your keyboard%%

Typo fixed, thanks Brian.

Same in RSP :

<% either something [ %>
    normal HTML is here
<% ][ %>
    something else here
<% ] %>

Just as a reminder for those currently using Cheyenne/RSP, you can 
add the DEBUG keyword in your webapp config section in %httpd.cfg 
to display a menu with useful debugging info.

impressed! 8) I finally gave another try at php support in cheyenne 
and after patching fastcgi.c as suggested it now works like a charm.

If you are on os x and use macports, here is a way to patch and compile:

sudo port install php5 +mysql5 +fastcgi
sudo port uninstall php5
cd /opt/local/var/macports/distfiles/php5/
sudo tar -xjf php-5.2.6.tar.bz2
>> run patch below
tar -cjf php-5.2.6.tar.bz2 php-5.2.6
sudo port install php5 +mysql5 +fastcgi checksum.skip=yes

copy of Dockimbel's patch with path fixed for this example

;---- cut'n paste the following code in REBOL's console ----

patch-php: has [buffer pos][ target: %php-5.2.6/sapi/cgi/fastcgi.c 
if none? attempt [buffer: read target][ print "unable to find the 
file to patch!!" exit ] either parse buffer [ thru "int fcgi_accept_request(" 
to "if (req->fd >= 0) {" pos: to end ][ insert pos "^/^-^-^-^-break;^/^-^-^-^-" 
write target buffer print "patch applied." ][ print "failed to locate 
the line to patch!!" ] ]
patch-php ;---- end of code ----

tar -cjf php-5.2.6.tar.bz2 php-5.2.6
should be:
sudo tar -cjf php-5.2.6.tar.bz2 php-5.2.6

just in case if you want to have macports php5 support mysql 5.1.x,
install this before php5 and php5 will recognise and use it:
sudo port install mysql5-devel +server

Is that just for Mac? I was having some problems with PC

the php source patch is needed only for non WIN platform

btw, belcome back Terry? ;-)

I just installed drupal 6.2 in a snap on Cheyenne, I really love 
the cleaning they have done on the database structure. If only it 
was in rebol...

Yep the patch is for non-Windows only.

OT: Will, do you find Drupal better than Jumla? I downloaded both, 
just haven't tried extensively yet .... from what I saw I found Joomla 
has nice interface :-)

Pekr, forget joomla, that is bloated stuff, drupal is elegant, has 
good community and good documentation. I like the cleaning they have 
done with the database structure in latest version. It looks to me 
they have so much reduced the code a good php/rebol coder could translate 
it in a week.. ;-)

It is just that I found Joomla much more user pleasant :-)

Doc.. have you worked with Erlang?

Will, I only come here to keep an eye on Doc's developments. And 
get sucked into the evolution group simply because I can't resist 
:)
But I've actually found post Rebol life to be very productive.

Erlang, no, I just looked at the language specs and a few examples, 
why ?

It has some features that make it ideal for serving web pages, DB 
access etc... all the stuff that's right up your alley.

Here's a Yaws (Erlang based daemon) vs Apache benchmark.
http://www.sics.se/~joe/apachevsyaws.html

Shows Yaws handling 80,000 parallell connections.

This bench looks a little odd to me. First, how can Yaws supports 
80,000 parallel connections when running on a single server (TCP/IP 
stack limit is at 65535 AFAIK) ? Second, the load is generated by 
sending request byte per byte with a delay of 10s between each bytes 
and getting in response a file of 1 byte...This isn't a web server 
real load test, it just compares the scalability of OS threads vs 
"soft threads". You don't need a benchmark to know which one scales 
better on a mono-CPU server, it's obvious. How Erlang handles multi-core 
CPU ?

Im not that familiar with it.. just looked interesting. 
Amazon uses Erlang for their S3 and SimpleDB products
Apaceh uses it for their CouchDB product.

Although it is possible to take advantage of multi-core technology 
by running several applications processes in parallel, the real benefit 
would be for multi-threaded applications. The challenge then is to 
change single-threaded or sparsely threaded applications into multi-threaded 
and also to debug them.

Erlang has unique properties for taking 
advantage of multi-core technology
One of the fundamental properties 
of the Erlang language is built-in support for very light-weight 
processes, each with its own memory, and using explicit message passing 
for their communication. Because of this most applications written 
in Erlang are realized as a number of cooperating Erlang processes 
representing something in the problem domain of the application, 
for example active call sessions, connections or transactions. Typically 
this will result in many thousands of simultaneously executing processes 
in a heavily loaded application.

The parallelism already present 
in most Erlang applications makes them ideal for taking advantage 
of multi-core technology, without there being any need to modify 
them.

The only thing needed is an Erlang virtual machine (VM) which 
works in a multi-threaded way, and that is what we now are releasing 
in Erlang/OTP R11B.

Yep, cooperative multitasking built-in. Maybe we'll get that in R4 
;-)

Cheyenne, with its mono-thread full async engine, would scale very 
well on a similar benchmark, probably much better than Apache, but 
less than Yaws I guess. OTOH, a bench testing raw throughput, would 
show Apache performing quite better than Cheyenne (maybe 2 or 3 times 
better). It's hard for interpreted REBOL to compete with compiled 
C on raw power. I think that it would be possible to reduce this 
difference to 1.5 with deep optimization in Cheyenne (task scheduled 
for v1.1 according to my roadmap). R3 should open new perspectives 
for speed & memory optimizations (threading, clean async kernel, 
optimized ports, Rebcode, plugins...).

Erlang has a lot going for it, but it has its own set of issues as 
well. Maarten recently spent some time evaluating it quite deeply 
for me. At this point, we're sticking with REBOL.

It is *very* attractive, all the stuff you get basically for free, 
in the context of building distributed systems.

Interesting Gregg, could you say more on what pros and cons made 
you take the decision?

Where's the whitepaper?  :)

Never noticed this before.. seems someone was considering using Rebol 
as the GUI for Erlang
http://erlbol.dougedmunds.com/

Interesting :-)

Was? That's a new project :)

A good starting point for doc links is http://www.erlang.org/doc.html
.


The pros are that it's been around for a long time, it was built 
to solve a specific type of problem, and has been proven to work 
for large commercial systems. It also has a nice community it seems. 


Just as C# and VB.net are capable languages, you really need to know 
the .NET framework to make things sing. Erlang, by itself, is very 
capable, but the OTP (Open Telecom Platform) provides a huge amount 
of value on top of it, if you're building distributed systems. It 
also has Yaws, Ejabberd, and other things already built that you 
can leverage.


On the downside, it's a very different model that takes some getting 
used to, though Maarten got up to speed for experimentation very 
quickly. If you're used to Prolog, that will help. It's also really 
only good for back end stuff, so we would still be doing front ends 
in something else, which wasn't the dealbreaker in our case. What 
turned us away was the security model. It's designed for use in an 
intranet type (read safe) environment, where access to machines on 
the cluster is controlled by secret cookie. If your cookie is compromised, 
they have absolute power over the node, and any nodes it shares that 
cookie with.  http://www.erlang.org/doc/reference_manual/distributed.html#11.7


We decided that, since we would end up building security on top of 
everything, using something like dialects for control, we were better 
off sticking with REBOL. There are a number of things out there already 
to bulid on (LNS, Rugby, Uniserve, BEER), we can really do things 
the way we want, in a tool we know we like and are comfortable with. 
And we know its limitations, so there will be fewer surprises.

Hi Gregg,  which is the project you're talking about  ?

Doc, the 64K limit is the limit on the number of server ports but 
not the number of connections that can be open to a single port like 
port 80