Open Letter to Rev: Quality Is Job #1
J. Landman Gay
jacque at hyperactivesw.com
Fri Oct 20 15:21:56 CDT 2006
Bill Marriott wrote:
> - The installer introduced in 2.7 is horrible. It installs desktop shortcuts
> that point nowhere. The file associations are busted.
The team knows this (because someone posted it to Bugzilla) and is
working on it.
> - Standalones created with 2.7.x are bigger, slower, consume more resources,
> and are highly unpredictable compared to standalones created with 2.6.1.
There are more libraries and a new file format, as well as lots of
additional features offering more control. This takes up more space and
resources. I have not seen any change in speed of execution though;
scripts seem to run just as fast.
I have experienced none of the problems you report with instability, so
there is apparently an issue with something specific you are doing in
your stacks that the rest of us don't see. Again, a bug report that
could reproduce the problem would be welcome. Crashes are fixed first,
with top priority.
> Half the time, quitting the standalone leaves the process running in Task
> Manager -- when the exact same stack under 2.6.1 exits cleanly.
This, I believe, is a scripting issue on your part. Executables will not
quit if a running process has not completed; this is documented
behavior. I have never seen Revolution leave itself running in any of
the stacks I'm writing under Windows, so I have to assume that you are
leaving someething open. This could be a shell command that has not yet
returned, an open library that is doing something, or a dll that has not
> We've had
> reports of libraries not being included even when explicitly added.
See Trevor's comments on this list about this, where he identifies the
problem specifically. You've had "reports" but have you had the
experience yourself? It would seem to be a problem with the shell
command on Mac OS X. Have you actually experienced this problem on Windows?
> And Bill
> V's recent post is not the first report of standalones being built
> incorrectly or bugs returning from the dead.
Perhaps, but I am more inclined to suspect that the wrong standalone
engine crept into his Runtime folder somehow. No one else has mentioned
any problems with it.
> - More often than I'd like, quitting Rev 2.7.x itself results in an
> application error upon exit. And that is if you're lucky and the process
> isn't simply "hidden" as it is in standalones that don't quit properly.
See above, and check your scripts for uncompleted processes.
> the Windows Error Reporting dialog comes up I click "Send Report" every
> time... do you guys even receive/read those reports? Because I haven't seen
> any decrease in their frequency from one release to the next.
Runtime doesn't get these reports. The only way to be sure that the team
sees your report is to enter it into Bugzilla. That is the one and only
venue that assures the problem will be noticed. If you hate Bugzilla and
can't stand to take the time to enter a report, then write one up in
your own words and send it to <support at runrev.com>, along with any
stacks that reproduce the issue, and I will enter it into Bugzilla for
you. You will not get progress reports if you do that though; Bugzilla
update notices are sent only to the original reporter.
> - The Internet library has resulted in lockups in stacks that have run
> without incident under 2.6.1.
> In fact, the 2.7.x series is so awfully bug-ridden, its most welcome new
> feature is the ability to save in "legacy" format.
I've been using every version of 2.7 and haven't seen much of what you
report. This again leads me to believe that you are scripting something
specific that others don't generally use. That could be why so many
people have no issues, but you are so frustrated. It is difficult to fix
a bug you never see; that is why you should send copies of stacks that
reproduce the problem to Bugzilla.
I had a similar experience about a year ago. I found the debugger to be
entirely unusable. It simply would not work under any circumstances, and
the internet library also failed. I was at a loss, and could not
identify the problem, but no one else had any trouble with it.
Months later, I finally was able to pin down the fact that the debugger
didn't work if the stack file path had a comma in it. This turned out to
be the exact same problem that affected the internet library. I wrote to
Dave Cragg and he had a fix for me within a single day. I reported the
same thing to the team and the next release of Revolution had a fix in it.
The reason I'm telling you this story is because I want you to
understand that I was as frustrated and unhappy as you are -- but I was
aware enought to know I was the only one apparently affected. The
debugger was completely, irretrievably broken for me, and yet no one
else complained. The issue was easy to fix once I identified the cause,
but completely unreproducible by anyone else.
The team does not expect you to identify the cause of bugs yourself, but
giving them an example stack would sure be a better way to get things
fixed than venting all over the list. That solves nothing.
> Yes, Rev, it's really that bad.
For you. I haven't had any of the issues you describe. Tech support
hasn't had any reports of most of what you describe (we did get the one
about the installer. So they're working on it.) There are lots of people
working with lots of copies of Rev and they don't have these problems
either. The only logical conclusion is that your stacks do something
that causes these issues, and if you can send them an example, the team
can fix it. If you refuse to do that, and if no one else has the
problems, then I guess you'll just have to stay frustrated because it
will go unreported.
> Some of you will say, "Bill it would be much more productive if you filed
> all this in Bugzilla." Well, I'm all for contributing to the community. But
> it takes time and effort to file a decent bug report. You need to have
> something reproducible, supply sample files, write it up properly, etc.
Yes, that's true. And if *you* can't provide a reproducible stack -- and
you are the one having the trouble -- then how can the team do it?
Obviously it worked for all their tests prior to release. What are they
supposed to do to find the bug that you can't provide an example of?
> I haven't seen action on other serious bugs
"Serious" is a relative term, depending on who is using it. However,
crashes are always fixed promptly.
> Besides, I don't even "own" this version.
That doesn't matter. You can submit to Bugzilla even if you are just a
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
More information about the use-livecode