RunRev vs RealBasic
b.xavier at internet.lu
Mon Jan 3 11:21:41 EST 2005
Basically, you want compileIT for RunRev for all platforms...
Not obvious to do probably ;))
Join the club!
Im sure someone is working hard on it ;)
What would be cool, would be a runrev to flash compiler ;))
eh, it's a joke, i'd rather have a FireFox plugin to run RevStacks
> -----Original Message-----
> From: use-revolution-bounces at lists.runrev.com
> [mailto:use-revolution-bounces at lists.runrev.com] On Behalf Of
> Gordon Webster
> Sent: Monday, January 03, 2005 16:53
> To: How to use Revolution
> Subject: Re: RunRev vs RealBasic
> 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 "Include".
> 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
> > 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
> > compilation) is much closer in speed to native compiled code.
> > Real Basic is a true compiler, which translates code into
> > 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
> > 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
> > 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
> > Son, that whosoever believeth in him should not perish, but have
> > everlasting life.
> > $
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.4 (Darwin)
> > 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
> > use-revolution at lists.runrev.com
> use-revolution mailing list
> use-revolution at lists.runrev.com
More information about the Use-livecode