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." <[EMAIL PROTECTED]> 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@lists.runrev.com > > > 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 > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution