Speed differences between MC and Rev and the origin of the English language

[Kevin Miller]

On 21/9/06 22:37, "Richard Gaskin" <ambassador at fourthworld.com> wrote:

>> I believe the revGeneral library is always included. There is no option
>> to turn it off, which is usually okay, since the majority of Rev users
>> need at least some part of that library.
> 
> What a strange design decision.
> 
> I've helped more than a few people diagnose errors in standalones that
> weren't evident in the IDE because of the additional objects being added
> to their first card.  Such errors are particularly hard to pin down
> because the objects don't exist in the IDE, which is the only
> environment that can run a debugger.
> 
> I can see having an "Include revGeneral" option turned on by default,
> but preventing people from doing anything else seems really odd.
> 
> One more reason to improve MC IDE for the masses:  it's the only way to
> make truly native Rev apps. :)

To suggest that a standalone is not a truly native Revolution application
because it contains Revolution code libraries seems nonsensical.  Does that
mean that a standalone containing libURL is not a truly native Revolution
application?

There is no such library as "revGeneral".  You may be thinking of the
revCommon library.  If this is the library you mean, it seems unlikely that
this library would be responsible for a drop in performance given that the
only system message it intercepts is mouseDoubleUp - sending a mouseUp to
objects, in the same way the MetaCard IDE has done since the dawn of time.
All the other message handlers in there are there to support those terms we
define as part of the language definition and include in the dictionary.
Basics such as revCopyFolder.  Its quite a compact library.  The bigger
libraries are all optional.

Whatever is causing the performance difference is unlikely to be that
library.  But if it is, well its like any other part of the product and
could contain bugs along with the engine, the IDE, the OS, a database
driver, etc.

Errors introduced by including objects on the first card of a standalone are
a pain, I fully agree.  That original design decision historically stems
from the need to deliver extensive functionality libraries (today in
constant use in the vast majority of standalone applications out there), and
not having control over the engine and therefore capability to create an
official place to put them.  Doing this better will come about as we improve
the overall product architecture and create a place for this sort of thing.
It won't come about by us hacking in a quick fix that will doubtless
introduce its own quirkiness.  Relative to the time you have already waited
for this, it won't be much longer.

In the mean time, rather than spending time being surprised that we would
attempt to deliver feature libraries with useful functionality for our user
base to include in standalones, we would as ever welcome constructive
suggestions on how to continue progress on making what we have work better
and more reliably.

Kind regards,

Kevin

Kevin Miller ~ kevin at runrev.com ~ http://www.runrev.com/
Runtime Revolution - User-Centric Development Tools