AltME groups: search

Sure, that's a significant improvement for Cheyenne.

I think there's only one issue left, for which I don't see an easy 
solution. If you specify both a user and a separate group, it must 
be in that order in the configuration file, because the group definition 
modifies the boot code that the user definition generates. Reversing 
them gives you the group belonging to the user, instead of the separate 
group

After some serious benchmarking with Redis using a couple of php 
libraries, it's become clear that a Cheyenne + Rebol blocks is by 
far the fastest solution.

I think the main issue with Redis is the I/O between PHP and Redis 
itself.. the only way to access Redis data is via a port.


ie: Apache <-> PHP <-> Redis  .. each I/0 adds precious milliseconds

Cheyenne has an advantage, as Rebol blocks are native.


I must admit, I didn't expect these results. Accesss to data stored 
within Rebol blocks  is crazy fast... and very flexible.

I have  a rebol block with 10 million integers.. i can crawl the 
entire block with a foreach [a b] loop in 0.17 seconds

Now if i can just figure out how to reduce the large block into a 
few smaller blocks, and run parallel foreach loops, it will be a 
killer app.

Terry, if you are able to simulate thousands of users, that would 
be a killer app too.

Well, as Doc pointed out, 1000s of simultaneous users makes for a 
VERY popular website.. take the millions  of $ and work it out as 
necessary.

I'm looking for say 100 users able to work on a very large datasets 
quickly.

Kaj: I keep having big issues starting Cheyenne as not-root user, 
the debug files are created while Cheyenne is stil root...The issue 
is deeper. The UNIX port number <1024 limitation, is a true PIA. 
Does someone know if there's a way for a process not started as root, 
to temporary get root privileges for opening a network socket?

Is there a core version of cheyenne for windows that can run as a 
service without issues?

nvm - i had a rogue apache service firing up on boot.

All the buzz in javascript land of late is around  Node.js and Redis.. 
And I've been in a heated debate with the Redis group over the latency 
issues. Cheyenne + Rocket (a Rebol key/value store I've been working 
on) makes the Node.js + Redis throughput look sick.
Why do these inferior technologies always get the buzz?

I did my own using SSH and a few server-side scripts and tricks.

I can start/restart the server without it requiring to be setup as 
a daemon.

the usual problem is that when you do a remote login, whenever you 
logout, any application you launched gets killed with the session 
when it quits.

Hey Doc.. I can access a websocket page from the interweb, but the 
socket communcations isn't working at all? However, it works fine 
accessing on the local network? Any ideas?

Is there a core version of cheyenne for windows that can run as a 
service without issues?

 AFAIK, encaping Cheyenne with enpro should work ok with Windows XP 
 (not sure for Vista/7).

I can access a websocket page from the interweb, but the socket communcations 
isn't working at all? However, it works fine accessing on the local 
network? Any ideas?

 Is there any HTTP proxy in between? Does it require SSL? Cheyenne 
 current websocket implementation doesn't support HTTPS yet.

good to see pmwiki working .... I hadn't realized before when on 
your site that it was a php wiki!

Seems like a port / FW issue, but not sure why that would be?

can I somehow automatically execute run one file or a pack of code 
before each page load If I am not in webapp? I added do %... to each 
html file now but it's not very elegant.

going to copy the .cache.efs file to cache.efs and then copy it back 
each time with a shell script to see if that fixes it

Also, in the screencast you're starting Cheyenne when it is already 
running, so it may be a legitimate fille locking error

After the first pwd you see that I get a message to say that my process 
was stopped.

I then do a ps aux | grep cheyenne to confirm that it is no longer 
running

Nope. This is a new ubuntu default installation.  I am *presuming* 
cheyenne quits because it can't write the .cache.efs file  but don't 
know for sure

Well, I don't know what is going on but hopefully my saving a copy 
of the .cache.efs file and copying it anew each time the user restarts 
cheyenne will bypass this issue

found the bug. it seems that cheyenne 0.9.17 cannot run with rebol/core 
2.7.7 due to it's inability to make a context from a hash!.

this is in fact a bit odd... I've been running cheyenne on this machine 
for about 18 months without modifications and suddenly it would not 
run unless I changed the 'phases hash to a block in httpd.r.

It should: WebSockets have been in the WebKit development builds 
for a while. So all the other WebKit-based browsers should get it 
soon, too

Hi Terry, it's possible that the ws URL wth port <> 80 returned by 
Cheyenne doesn't match the one expected by the browser to validate 
the ws handshake, let me have a look at it...

from the server, i cant' get a message to on-message .. but from 
the other client, I can.. only it won't reply.

Terry: just replace ws:// by http:// and test the URL from rebol 
console with a READ (from your server box)

(or from a ws-enabled browser from your server box)

The port 80 vs 82 was a guess.

doc, is curecode still under active development ?  Is there a release 
1 on the horizon?

Apple had their chance back in the early 80's.. back then you had 
a choice, forfeit the downpayment on a house and buy a Mac, or get 
a clone.

So, is there going to be a groovy version??

I'm still wondering if I should build my own language (probably REBOL-derivated) 
or dive in a mainstream one...

Looks like Frank did a lot of work on Freebell ..

Freebell is just a proof of concept

(a good working one, Frank did a good job)

Graham: the jvm is just a target like .net or any cpu...

however, still not working from host.. prob a windows 7 hostname 
thing.

sure .. a virtual cpu

or we could start a bounty for rebol on the JVM :)

Graham, without money, it's just not worth it, you need a lot of 
libraries to make a programming language useful, no way one man only 
can build all the required ones...but if it can generate enough incomes, 
you can pay some developers for that.

Graham: sure, but either you build an abstraction layer other each 
java lib (using a scheme or a dialect), or you'll just use these 
libs with the java syntax, so better use java or scala directly.

Graham: without a tight and higher level integration of lower level 
libs, the benefits of a higher language like REBOL will be reduced 
greatly while you'll pay the performance penality.

Terry: interpreted (REBOL) vs compiled (java) language will still 
have a huge performance gap

I have a PHP library that I've been using personally for 5 or 6 years 
now. I'm sure it's of value to someone, but I just can't be bothered 
to market it to the 500  interested individuals

still, I believe that it would be very hard (if even possible) to 
make a jREBOL with performances matching the C version.

Lik e Cocoa.. I've tried looking at that noise a few times now.. 
syntax boggles my mind.. but much of it (iphone apps etc).can be 
done with JS and HTML5..

Sorry, but Moore's law doesn't allow REBOL to be used as a generic 
programming language, due to poor performances compared to compiled 
ones (like C or java). You can't even write a decent compression 
lib in REBOL (would be too slow).

which is why rebol is dying.. it's a dinosaur.. 10 years ago it was 
hot, but the ball was dropped, and ruby took it's place.  Stupid 
license / closed source killed it.

The only thing is for a few folk here who prefer to use it for low 
end development / back office.

So, just call a compression library from the jvm

yes especially on web servers.... the number of users of a site can 
quickly slam moore`s law.

If I write a WP ... it's not computationally expensive ... vs a statistical 
package

REBOL is not even fast enough to write a code editor with syntax 
coloring...a WP is out of reach ;-)

That's a fault with the view implementation

So, what advantages do you see being lost with a port to the JVM 
or .Net ?

doesn't sound like a big loss .. most people I see already have .net 
or the jre already installed

but Graham, I'm not against a jvm and .net port, it would be a good 
thing

well, as I'm not a jvm nor .net fan, I might not be the right person 
for the job ;-)

MS IDEs crash regularly in a typical work session... plus every new 
release, you have to refactor stuff... its just really not nimble.

There was a wish to add a documentation type to curecode

things work fine as long as i use a domain name, but as soon as I 
go localhost:81 or 127.0.0.1:81, it goes south.

hmm, now its working fine everyway.. feel free to completely ignore 
my previous noise, and I'll just pretend it was all a bad dream

is there a ws:// protocol implementation for R2? How do I connect 
to a server and use websocket without a browser?

http://www.whatwg.org/specs/web-socket-protocol/


Doesn't look very difficult .. if you need it, start a bounty for 
it

I had a quick look at the first few pages and it seems to use framing, 
with only one frame type defined at present.

I presume that a web socket "function" will block all of Cheyenne 
until it is completed.

Unless there's a way of handing off to one of the spare cheyenne 
processes

well, I'm planning to make an turn based online game, but not inside 
a browser, client will be a separate rebol application. it will be 
connected to a web socket, and player did somthing it will be sent 
to all other players

I can use cgi aswell but there is no way to detect if a player disconnected.

But yes it blocks the whole Cheyenne process so it should be a very 
small and fast function.

Websocket server code can be run from two places: either in Cheyenne 
main process (allows accessing all clients ports and detecting ports 
open/close events) or in RSP scripts (using 'do-task function from 
a websocket app) when the job takes too much time (like accessing 
a database).

Terry: tested Sensha (Extjs re-branded), looks good but way too slow 
even on a Android with latest hardware (1Ghz CPU)...too bad.

I guess it's only good for desktops with a touch screen, not for 
mobile devices.

So, we could use this to send email instead of RSP script?  Just 
have to upload attachements base 64 encoded still I guess as it is 
still a text protocol

Sounds like I can forgo the sendmail.rsp script which a user might 
damage and just use a web socket instead

Graham: websocket is just an evolution of the HTTP protocol, it's 
not TCP, you can't contact a SMTP server from a browser directly 
if this is what you have in mind.

AJAX will remain in use I guess, having a permanent connection is 
not always required and makes servers less scalable. Websockets will 
mainly replace all COMET tricks for server-side events.

Doc, you have a mail server inside Cheyenne .. .that's what I want 
to use.

Graham: I don't see any advantages in using websockets rather than 
classic requests then? Btw, you can't upload files from a browser 
using websockets AFAIK.

Doc, I have a Rebol app .. that uses Cheyenne as an helper app ... 
so I would be using it from my Rebol app ...

If you're using Cheyenne just as a MTA, better strip it down to just 
UniServe + MTA service, and integrate %Uniserve/libs/email.r in your 
client app.

I also use it as a web server

If a pdf is loaded into a browser .. it allows one to post the data 
in an acrobat form ... but if it is loaded into acrobat reader alone, 
then it can post, but it can't understand any html returned by the 
web server

You could pass a message to C via websockets and have C send it along 
for you.

I use websockets for passing javascript and JSON to a static page. 
 The pages start off with a single javascript function, then i use 
websockets to lazy load.


Here's  pseudo for an email client using Cy (shorting Cheyenne to 
Cy from C.. keep confusing myself)


- Start with a blank page with the websocket function. No HTML, No 
css.. link to Jquery only  .. this page is under 1k

- Send an initial message to Cy with the page name, Cy responds by 
pushing the necessary HTML (simple email form), CSS and JS (a single 
function to send back the form results to Cy) to the DOM

- User fills out form, and submits.. pushing an array (JSON, string.. 
whatever) with the message details to Cy
- Cy sends the message via rebol mail

... but then 


.. Cy polls the users pop mail acount on a regular basis, and upon 
finding a new message, sends <i> sends a javascript function</i> 
to the page, that gets EVAL 'd . This could do some animation in 
a canvas tag, push some message to the browser's chrome.. whatever.
 

All using the same tiny webpage. When you look at the source, you 
see 20 lines of code.

@Graham: you are using web sockets for a wierd job. The shortest 
explanaiton for web socket is: it is the way to trigger an event 
on the client side from the server side via already open tcp (http) 
connection. ofcourse that connection is full duplex, client and server 
both can send a utf8 encoded (currently no binary) string messages 
anytime.

I wonder if this is a way to ask Cheyenne to unload it self ... I 
presume 'quit does not work in RSP scripts

Notification thru websocket port: sure, you can have that, but you'll 
need: a ws client for REBOL, a websocket app and a RSP script for 
that (the websocket app will need a timer to trigger queries on a 
RSP script to get the email status or hack in local MTA data to get 
the info to avoid querying a RSP script).

fyi html5 has a new file api.. 
http://dailyjs.com/2009/11/30/html5-file-api/

also note that at some point,  the word "less" is used directly.... 
 so this skews the results a lot

Maxim, the reason the client-side processing is faster is not because 
of processing overhead, it is because the resulting CSS code is much 
larger than the LESS source code, so it takes longer to transmit 
over a network connection.

Doc, just an update regarding using the browser on the websocket 
host box closing as soon as the websocket connects.. seems to be 
a Google Chrome issue.. Safari 5 is working fine

scratch the word "using" in that last post.
Post posting.. a great time to proofread ;)

To keep Cheyenne on the html5 leading edge, you may want to add a 
"server-sent events" service as well.

uses a text/event-stream mime type

It's basically a one way websocket communication... server -> browser 
 . Not sure what the real advantage would be, perhaps less overhead?