How do you handle the poor performance of LC 7?

[Andrew Kluthe]

Thanks for the reply, Richard.

I totally understand what you're talking about there, but between a full
time gig, very young children, and freelance work at night. I just don't
know where I'd find the time to be effective at giving them the level of
detail that they need. I can't give them the actual software that's
suffered from these issues as it's all under NDA. I don't really have time
to hunt down the root of the problem, recreate code to explain it, create a
data set they can refer to for testing it, wait for it to be analyzed, wait
for it to be implemented, and try again.

Sure, I would love if the users of my software would all sit down and try
to help me pinpoint regressions, bugs in new features, etc. I would want
well thought out, reproducible issues with good data to try them against.
Reality is, they are all also busy trying to use said software to do their
increasingly strenuous day jobs (of which the software is supposedly there
to make it easier). That's just something I have to understand as a someone
who writes software for users. It would be nice, it would make things go
smoothly, it's a good goal to reach for in educating users, but it's not
exactly as easy as that.

It's not really an excuse to sit back and wait for someone else to find out
the bugs as it is the hard reality of some people's situations.

In short, the request for us to invest this much time in helping them
figure it out is almost as stressful as the actual problems.

The Us (community) vs Them (RunRev) that persists is the result that most
of the people started using this software when it was still proprietary.
It's a big step for many of us to transition to. Particularly, if we came
to runrev/livecode to save us on development/prototyping time. Our
community used to be so sure of the praises of livecode. It really was and
will again sometime be a fantastic product. But I'm sorry to say v7 is not
a production quality toolset for those without tons of extra time on their
hands.

As a result, I have done no new development that wasn't a one off utility
for something simple in livecode since it went open source. I'm too afraid
to lose my lunch (or for users to lose theirs) to these issues. When one of
my livecode apps needs an overhaul, I've been selecting other
tools/technologies to rewrite it in because of how long all of this has
been building up to and in the works.

Things will get better. I know that. It will take some time. I get that.
I'm more or less fine with things taking longer to smooth out. But I won't
recommend that someone else spend their time on it, if they don't have time
to spend.

It seems like lately there has been this big move to say "Well, there isn't
actually a problem. People just aren't pitching in to help us like they
should." I don't think this line is entirely realistic for all in our
somewhat small community. Some of us are just going to have to wait until
LC is a realistic production-worthy option for us again, and I'm looking
forward to it after the 8 previews. I think this is mostly because
regardless of speed, 8 will have enough new (and relevant) features to make
it worth the hassle of trying to work with.

On Fri, May 29, 2015 at 12:36 PM Richard Gaskin <ambassador at fourthworld.com>
wrote:

> Andrew Kluthe wrote:
>
>  > I guess I've just been hanging back from upgrading the important
>  > stuff until I stop seeing emails like these on the list.
>
> There is some performance degradation with v7, but improved in recent
> builds and often the difference may be measurable but not noticeable.
>
> There's an option with File -> Save As in LiveCode to pick any file
> format supported over the last decade.  Once chosen, any use of File ->
> Save will continue to use that format, so you can work on things moving
> between 6.7 and 7.0 without penalty.
>
> Of course backups are helpful, but less for LiveCode than any other
> reason all of us make multiple redundant backups nightly (earthquakes,
> disk failure, etc.).
>
> Given the scope of changes between 6.x and 7.x, relying on hearsay is
> problematic for two reasons:
>
> 1. The specific areas in which other people are seeing performance
> degradation may not be the same your app will experience.  Yours may be
> fine, or it may expose something more critical and well worth
> identifying, but if we don't identify it it can't be fixed.
>
> 2. To be frank, the number of posts here about issues in v7 is a
> multiple of the number of actual issues, with a relatively small number
> of issues cited over and over, often requiring nudging or direct
> assistance to turn those concerns into actionable bug reports.
>
> True, multiple changes in the iOS SDK have required the team to postpone
> issues for other platforms to rush out yet another 7.0.x build to
> address Apple's changes du jour, and this has meant many things we need
> for other platforms have remained outstanding longer than anyone,
> including the dev team, would prefer.
>
> In my meeting with Ben yesterday we spent the bulk of our time
> discussing community concerns about quality and performance in v7.  One
> of the challenges the team faces is the signal-to-noise ratio, in which
> vague comments like "7 is just broken!" aren't actionable and therefore
> even if well-intended are ultimately confusing if it doesn't produce a
> bug report.
>
> 6.x may be maintained for now, but its days are numbered.  It represents
> an expense to the project that would benefit all of us if the dev team
> weren't saddled with.
>
> 8.0 is the future, but that future rests on the foundation of v7.
>
> 7.0.x is the present.  It includes the largest number of fixes and
> enhancements, it's the core that v8 depends on, and it's what the
> company's revenue depends on now and for many months ahead.
>
> It's also what we in the community depend on for our own work, so let's
> pull together and identify specific actionable issues and make sure
> they're in the bug DB so they can be addressed.
>
> I'll continue to do my best as time permits to help triage and steward
> reports as they come in.
>
> --
>   Richard Gaskin
>   LiveCode Community Manager
>   richard at livecode.com
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>