RunRev vs RealBasic

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
"Include".

How about it rr - something like:

revDeclareExternal someFunction in "C:\something.dll"

Wouldn't that be sweet :-)

Best

Gordon

--- "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
> 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
> > use-revolution at lists.runrev.com
> >
>
http://lists.runrev.com/mailman/listinfo/use-revolution
> >
> >
> -
>
-----------------------------------------------------------
> 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)
> 
>
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
> use-revolution at lists.runrev.com
>
http://lists.runrev.com/mailman/listinfo/use-revolution
> 