Open Letter to Rev: Quality Is Job #1

Sarah Reichelt sarah.reichelt at gmail.com
Fri Oct 20 18:09:21 CDT 2006


I am mainly a Mac user, but I do have a few things I use Windows for,
so I thought I would chime in here. I agree with some of Bill's points
and disagree with others.

I have used all the 2.7.x versions and while I didn't recommend 2.7.0
to anyone else, I did get my colleagues to upgrade to 2.7.1 and have
been pleased with the results.

> - The installer introduced in 2.7 is horrible.

I have only used the installer on a standard install of XP Home
(running under BootCamp on my Intel Mac), but it worked perfectly. I
have had problems with updating on a MacBook. I haven't tried
uninstalling.

> - Standalones created with 2.7.x are bigger, slower, consume more resources,
> and are highly unpredictable compared to standalones created with 2.6.1.
> Half the time, quitting the standalone leaves the process running in Task
> Manager -- when the exact same stack under 2.6.1 exits cleanly. We've had
> reports of libraries not being included even when explicitly added. And Bill
> V's recent post is not the first report of standalones being built
> incorrectly or bugs returning from the dead.

On Mac, the Universal Binary standalones are bigger. On Windows, I
have found that my apps compile to more or less the same size. Maybe I
am not using some libraries that have increased in size?

The problem with libraries not being installed is definitely an issue,
which I had hoped would be fixed in the latest release and wasn't.
However I only get it on one of my computers and not the other, so I
can see how it might be hard to diagnose. For any Mac users following
this thread, this often includes the plugins that control the look &
feel. If your app looks like an OS 9 app, these plugins are missing
from the app bundle. I wrote a standaloneSaved handler which puts
these in automatically after building. It's in the list archives if
anyone is interested. I realise that Bill is not interested in
workarounds, but wants the problem fixed, and I respect that, but in
the meantime, there IS a workaround.


> - More often than I'd like, quitting Rev 2.7.x itself results in an
> application error upon exit.

OK, this is the point that really made me write this reply, since I
too suffered from this when converting a major app from 2.6 to 2.7.
However it turned out that it was an error in my scripting. Rev 2.6
just ignored the error, where 2.7 tripped on it. This eventually
showed me that my entire shutdown routine was flawed (various
asynchronous serial commands getting mixed up with stacks closing) and
I was able to fix it. Under 2.6, the problem was there, but I just
didn't realise it.

> The IDE is noticeably, painfully slow, and suffers from screen refresh
> problems and on-screen corruption.

I haven't noticed this so I can't comment. I now use Galaxy all the time.

> - Geometry manager still is hit-or-miss. It works until it doesn't... then
> you have to rebuild everything from scratch. One prominent developer told me
> he never uses it, because of the peril to his work product. Just when are
> you going to get around to fixing that?

Like Chipp, I find it much easier to write my own geometry handlers.

> - The XML library under 2.7.x seems to consume much more memory and not
> clean up after itself. Stacks that use XML work fine under 2.6.1, but have
> locked up with 2.7.x.
>
> - The Internet library has resulted in lockups in stacks that have run
> without incident under 2.6.1.

I've used the XML & internet libraries successfully in both Mac &
Windows under 2.7.x - In fact I deployed a cross-platfrom app just
recently that relies heavily on those 2 libraries and haven't had a
single problem reported.

I used to do play testing for a computer games company and they always
reckoned that the biggest problem was the enormous variation among
PCs, even with supposedly identical installations of Windows. Given
that not everyone is experiencing Bill's problems, I would assume that
a lot of them will be due to something about his system that is
different to any of their test systems. I completely agree with Bill,
that Rev should be using the Windows error reporting mechanism, which
would be giving them info on any major problems as well as details of
the particular system. They would then be able to see if a particular
system configuration was causing problems that didn't occur elsewhere.

Finally, a note on Bugzilla: if you have a bug that you can't
reproduce reliably and you can't find an exact recipe for it, the
incentive to make a vague Buzilla report is very low. Every 6 months
or so, a new person seems to go through the list and "confirm" a lot
of the bugs, but that seems to be the major action taken. While I'm
sure that crash reports receive more priority, one without a recipe is
not going to get anywhere I would have thought.

I also think that Rev's frequent statement "we don't read the mailing
list" is a very short sighted policy. This list has a number of very
talented and skilled people who are very generous with their time.
They must take a lot of pressure off Rev's official support, but they
also come up with many solutions and suggestions. RunRev's decision to
ignore this valuable resource is just incomprehensible.

Regards,
Sarah



More information about the use-livecode mailing list