RunRev vs RealBasic
gwalias-rev at yahoo.com
Mon Jan 3 10:53:21 EST 2005
I really like what Frank is contemplating ...
It would be ganz wunderbar if rev users had the option
to create stacks that were destined to be natively
compiled as externals. I guess that rev would have to
insist on some sort of type declarations in such a
case to get optimal performance, but this could be
done only in the stacks that are to be compiled,
allowing rev users to keep a flexible, typeless
environment except for the parts of the app that
needed compiled performance. Naturally, the runtime
would produce all the necessary boilerplate code for
the interface between the rev runtime+bytecode app and
the new external :-)
BTW: I purchased rev because I was tired of working on
my hands and knees pushing heavy boulders with my
nose, writing in C (or doing the same with a hippo on
my back, writing in C++). Isn't there some way that
rev could free us from the hell of having to write
externals in C? I also use PowerBasic, which allows
you to declare the functions exported by a DLL in your
code and then simply use them as if they were an
How about it rr - something like:
revDeclareExternal someFunction in "C:\something.dll"
Wouldn't that be sweet :-)
--- "Frank D. Engel, Jr." <fde101 at fjrhome.net> wrote:
> -----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
> > 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
> 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
> > use-revolution at lists.runrev.com
> Frank D. Engel, Jr. <fde101 at fjrhome.net>
> $ 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)
> -----END PGP SIGNATURE-----
> $0 Web Hosting with up to 120MB web space, 1000 MB
> 10 Personalized POP and Web E-mail Accounts, and
> much more.
> Signup at www.doteasy.com
> use-revolution mailing list
> use-revolution at lists.runrev.com
More information about the Use-livecode