How do you handle the poor performance of LC 7?

[Richard Gaskin]

Peter W A Wood wrote:

 >> On 31 May 2015, at 07:07, Richard Gaskin wrote:
 >>
 >> If there are bugs that have been submitted but not acted on and
 >> are holding up work without a workaround, let's identify those
 >> and get them resolved.
...
 > I reported a bug - <http://quality.runrev.com/show_bug.cgi?id=15173>
 > - in the default version of LiveCode Server used on On-Rev on 8th
 > April 2015. The bug stopped me using LiveCode to develop a small web
 > app used by a client. I had to use Ruby instead. When the client
 > asked, “What did you write it in?”. I answered “Ruby” not “LiveCode”.

Looks like Lyn Teyla came through with a workaround in that report 
(thanks Lyn).  In fact, I tend to read from stdIn anyway since I rarely 
use LiveCode Server, preferring faceless standalones so I can do unit 
testing and reasonably complete server emulation right in the desktop IDE.

Also, your report was against v6.6.5, so while Lyn was able to confirm 
that this is also present in v7.0.5 in this thread about issues 
preventing people from moving to v7 this would not be one of them.

Still, it would of course be good to see it fixed, and I spent a couple 
minutes to search for related items in the DB, and posted links across 
them to help steward this to resolution.

In the meantime, although Ruby's an excellent language, if you want to 
use LiveCode for that I believe there's code in the community for 
parsing multi-part form data, and I could dig some up if you're in a 
position to rewrite that (though since it's working now I'd understand 
if it's not worth the time).


 > Nobody at LiveCode has bothered to review the bug report yet.

Consider how differently that sentence reads with one small change:

   Nobody at LiveCode has reviewed the bug report yet.

I try to be mindful that this is an international community and 
sometimes expressions carry different weight in different cultures.

I see a number of people outside the US use phrases like "RunRev can't 
be bothered" quite liberally, but in the States that wouldn't be how 
professionals address one another in conversation.

In American culture "can't be bothered" is used almost exclusively as 
derisive, carrying a connotation that the subject had sufficient time 
available for whatever task is being discussed, but wilfully chose to do 
something less important, or perhaps even trivial.

I once worked for a manager with limited technical skills, but he held 
his position well because he possessed an uncommonly insightful 
awareness of the nuances of communication that shape human performance.

He advocated with his staff a practice he called "de-hooking", reviewing 
communications before they go out to see if there's an opportunity to 
remove any phrases which might raise the recipient's ire, to keep the 
focus on actionable outcomes.

Lord knows - as do many of you here - this is something I'm still 
learning to get right myself.  I enjoy language, and could benefit from 
using it less pointedly at times.


We all want things, and many of the things worth having are bigger than 
any single person can accomplish alone.  So we work in teams, together, 
in a spirit of mutual respect, and collectively we can have a chance to 
get what we want.

Thanks in no small part to some kind nudging from Jacque many years ago, 
I try to write as though I'm sitting across the dinner table from the 
reader.  After all, in this community, which includes the core dev team, 
chances are that'll happen in person at some point or another.

Though I can certainly improve my own "de-hooking", I find a mindfulness 
of tone helps me get what I need from the people I work with.  Extra 
bonus points that it makes the conversation that much more pleasant as well.

-- 
  Richard Gaskin
  LiveCode Community Manager
  richard at livecode.org