-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Dec 31, 2004, at 5:04 PM, Chipp Walters wrote:
On Fri, 31 Dec 2004 2:40 pm, Ken Ray wrote:That's one of the beauties of Rev... data can be stored *inside* the stack
files, either as data in fields that have been saved, or as custom
properties that are stored with the stack itself.
A great point. I recently was able to create a compressed, encrypted binary data storage file using a stack and a single line of code. This data file stores text data along with imades in 3 different formats.
This data file is actually a stack with no business logic and is opened by my app invisibly and data selectively moved to the gui, edited there and then moved back to the inv stack to save. Talk about simple. Doing the same in VB would be very complicated. I imagine RB too.
Btw, regarding speed issues, I think there have been a number of speed coding challenges between RB and RR with no conclusive winner. Perhaps Frank can be more specific with regard to areas he feels RR runs slow?
Again, CPU-Intensive routines, such as processing each byte of a long string individually. Most of the more "stock" operations run quite well in Rev, but when doing intensive, custom CPU-intensive routines, it generally pays to write an external, particularly when targeting older hardware.
Also, last time I looked, RR compiles scripts 'on the fly' like Java. Didn't know RB was a compiler. Must be tough on edit/compile/run/debug cycles. Perhaps it's an interpreter like RR and compiles during runtime? I don't know.
Rev "compiles" scripts into a bytecode format which is later interpreted by the runtime environment. Faster than a "pure" interpreter, but still slower than compiled code.
Java code gets run through a compiler which translates it into a Java bytecode. That bytecode is then interpreted at runtime, much as is Rev code. However, some Java runtime environments (JREs) will actually "recompile" the bytecode into native code for the platform. This is slower than compiling code directly for the hardware, but adds the write-one-run-anywhere flexibility of Java (and to some degree of Rev), and the result of this (sometimes referred to as "Just-In-Time" compilation) is much closer in speed to native compiled code.
Real Basic is a true compiler, which translates code into instructions for the actual hardware on which it is run. This is the fastest solution, since the computer hardware does virtually *all* of the work of figuring out how to execute each instruction, and there is no runtime translation step. However, this also locks the compiled version to the platform for which it was compiled (similarly to a standalone produced by Rev), and it causes a Compile-Run-Debug cycle to be introduced. Visual Basic (M$ product) is also a true compiler.
I personally wonder what it would take to create a true compiler for Rev stacks? Obviously this would introduce some limitations on certain operations, but for stacks which don't use those operations, it could substantially increase performance...
Best, Chipp Chipp Walters, Altuit.com Sent from my Sidekick _______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
- ----------------------------------------------------------- Frank D. Engel, Jr. <[EMAIL PROTECTED]>
$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.
$
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFB2WM77aqtWrR9cZoRAsUbAJ4gtrDqiI1CZJxxBW6uoR4CoaMjCwCePAdK KhTWir4Ze+lNH6W5Kgz47x8= =6op3 -----END PGP SIGNATURE-----
___________________________________________________________ $0 Web Hosting with up to 120MB web space, 1000 MB Transfer 10 Personalized POP and Web E-mail Accounts, and much more. Signup at www.doteasy.com
_______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
