AltME groups: search

Ok, I have always set my mouse to the fastes movement possible on 
the system. I don't use a scroll-wheel, I just click the arrows to 
either go line-by-line or posting-by-posting (which I would prefer). 
But, as Chris stated, clicking ones, pages more than one page up/down, 
so I'm missing postings. Workaround: Dragging the slider, which is 
a mess with this mouse speed and the number of messages (IIRC 1500) 
I display.

I just did some speed tests.  Seems about the same.  Even though 
it should be unrealted, do you still have your message count set 
to 100?

Of note, AltME seems to be the same speed, and Qtask should be about 
20% faster, and will continue getting faster.

Regarding async speed: I posted a note in the async group to look 
at that closer.

I'm not sure it's a good idea to not allow 0-sized faces. Is it a 
speed improvement that makes things so much faster ? The user code 
must HIDE the face instead of sizing it to zero, but HIDE may have 
other unintended side effects that are hard to workaround. eg. time 
events are stopped by HIDE:

A time function to measure the speed of code:

time: func [:f /local t0] [t0: now/time/precise do f now/time/precise 
- t0]

Now you can do e.g.:
time [loop 40000 [
xx: [ ["a" 11 #toto] ["b" 28 #titi] ["c" 3 #pim] ]
x: copy []
loop length? xx [insert tail x xx/1 xx: next xx]
]]

once again we are here to ask ourselves, if open-source would not 
speed-up things significantly ...

speed is not RT's priority, but ensuring a successful company is.

www.rebol.com/speed.r

I want to change the color, I want to be sure how to find it, set 
it, etc...and review the know problems...get up to speed.

Graham, I agree with BrianH. It should speed up your parse, and make 
it easier to read because you can use TO and THRU again.
	caret: #"^^"
etc

Anton, I used to use a character rather than a string too, because 
of the memory issue. But it turned out to be slower that way. I think 
parse only matches on strings, and single characters have to be converted 
to one-character strings before they can be passed to the matcher. 
At least that would explain the speed discrepancy.

my current app is so threaded because of the async core that its 
impressed everyone at the office... I can be scrolling a list view, 
reading files doing sql queries and reading directory lists which 
buildup view menus in real time... everything is fluding and strangely, 
having sql and a loop browsing through several hundred directories 
scanning their content is almost unnoticeable !!!!!!    scrolling 
speed goes down by maybe 20%... but network access remains pretty 
steady... congrats to RT...

I think I mean 
   where prod-code in
not NOT in
(the code is not tested, and may not be possible in mySQL)

Joe Celko's SQL for Smarties is probably the best book for getting 
up to speed.

I have plans for a version 2 of this driver including a full code 
rewritting for much cleaner design, speed improvements, optional 
async API, support more protocol features (like LOAD DATA), implement 
the v5 protocol, improved user API (e.g.: select column in a record 
by field name), etc...

when the server is connected, everything runs at full speed

well, its not that we can't right now... like you show, load can 
be called anywhere.


 (though I am going to admit I would not have figured out such an 
 elegent way to do it, *I* am not yet able to use the force... <ahem> 
 parse with such skill, MASTER JEDI  ;-) ... 


but did you see how much is needed to make that work and the twist 
of redefining a rule within the evaluated expression?  parse is supposed 
to scream in speed... having a load directive integrated would be 
MUCH faster IMHO, and would be MUCH simpler for the new guys on the 
block and us oldies too...  try to explain the above to the average 
joe and well... there goes the parser...  I only 'SEE' your example 
cause I've become able to fit parser in my mind, and I realize that 
even within the advanced REBOLer crowd... not everyone really grasps 
the parser...


one question though, does the set [value pos] define the word globally 
even if the entire above code is within a context which has a value 
and pos defined?

Hello, I finally get FastCGI with rebol/cmd with Lite Speed Web Server, 
but not with Apache.

My uplink speed kinda (no, it pretty much completely) sucks but I 
offer free hosting to any rebol that wants it at peoplecards.ca. 
 I just ask for patience if a new service needs to be installed while 
I work out kinks and the user needs to know that it's home based 
with a not-so-speedy delivery pipe and I offer little in the way 
of frills; meaning it's sftp or ssh cli, not cPanel or other gui.

Now, what happens? The OS will start distributing the CGI processes 
over the multiple cores. Using the disk cache etc to speed loading 
times, enough memory per core on the processor. A 8Gb RAM quadcore 
should be able to run +- 1000 procs/sec (rough estimate). That's 
just one box, with that load it should be profitable. And as you 
obey rule 6, you can scale up and load balance pretty easily.

But Gregg, the reference was towards a "language that combines vocabulary 
and grammar"...  sounds more like "Energy equals mass times the speed 
of light squared", rather than E = MC2

I would look for uniserv anyway, if i can run demons and need speed.

it is imo way faster than even rebcode ... pity rebcode is not c 
level speed :-)

yes, I noticed it, as I played with original rebcode versin a bit 
.... I thought for a little while - cool, they speed up rebcode, 
maybe kind of compiler inside? :-) and then I realised I am running 
official release, without rebcode inside :-)

I think the biggest bottleneck in Rebcode convolve version is extracting 
32-bit integer(pixel) into R G B A parts. We probably need some opcode 
for that. I think this could speed up the 'per-pixel' operations.

G4C TUT_MCListview

// ===========================================================
// A Multi Column (or Database) Listview..
// ===========================================================

WINDOW 126 90 367 373 "Listview"
	winattr style resize

xOnLoad
	// add some records to the listview & open..
	gosub #this AddRecords
	guiopen #this

xOnClose
	guiquit #this

// ===========================================================
// The listview
// - This is a normal MULTISELECT listview (the default).
// For this type to be triggered, you must double-click it.
// ===========================================================

XLISTVIEW 0 0 0 0 'The Title' "" var

	attr ID mylv
	attr resize 0022
	attr frame sunk

	// Give it a grid and allow the user to drag, drop & re-arrange
	// the lines - You can add more styles here..
	attr style grid/arrange/drag/drop/arrange

	// Add some columns. The first one we state with a '#'
	// in front to indicate we mean the 1st column.
	attr LVCOLUMN '#Item/width/120/TITLE/Description'

 attr LVCOLUMN 'Units/width/60/TITLE/Units/TYPE/number/JUSTIFY/RIGHT'

 attr LVCOLUMN 'Amount/width/60/TITLE/Amount/TYPE/number/JUSTIFY/RIGHT'

 attr LVCOLUMN 'Total/width/60/TITLE/Total/TYPE/number/JUSTIFY/RIGHT'

	// show the line double clicked..

 SetWinTitle #this 'SUM: $%Units x $%Amount = $($%Units * $%Amount)'


// ===========================================================
// This is a routine to add 100 records with various
// meaningless values to the above listview. Note how
// the fields can be used as normal variables.
// ===========================================================

xRoutine AddRecords
	local c

	use lv #this mylv

	// before we start, we HIDE the listview. This will
	// stop Gui4Cli from visually refreshing it every time
	// we add a record and will GREATLY increase the speed.
	// This will have no effect if the window is closed.
	// After we finish, we show it again..
	setevent #this mylv HIDE

	for c 0 100
		// add an empty record..
		lv add ''

		// Fill the fields with various values..
		%Item   = "This is Item $c"
		%Units  = $($c * 3)
		%Amount = $(($%Units / 2)*1000)
		%Total  = $($%Units * $%Amount)

	endfor

	// Show the listview again, refreshing the display..
	setevent #this mylv SHOW

// ===========================================================
// Right mouse button handling - Some menu choices..
// ===========================================================

xOnRMB


 QuickMenu -1 -1 'Select All/Remove selected/Add 100 records/#sepa/cancel'
	use lv #this mylv
	docase $$choice
		case = 0			// Select All
			lv select all
			break
		case = 1			// Remove selected
			lv delete selected
			break
		case = 2			// Add some records..
			gosub #this AddRecords
	endcase

speed: Ashley, the parse spec looks very much like a degenerated 
'switch statement to me. You are not doing anything wild that requires 
parse. Have you tried to loop through the spec block and use a switch 
statement instead? It might require a bit state handling but could 
be faster.

Brock yes the colonne resizing feature is planned. but I fear this 
kind of feature is speed in C/C++ and slow in rebol ...

and if you want to test for speed, you can ab (apache benchmark) 
http://wwd.francobianchi.ch/words.cgi;-)

Ah, thanks for the info, I'll check the parsing rules used (that's 
a real PIA to get it right *and* secure). For the speed concern, 
a PARSE-based solution shouldn't be much slower than a C parser.

Improving Cheyenne/UniServe: adding multithreading could make it 
scale much higher with much lower memory footprint. Currently, the 
main process stabilizes around ~20MB after a few hundred requests 
and each worker process take ~15-20MB depending on the application 
and loaded 3rd-party librairies. So for a server script what would 
take 1s to complete, supporting 100 clients simultaneously would 
require today ~2GB of memory. This is huge. 


Carl stated recently that threads overhead is 1MB, so with multithreading 
support, the memory usage for such use case would drop to ~100MB, 
which is an order of magnitude lower (not mentioning the speed gains 
and code simplifications resulting from dropping TCP-based IPC).

hmm, I think that our problem is not lack of speed, but lack of fully 
compliant xml parser at first....

Geomol,  you might just have made yourself a new user :-)  I'll try 
to stress-test RebXML next week, gauging speed, features and stability.

building output objects instead would be simple, but the RAM/Speed/symbol 
table implications of all the binding involved makes this un-optimal.

my paths.. namespace works... for sure.  did you know you can have 
colon in word names in R2 !   but i didn;t use that, I just used 
tags directly.  more obvious than strings, and the exact same effort 
and speed.

i may opionion the speed and the light weight use of the band width

PDAs can do as much work as a desktop (of similar speed) with a 21in 
monitor, but limitations in the input and output methods can make 
it so difficult to use that it will be less effective. Try an OQO, 
Microsoft's Origami platform, or maybe RT can make a build for the 
Nokia 770.

The the laptop I have been eyeing:


http://www.xtremenotebooks.com/index.php?section=specs&model_id=1054


But it is too expensive for me. Does anyone know of a similar one 
at a cheaper price?  Or perhaps someone knows that  this would not 
be a good choice anyway. I'm open for suggestions. I just need a 
big, high resolution screen, large harddrive, and lots of speed. 
I'm not particularly worried about weight.

Ah...on Rebol.com/speed.r

But my hard drive speed is only 4.

Are these very fast speeds for %server-speed.r :

Console:   0:00:00.672 - 753 KC/S
Processor: 0:00:00.25 - 3456 RHz (REBOL-Hertz)
Memory:    0:00:00.625 - 76 MB/S
Disk/File: 0:00:00.172 - 177 MB/S

Geomol, when my mac mini fan is running at max speed, it's about 
half as loud as my PC. During normal operation it's about as loud 
as a brick. :-)

Going for a VMWare for development was my best decision. I hate it 
to setup/move complex environment with different compilers etc. As 
long as you have enough memory, you don't feel a speed difference. 
For some things I even have the feeling it's faster.

but because there's no difference in speed of integer and FP math 
in REBOL, everything is done in FP sou it's needed to convert FP 
to 16-bit integer

math with fpu should be comparable in speed today. i try it.

R3 build-song speed (without optimization) plus write to disk is 
1810ms vs R2 of 2862ms. So even without optimizing in R3 there is 
a large difference in performance.

Before I go this is the shortest intro to scheme and functional programming 
that I had found. It will get you up to speed in this model in one 
day http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html

Example problems I would give my students to solve would look like 
(to be adjusted according to the native word set retained):


Using iteration, draw a 19 line isoceles triangle (concepts of looping 
not obvious for beginners, but essential to grasp early)


Find all prime numbers lower than a given one, using previously found 
primes in the process to speed up the search.


Given a list of adresses, get the files and identify which ones have 
a given information on them (elementary parsing)


... Things like that. Diversified enough to give a good feel of what 
programming can solve while gaining basic skills (data stores, interation, 
maybe recursivity, various control structures - not necessarily all 
of them, operators, native functions and user defined functions, 
input and output, ...)

Vladimir, the window/feel gets time events at full speed. Any subface/feel 
gets time events at subface/rate.

Thanks for the answers to some of my questions! In summary:

- The set-word notation for setting variables doesn't seem to work 
any more, and the reason for the change to the set* opcodes is increased 
speed.

- BRAW is computed goto, but it is yet unclear what the value of 
the word is supposed to be. I'll test.

They can be a great way to speed up state machines, implement switch 
statements and such.

Pekr, we just can't win with you, can we?  You say speed it up but 
as soon as things speed up you say slow down. ;-)

No, nothing like that - I just said that with current speed of development, 
Microsoft should be scared, as ppl will soon realise .NET is big 
mistake ;-)

hmm, but then you just will have few helper funcs in rebcode to speed 
your code execution here or there. OK, so you produce JIT using some 
external library, but how you link it back to rebol? (maybe wrong 
question not understanding properly how this stuff would work :-)

Carl mentioned everything is traded for speed.

Btw speed, little benchmark rebol, rebcode, c: http://polly.rebol.it/test/test/rebcode/download.r

There are some things you shouldn't trade for speed.

that's no good:( I cannot use rebcode to speed up any from my RSWF 
dialect functions as all of them are base on dealing with datatypes 
like UI16 UI32 SI16 SI32, FP and other which simply Rebol do not 
support:(

I am writing int-to-binary conversions in rebcode that support lengths 
of binary from 1 to 4 bytes, little and big endian. I already wrote 
binary-to-int conversions in rebcode, 16 and 32 bit, little and bigendian, 
before it occured to me to check the behavior of to-integer. I'll 
speed-test the rebcode-versus-REBOL methods for comparison.

Jaime: "rebcode first priority is speed, according to Carl."

And it is fast, really. Later, when JIT is implemented, it will be 
even faster.

I am talking speed ;) Your example goes thru a rebol-style call. 
a direct call may be much faster

Back to parse, you could in theory statically translate the rules 
to an internal rebcode-like form for a different VM, and then JIT 
that. You wouldn't get as much of a speedup as you think though. 
The existing parse engine spends most of its time actually doing 
the parsing with the native code in the engine - a JIT would only 
speed up the reading of the parse rules, something it doesn't spend 
as much time doing in comparison.

There have been suggestions for additional parse operations: remove, 
replace and change. I even suggested an if clause that would allow 
the return value paren to direct the parsing flow. Between these, 
that would take care of the vast majority of the operations performed 
in parens, and thus would speed up parse a lot in practice. Even 
more than rebcode would.

Kru: yes, in Rebol there is conversion done. In Rebcode you are at 
full speed ;)

A note about speed:
I've made an exponont function like this:

exponent: rebcode [b [decimal!] x [decimal!]] [
	eqd x 0.0
	braf 2
	return 1.0
	log-e b
	muld b x
	exp b
	return b
]

It can then be used in a rebcode function, e.g.:
apply result exponent [2.0 4.0]

An alternative way is to make a normal REBOL function:
exponent: func [b x][b ** x]
which can be used the same way:
apply result exponent [2.0 4.0]


It turns out, that using a normal REBOL function is faster in this 
example. It then occured to me, that it could be even faster, if 
APPLY was changed to support operators. Like this:
apply result ** [2.0 4.0]

Is that a good request?

guys, how well does parse play with rebcode? It was said that parse 
is VM in itself, it is very right, but now we have some discussion 
about zlib support. Let's suppose we have rebol version on rebol.org 
and that we would like to speed it up. We can simple extend the idea 
to any other datatype (= in amiga terms, simply a file format, or 
protocol one). you will surely want to use parse. The question is, 
if you can speed up some things using rebcode?

note that if speed is what you are after, this is likely to be the 
fastest way; if the object changes in a loop, then the rebcode advantage 
is probably not big, though i understand there may be cases in which 
a BIND or IN opcode would be desirable...

as for me personally, I first met with syncing with IOS, and I have 
to say, that I was hooked! It was really nice to watch, connecting 
even month later from my notebook, to sync properly what was missing 
.... However, later on, I found some limitation to such aproach. 
I don't want to talk about the speed - that could be corrected by 
using different technique for local storage, e.g. RebDB, but about 
following two problems:

I would like to have answered:


1) what technique to use for "timestamping" - do we continue with 
timestamps against one central time, or do we use hashes, or sequencing 
numbers, or mixture of mentioned techniqueues? We might look how 
others do it ...


2) better support for possible conflicts - imagine following scenario 
- you have some reblet, e.g. Contacts - one person starts editing 
it, then another person starts editing it too. First one syncs (saves 
changes), then second one does the same - changes of first ones are 
lost. How to aproach this - introduce some kind of resources locking? 
(not real locking, but we are message based, so could be queued)


It could work as follows - person 1 wants to edit some record. Edit 
button posts request-for-lock. Lock is assigned. I other person tries 
to edit, it will not obtain lock. We could even introduce protocol 
level support, so that the person is informed, who has the lock, 
and how long. The trouble usually comes, when person goes off-line 
after the edit started - we need to remove dead-locks, so by default, 
I would lock for 20 minutes e.g. and the lock would have to be renewed, 
if person 1 wants to work longer with the given document ...


another scenario is, when you actually start editing something which 
might require locking, but you start already being off-line. We could 
create lock-request, just not synced yet. Once you go on-line, you 
simply check seqno, if the lock is possible, and the given record 
not modified. But what if it was modified in the meantime? e.g. you 
might be working with stock system and someone else in the office 
sells few units, for which you may start writing offer for to another 
customer. Tough scenario - would like to know your opinion. Maybe 
some things simply need to be done on-line only?


3) I needed small file-sync scenario - could use IOS, but IOS can't 
sync and "forget". Simply idea is to have different kind of syncing 
techniques, so e.g. for file transfer you have dir to sync, if correctly 
synced, log it, forget it, delete it on client and or server (or 
not, it depends)


as for IOS, local storage could be encrypted (or not), imported into 
RebDB (no single better solution so far introduced for rebol), sync-per-record 
or record-set could remain (record=document). RebDB on Serve would 
speed things up significantly too ...


another possibility is to think outside the IOS terms, in more general 
way - simply thinking about world of objects, being in various states, 
with various life-time around internet and on-line or off-line devices. 
I think that maybe we could find some simpler solution than SyncML 
and the likes ...


another point - such techniques should be transport independent, 
so I would not like to hear that it needs this or that ;-)

So, anyone?

I must say though.. Its the way you program Java.. The speed is not 
always the issue because i have seen java boots screens that did 
my ears wave.. ;-) But i dont understand the choise of java..The 
idea thats its multi-platform is long past..there are alternatives..(but 
those are unknown and scary :-)

Volker you are right. But I was thinking on Rebol bootstrapping itself 
and offering incremental compilation too. Just like Dylan or CL. 
Here is an excerpt from wikipedia. "Common Lisp has been designed 
to be implemented by incremental compilers. Standard declarations 
to optimize compilation (such as function inlining) are proposed 
in the language specification. Most Common Lisp implementations compile 
functions to native machine code. Others compile to bytecode, which 
reduces speed but eases binary-code portability. The misconception 
that Lisp is a purely-interpreted language is most likely due to 
the fact that Common Lisp environments provide an interactive prompt 
and that functions are compiled one-by-one, in an incremental way."

Not to expensive to get a lot more speed. (interpreter would be always 
available too.)

BTW, compilabe- function shares some of the traits of closure. closure 
are a separte function in rebol because they are expensive. In Orca 
we made all funcs to behave like closures, but we decided to factor 
it out like in Rebol to keep the speed gains.

Volker here is another example,



anyF: does [f g h
]

f: func[x][print "f third" 2 * x]

g: func[y][print "g second" y + 1
]
h: func[][print "h first" 1]


anyF ;; == f(g(h()))

;; 

now lets change 


g: does [print "g second" 5

]

anyF ;; == produces something like f(g()) h()


  anyF is compilable only if the order of evalutation 
doesn't change 
  at runtime. 

Rebol permits for the order of evalution to be determined 
  
by the context in which anyF is run, and the interpreter is 
smart 
  enough to GC the unconsumed values.


   This is a feature of Rebol because with the same expression 
you 
   can have two very different meanings, the disambiguation 
of the 
   grammar is provided by the context (or environment). 
This allow 
   Rebol to support easy Dialecting. That is each 
DSL may need specific 
   evaluation orders, aka semantics, 
while they share the same code 
   expression. In this case [f g h].



In the example above two different branches of the AST three 
were 
followed. But by just looking at [f g h] is impossible
to know which 
branch will be taken. 


  Other compilable languages enforce the order of evaluation by 
using 
  specific syntax forms to determine what is an expression. 
 Lisp 
  uses  parens, while  C semicolons and others markers.

 


So in order to make anyF compilable we need to  enforce the 
order 
of evaluation.  One possibilty  is to use Rebol parens.



anyF: does [(f) (g) (h)] ] *** see note


  The cost is evaluation speed for the interpreter, and now 
we are 
  back at using parens at each step. Which is what 
lisp uses. Should 
  we go back to 1967?


  The alternative of JIT is possible, but  it requires hinting and 
  
a sofisticated runtime environment. The translation of Rebol 
code 
  to some an  internal VM like rebcode  is simpler and maybe 
sufficient, 
  otherwise extending rebol via DLLs  is the way to 
get closer to 
  the metal. However, I don't see an easy path 
to having a Metacircular 
  Rebol. If you do, I hope you write
 a Rebol compiler and share it 
  with us ;-)

I hope there will be direct access to the buffer rather than going 
through SHOW. this would speed up operations immensly.

Google - the funny point here is: They say code in java, compile 
to javascript. The first time i see it that way around. Till now 
i heard "use scripting to get it running, use java/c for big things/speed". 
Javascript must be really awfull :)

but it lacks speed and elegance

JAVA 6 to support scripting, speed-up client side GUI, etc - http://www.betanews.com/article/Sun_Releases_Second_Java_6_Beta/1150922228

but it's quite slow. about a third of the speed of a typical VID 
application

I watched a program recently about crossing the street there.  The 
trick being to begin to cross, and keep your speed exactly the same 
at all times.  Which they demonstrated.  Two women holding hands 
(one was a westerner) cross the very wide street with motorcycles 
and mopeds and tiny cars whizzing by.  Scared me to simply watch 
it.


I suspect he paused, which would be something most of us that are 
not used to that might do.


It is a deep shame, as an absent minded professor, one of my big 
fears is being hit by a car.  I used to walk home at about 3:00 a.m 
almost every night.  My office and home were 3k apart.  The streets 
were completely empty, and so I felt somewhat safe from cars.  One 
night in deep thought I crossed the street (totally ignoring the 
state of the light) and was almost hit by a racing car.  Often, when 
I would arrive at home I simply could not remember walking at all, 
I was so deep in thought.

I have no opinion on molded values issue .... maybe we could have 
something like /custom, with a dialect, or not so complicated, just 
/molded refinement, where you define which columns to mold - if that 
makes sense and would actually speed anything up?

BTW, is there a speed gain when using direct? I only save strings 
atm, anyway.

Direct: definite speed gain as MOLD / LOAD is bypassed for each and 
every value bound / retrieved. /flat (if your data structure can 
use it) is also faster and uses less memory - although the gain is 
more noticeable with larger numbers of rows.

Performance will be about 50% without encryption for the SQLite extension. 
But I don't think that it's that much. Reading/writing to disk is 
a lot slower compared to execution speed of processors. So, I expect 
about 25% performance loss.

Hello, I need to implement a database with over 500 rows and I think 
SQLLite is the riight solution. Speed is much important as I need 
to perform about 20 queries each second. Is it loaded in memory ? 
Is there a way to load the database in memory ?

cyphre, try resizing the browser window to fit the plugin. it doesn't 
speed up, so it might be something with mouse events

Maybe a good compromise. Full speed rebol-network restricted or signed, 
and more relaxed thru javascript, where the user knows allready how 
to deal withit (more or less)

Volker: That "wait time" may be due to the new auto-update feature, 
which checks for a new update at RT's servers every day. Do you notice 
a speed improvement on subsequent uses of the plugin within the same 
day?

I had always imagined that the view.dll ran just like View in terms 
of speed.

Single process, no virtual memory - through other tricks, they managed 
to avoid needing it. Because of this the event broadcast, like everything 
else it did, ran by itself on the bare metal. Hence the speed.

but I have started to look at C++, because of speed issues.

also note that liquid was NEVER optimised, so if you look at its 
code, you might find slow loops and such... I know!  for me, having 
it work without bugs and making it easy to maintain, is more important 
than raw speed... in all apps I've done using it, a single View face 
refresh slowed down the application more than alll liquid nodes combined, 
so the integrated lazy computing does enough optimisation on its 
own to make raw optimisation less of an issue.... but when I decide 
to go v2, I will make a "fast" version of the tool for production 
purposes... indentical in features, but with debugging removed and 
some loops optimised for speed.

but I love the speed. comparing it to rapidweaver, it's crazy fast. 
it's webserver independent as well.

Yes, I quite happy with the speed and stability of the new implementation, 
I have RSP pages with 3 SQL queries to a MySQL backend, input and 
output filters, session handling, tables constructed dynamically 
with data from DB, all this occuring in a few milliseconds...I still 
need to test how it scales.

And I am loooking forward to compare Cheyenne R2 vs Cheyenne R3 (using 
threads), and to see speed, and system resources requirements :-)

That way Cheyenne achieve FastCGI speed on normal CGI scripts.

I've been thinking about a game dialect in REBOL for a few years 
now. An abstraction layer, that is perfect for the programming problems, 
you're faced with in game development. Maybe it could even output 
C++ source, if more speed is needed.

I guess a few oddball capabilities might be to purchase some game 
effects like motion speed, range, terrain type for your world, for 
which being need to have a specific means to cross... like noode 
forests and acid baths  :-)

- re help: now that ive spelt ill add it in ;) - ill write some docs 
:(

- re zoom: can do - i need to add a preferences section anyway where 
you can set zoom smoothness etc depending on system speed.
- re numbers justification - will do

- re status output - its there until all the deck cards are ready 
and the deck is also balanced properly - so could be a little while 
;)

re zoom - that will speed up greatly once i turn card info into a 
static image - later today hopefully

Brian, we are different I guess. I also hate talking on a phone, 
since spoken word for me can be hard to understand, but a simple 
line of text can be read again and again until you get it at the 
speed that you can read, not the speed that's dictated at the other 
end. I see a big difference there and my brain works just fine, processing 
text. Perhaps it only comes after 10 years of IRC'ing with lots of 
different people.

I don't really care about video unless it's a tutorial where the 
content is shown in at least DVD quality with a clear voice using 
a studio microphone and the audio is properly synchronized with the 
video. Simple plain text is for me far preferable for anything less 
than that.