Colin wrote:
>If a thousand people experience great performance and one person
>experiences very poor performance, would it not seem worthwhile to
>consider the cause of the difference may lie with the system's
>configuration?
You can't use logic for this case, otherwise you would argue that if on a
particular machine you can open and run a stack without any issues in 2.9,
and if you open and run the stack in 4.0 you get two minute long lock up
of the machine every time you press a certain key, obviously 4.0 is the
only thing that was changed in the test, and so must be at fault.
Actually, one can and should use logic here. The former is an example of
logic; the latter is, well, superstition. The difference is "sample size."
If I buy two loaves of bread at the store, and one is stale but the other is
fresh, I can make no logical inferences about the cause of the staleness
even if superficial aspects like "expiration date" and "wrapper color" are
the same and the only apparent difference is the brand. The fault could lie
among a hundred different variables. You cannot compare two loaves and say
with any confidence that "Brand X" is a better bakery than "Brand A."
Neither loaf can be said to be representative of the larger population.
However if 999 loaves of Brand X turn up fresh and one loaf is stale, it's
logically valid to infer there must be something about the unique
handling/processing/delivery/storage of that particular loaf that has caused
the problem. Perhaps the wrapper was torn while unpacking, or a 6-year-old
kid with grubby hands opened it and stole a slice while it was on the store
shelf, etc.
Mark wrote:
Who says that thousand people experience great performance?! I, for
one, don't.
I am pretty sure that Inselfan did something that should just work in
Revolution without problems and figuring out the source of the problem
is a process that one should not have to go through with a development
environment like Revolution in the first place!
Mark, I'm sure that if it took you minutes to hide/show the Tools Palette
and anything more than milliseconds to navigate between cards, we would have
heard from you about it before now. I would also say that investigating
reasons for mysterious slowdowns in projects is an unavoidable task in any
development environment, especially one like Rev which is designed for
authoring/deployment on so many varied platforms. Having said that, a
refresh of the IDE probably is needed -- for efficiency, to update the
look-and-feel, and to exploit new features like behaviors --and is in the
works.
In this particular instance there are so many variables and factors we do
not know about the situation. Does this problem occur with all stacks or
just the 16MB one? Is the Property Inspector open, and to what pane? Are
there any third-party add-ons installed that have not been designed for the
post-2.9 world?
It's also easier than ever to do testing, especially on Windows where you
have Microsoft's Virtual PC 2007 and freely downloadable images of the
Windows XP and Vista operating system. I'd really like to see what happens
if Horst downloads one of those images, installs Rev 4.0 fresh, and tries
his stack.
I'm not saying there definitely is NOT some obscure change made in Rev 4.0
that causes this interaction. But I'm saying it hasn't cropped up before
despite extensive usage by hundreds of other people. I'm confident that a
configuration change will solve the problem, or failing that we will learn
something about the particular usage scenario that needs to be addressed,
either by the end user or RunRev. Without going through the troubleshooting
process, we will never know. It certainly isn't fair to encounter something
like this and throw one's hands up saying, "Ah, Rev 4.0 is obvious crap!"
Richmond wrote:
There is a school of thought that RunRev have tried to expand the
capabilities of Revolution rather too
rapidly, without taking care of some 'nuts-and-bolts' glitches that have
been around for some time.
Perhaps. But as someone who wrote just over three years ago that "Quality is
Job #1," I have to disagree with this school. We've come a long, long way.
RunRev spent more than a year and a half working on the
free-for-almost-everyone Rev 2.9, which addressed hundreds of those issues,
re-architected tons of internals, and brought the Linux edition up to speed
with the other platforms. The result was a measurable, marked improvement in
quality, and a more robust platform that has enabled much-needed
"nuts-and-bolts" enhancements since then: the new tabbed script editor
(3.0); the data grid and behaviors (3.5); and the Web plugin (4.0). All of
which have been delivered on a predictable schedule with more far more
external testing -- both in terms of number of users and length of
testing -- than prior versions. At the same time, we have halved the retail
price of the product and even introduced the free and highly capable
revMedia edition while growing in profitability during a time of global
economic uncertainty. We still have a ways to go. I realize that we often
don't report status in a timely way in the RQCC, and not all the reports we
want to have been fixed. There will always be issues with software; the key
is choosing the right battles. Overall, we must be doing something right.
- Bill, RunRev marketing guy
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
